[ECOS] 28Fxxx Flash query problem

Gary Thomas gary@mlbassoc.com
Tue Jun 24 13:52:00 GMT 2008


Steven Clugston wrote:
> 
>> -----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.

They are there, just mixed in.  0041AFA4 & 0041AFAC

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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



More information about the Ecos-discuss mailing list