This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Booting from Flash in a AT91M55800A based platform


Marc-Andrà Beck wrote:
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'
you need to add a flash driver. Redboot can not find a flash if the drivers are not compiled in...
Of course "There's no FLASH part: " ...
see at eb55. my /misc/redboot_rom.ecm looks so:
cdl_configuration eCos {
package CYGPKG_IO_FLASH current ;
package CYGPKG_DEVS_FLASH_[platform-name] current;
package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current;
};




As the flash (NAND) supports the JEDEC-standard, shouldn't it be accessible from RedBoot with a generic driver?
Spansion does not make NAND flashes, only NOR flashes. So you have a NOR flash. Yes, I know, the datasheet does not mention it, but then it is a NOR flash - if it would be a NAND flash, the datasheet would mention it. Or visit the spansion web-site... (datasheet via alldatasheet.com).

Yes, a generic driver.. Redboot still needs a low-level driver, in this case the devs/flash/amd/am29xxxxx/. -> 'package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX current;'
Spansion has taken over the flashes from AMD.
The datasheet also mentions that the S29AL016D is "Fully compatible with Am29LV160D and
MBM29LV160E devices" In devs/flash/amd/am29xxxxx/ only the T and B are present (not the D), but your flash has an ID of 0x49, so I would give it a try with the AM29LV160-B flash. Still, I would check with the datasheet if it is completely the same. If you don't understand something from the files in devs/flash/amd/am29xxxxx/, just ask.


Redboot also needs you to specify the root address. -> 'package CYGPKG_DEVS_FLASH_[platform-name] current;'




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
from the datasheet: bottom boot has ID 0x49
problem as the ATMEL AT91M55800A should be capable of code shadowing?
google explained to me what "code shadowing" is. In ecos, this is called ROMRAM mode: you boot from ROM, but then copy all binary to RAM (done in assembly in hal_platform_setup.h). You do this because an external NOR flash is very slow to execute code from; but I only do it for the application, not for redboot: redboot is executed from flash and then loads the application (in my case).
I would think your processor just needs RAM do be able to do code shadowing.
Even in ROM mode, the flash access functions are mapped into RAM in ecos.
Regarding the boot block of the NAND: Shouldn't it be XIP (execution in place) capable?
Indeed. but you have a NOR flash, so don't worry: in general a NOR flash is bootable or XIP, a NAND not.


 > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]