RE: [ECOS] 28Fxxx Flash query problem

["Steven Clugston" <steven dot clugston at newcastle dot ac dot uk>]

>-----Original Message-----
>From: Andrew Lunn [mailto:andrew@lunn.ch] 
>Sent: 24 June 2008 13:47
>To: Steven Clugston
>Cc: ecos-discuss@ecos.sourceware.org
>Subject: Re: [ECOS] 28Fxxx Flash query problem
>
>
>On Tue, Jun 24, 2008 at 12:36:14PM +0100, Steven Clugston wrote:
>> 
>> >-----Original Message-----
>> >From: ecos-discuss-owner@ecos.sourceware.org
>> >[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of 
>> >Andrew Lunn
>> >Sent: 23 June 2008 16:54
>> >To: Steven Clugston
>> >Cc: ecos-discuss@ecos.sourceware.org
>> >Subject: Re: [ECOS] 28Fxxx Flash query problem
>> >
>> >
>> >On Mon, Jun 23, 2008 at 04:22:57PM +0100, Steven Clugston wrote:
>> >> I'm trying to add flash support to a board that has a single
>> >> 28F320C3-T part. I've included the Intel flash_28fxxx and generic 
>> >> flask packages and provided a platform flash package as well.
>> >> 
>> >> To test this I've created a Redboot RAM Elf image built from
>> >cvs which
>> >> I upload and start from an older Redboot image installed a couple 
>> >> of
>> >> years ago on separate internal flash.
>> >> 
>> >> The problem is that when I run the image, it hangs in
>> >> flash_28fxxx_parts.inl flash_query function:
>> >> 
>> >> void
>> >> flash_query(void* data)
>> >> {
>> >>     volatile flash_data_t *ROM;
>> >>     flash_data_t* id = (flash_data_t*) data;
>> >>     flash_data_t w;
>> >> 
>> >>     ROM = (volatile flash_data_t*) CYGNUM_FLASH_BASE;
>> >> 
>> >>     w = ROM[0];
>> >> 
>> >>     CYGHWR_FLASH_WRITE_ENABLE();
>> >>     
>> >>     ROM[0] = FLASH_Read_ID;
>> >> 
>> >>     // Manufacturers' code
>> >>     id[0] = ROM[0];
>> >>     // Part number
>> >>     id[1] = ROM[1];
>> >> 
>> >>     ROM[0] = FLASH_Reset;
>> >> 
>> >>     CYGHWR_FLASH_WRITE_DISABLE();
>> >>     
>> >>     // Stall, waiting for flash to return to read mode.
>> >>     while (w != ROM[0]);
>> >> }
>> >> 
>> >> Using a hardware debugger to interrupt execution is it
>> >always stuck in
>> >> the while loop at the end of this function. If I force the program
>> >> counter back to the start of the function and step though 
>it works 
>> >> fine, the flash chip returns the correct manufacturer and 
>parts id's 
>> >> and I get all the Redboot 'fconfig' commands.
>> >> 
>> >> Strangely, (perhaps because the code has been inlined?) if I set a
>> >> breakpoint to catch it before it goes through they don't 
>> >> seem to work 
>> >> and it still drops through to the while loop, and the 
>debugger gives 
>> >> register locations instead of memory addresses for variable 
>> >> locations.
>> >> 
>> >> Does anybody have any ideas how to tackle this?
>> 
>> 
>> >Do you have an MMU? Have you configured the address space to
>> >be none caching, write through etc.
>> >
>> >         Andrew
>> 
>> Thanks (again) Andrew.
>> 
>> Its an MPC555, so it doesn't have an MMU or data/instruction 
>cache to 
>> worry about.
>
>I think it does have an Instruction cache, but that does not 
>matter here.
>
>> As far as I understand there's just two USIU memory controller 
>> registers to set, BR0 and OR0 for chip select CS0 which the flash is 
>> on. I've set these to the same as the manufacturer uses with U-Boot 
>> and I've check that the values make sense, burst inhibit, 
>16-bit port 
>> etc.
>> 
>> I've just tried stepping through the code again and for some 
>reason it 
>> seems to execute non-sequentially, it jumps around in the 
>> flash_query() function which causes the variable 'w' to get 
>read after 
>> Read_ID has been written to the flash so the while() loop 
>always hangs 
>> as 'w' has the manufacturer's code instead of the original 
>flash value 
>> in it.
>
>Show us the assembly language for this function. Lets see if 
>that at least makes sense.
>
>      Andrew
>


    CYGHWR_FLASH_WRITE_ENABLE();
0041AFA0: 3D600280  lis      r11,640
0041AFA4: 3D40FFC0  lis      r10,-64
0041AFA8: 616B100C  ori      r11,r11,0x100c
0041AFAC: A10A0000  lhz      r8,0(r10)
0041AFB0: 800B0000  lwz      r0,0(r11)
0041AFB4: 7C0006AC  eieio
0041AFB8: 60000004  ori      r0,r0,0x0004
0041AFBC: 900B0000  stw      r0,0(r11)
0041AFC0: 7C0006AC  eieio
    
    ROM[0] = FLASH_Read_ID;
0041AFC4: 38000090  li       r0,144
0041AFC8: B00A0000  sth      r0,0(r10)

    // Manufacturers' code
    id[0] = ROM[0];
0041AFCC: A12A0000  lhz      r9,0(r10)
0041AFD0: B1230000  sth      r9,0(r3)
    // Part number
    id[1] = ROM[1];
0041AFD4: A00A0002  lhz      r0,2(r10)

    ROM[0] = FLASH_Reset;
0041AFD8: 392000FF  li       r9,255
0041AFDC: B0030002  sth      r0,2(r3)
0041AFE0: B12A0000  sth      r9,0(r10)

    CYGHWR_FLASH_WRITE_DISABLE();
0041AFE4: 800B0000  lwz      r0,0(r11)
0041AFE8: 7C0006AC  eieio
0041AFEC: 540007B8  rlwinm   r0,r0,0,30,28
0041AFF0: 900B0000  stw      r0,0(r11)
0041AFF4: 7C0006AC  eieio
    
    // Stall, waiting for flash to return to read mode.
    while (w != ROM[0]);
0041AFF8: A00A0000  lhz      r0,0(r10)
0041AFFC: 7C004000  cmpw     r0,r8
0041B000: 4D820020  beqlr
0041B004: 4BFFFFF4  b        flash_query+0x58 (0x41aff8)

Sorry, the first two C lines seems to be missing in the debugger.
Perhaps that's an indication of something. I'll try objdump as well.

Steven

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss