This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: 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
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss