Re: [ECOS] 28Fxxx Flash query problem

[Andrew Lunn <andrew at lunn dot ch>]

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

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