This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: 28Fxxx Flash query problem
- From: "Steven Clugston" <steven dot clugston at newcastle dot ac dot uk>
- To: <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 24 Jun 2008 14:05:29 +0100
- Subject: RE: [ECOS] 28Fxxx Flash query problem
>-----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