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

["Jürgen Lambrecht" <J.Lambrecht@televic.com>]

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