[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