[ECOS] Re: Booting from Flash in a AT91M55800A based platform

[Marc-Andrà Beck <marc-andre_beck at gmx dot ch>]

Hi,

I'm a coworker of Nuria and am rather new to this project. So i reply to 
this mail.

Lambrecht JÃrgen wrote:
> Frank Pagliughi wrote:
>  > Pazos Escudero Nuria wrote:
>  >
>  > >Hi,
>  > >
>  > >I've ported eCos and RedBoot for a proprietary platform comprising the
>  > >AT91M55800A processor a SRAM and three S29AL016D90TFI02 flash modules.
>  > >The RAM version works fine and I can communicate with the RedBoot
>  > >console through the serial port, but I have not yet managed to make
> Can you access the flash from redboot? (fis init; fconfig -I; ..)

No. while booting from RAM I only see the RAM. There's no FLASH part:

RAM: 0x40000000-0x40080000, [0x4001f1e8-0x40034000] available


Trying to build the "Flash Tools" (CYGSEM_REDBOOT_FLASH_CONFIG) fails 
with a linking error:

.../libtarget.a(redboot_fconfig.o): In function `do_flash_config':
.../fconfig.c:322: undefined reference to `__flash_init'


As the flash (NAND) supports the JEDEC-standard, shouldn't it be 
accessible from RedBoot with a generic driver?


> Are the flash things OK? You can use the arm/at91/eb55 port as starting 
> point. You need also flash code in devs/flash/arm/eb55 and 
> devs/flash/amd/am29xxxxx -> I just checked 
> devs/flash/amd/am29xxxxx/current/include/flash_am29xxxxx_parts.inl, and 
> there is no S29AL part in the list.
> Just add it. You can start from the CYGHWR_DEVS_FLASH_AMD_S29GL128N 
> part, and check your datasheet for changes.
> (mark: the eb55 board uses an atmel flash of course, so the part used (' 
> #define CYGHWR_DEVS_FLASH_ATMEL_AT49BV1604A ') is in 
> devs\flash\atmel\at49xxxx\current\include\ flash_at49xxxx_parts.inl)
>
> You could also have problems because of the 3 flash chips. Start with 
> using only 1.
> If you want to use the 3 flashes separately, I think you need then the 
> flash_v2 drivers - check the mailing list for it.
>
>  > the
>  > >platform boot from the flash (after copying the ROM version of the
>  > >ported RedBoot on the flash address pointed by the chip select 0). I
>  > >don't know whether the problem comes from the platform porting or from
>  > >the fact that eCos does not recognize the used flash chips from
>  > >Spansion. Could you provide me any hint?
>  > >
>  > >Thanks in advance!
>  > >Nuria
>  > >
>  > >
>  > >
>  > If you're programming the Flash chips with a JTAG, then the lack of
>  > eCos
>  > drivers doesn't matter at this stage.

Yes, it was done using a JTAG.

>  > - Does the JTAG software claim that the "program and verify" worked
>  > properly?

Yes.

>  > - Are the Flash chips properly wired on the board?

Yes. Verified and reverified.

>  > - Did you set up the "_InitMemory" table in "hal_platform_setup.h" for
>  > the Flash chip(s). You need to set the base address, # wait states,
>  > etc.

I adapted them for the S29AL016D90TFI02:

	.long   0x100037B1  // NAND Flash, 2MB, 3 cycles after transfer, 
16-bit, 5 wait state
	.long   0x200037B1
	.long   0x300037B1
        .long   0x40002121  // RAM
...

Still the Spansion S29AL016D is NAND-Flash with a bottom boot block. So 
i am booting from NAND. Is this a problem as the ATMEL AT91M55800A 
should be capable of code shadowing?
Regarding the boot block of the NAND: Shouldn't it be XIP (execution in 
place) capable?


>  > Plus the base address for each CS line must be different, even if the
>  > CS
>  > is disabled.
> Indeed.
>
> I have a 64MB S29GL512, and use 4 chip-selects for it.
> Here is my "_InitMemory" code:
>
>         .long   0x1000352D  //NCS0 flash-1 , 16MB, 2 cycles after 
> transfer, 16-bit, 4 wait state
>         .long   0x1100352D  //NCS1 flash-2 , 16MB, 2 cycles after 
> transfer, 16-bit, 4 wait state
>         .long   0x1200352D  //NCS2 flash-3 , 16MB, 2 cycles after 
> transfer, 16-bit, 4 wait state
>         .long   0x1300352D  //NCS3 flash-4 , 16MB, 2 cycles after 
> transfer, 16-bit, 4 wait state
>         .long   0x06002121  //NCS4 IDT SRAM, 16MB, 0 cycles after 
> transfer, 16-bit, 1 wait state
>
> Starting from the eb55 port, I first used addresses 0x0100, 0x0200, 
> 0x0300 and 0x0400. But this did not work very well! I still don't know 
> why. The addresses 0x1000, 0x1100, .. worked, so I stopped my effort there.
>
>  > - You should be able to reset the CPU and single step through the first
>  > few instructions, using the JTAG and/or gdb. Remember that the chip
>  > starts with the first Flash (CS0) mapped to address zero. You can
>  > single
>  > step up to the point where the chip select registers are loaded and
>  > make
>  > sure that the values are being loaded properly.  But note that you
>  > can't
>  > step over the remap command since the debugger messes with the
>  > pipeline.
>  > - One of the first things that the assembly startup does is set the
>  > master clock (and maybe the PLL) running faster. If you set them
>  > running
>  > faster than the external board can support, the board may lock up.
>  >
>  >
>  > Whatever you're using to load the RAM debug code onto the board is
>  > initializing it properly (a JTAG initialization file?). Use that as a
>  > starting point. The only thing it isn't doing is setting up the Flash
>  > chip select registers in the EBI, so pay careful attention to that.
>  >
>  > Frank

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