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

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

[Marc-André Beck]

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

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

[Frank Pagliughi]

Marc-André Beck wrote:
>
> No. while booting from RAM I only see the RAM. There's no FLASH part:
>
> RAM: 0x40000000-0x40080000, [0x4001f1e8-0x40034000] available
Are you testing a ROM/Flash boot or a RAM boot? If you're trying to 
debug apps from RAM you need to use your JTAG to configure the 
oscillator, PLL, and chip select registers before loading the 
application into memory.
>
>
>>  > - 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.

Ok. With the chips programmed and verified, you should be able to use 
the JTAG to reset the board and single step through the first few 
assembly instructions. Remember that it uses a base address of zero 
until it gets to the remap (stmia) instruction. And also remember that 
you can't use the JTAG to single-step over that instruction. There are 
two points where the system can easily get lost in here:
1. When it sets the clock frequency. If the board stops responding after 
you set the oscillator or PLL frequencies, then you've set them too fast 
for the board to support.
2. If the board doesn't make it past the remap command, then either the 
values in _InitMemory table are wrong, or your .text section is mapped 
to a different address than you think. To get past the remap command, 
set a breakpoint at the remapped address of the first instruction after 
the _InitMemory table (the symbol "10"), then 'go'.

If you get here, and can still single step, then things are good. You're 
running from Flash and your basic CPU initialization is correct. Now you 
can connect to the board with GDB/Insight and follow the debug with that.



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

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

[Jürgen Lambrecht]

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