-----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.