Well, I think I see the problem. I have a 25VF080 connected to SPI0_NCS1. I had to add a chip ID to SAM-BA and recompile the serialflash code. At that point, I was able to communicate with the serial flash, using SAM-BA. I then recompiled the 9g20 nandflash version of the AT91 bootstrap file to turn on debug messages, and then loaded it to the serial memory. On boot I get two messages:

Start AT91Bootstrap...
-E- No NandFlash detected !!!

If I put this exact same bootstrap file on the NAND flash, the system boots to uboot properly.

What I think is happening is that the bootstrap program is not fully initializing the NAND Flash. The boot ROM checks memory in a certain order. The serial flash is checked before NAND Flash. If it finds the serial flash, it does not initialize the NAND flash. But if the boot ROM does not find the serial memory, it then initializes the NAND flash and tries to read it. So when the boot strap code is running from the serial flash, the NAND flash is not fully set up and therefore the ID cannot be read. Whereas when the bootstrap is run from NAND Flash, the boot ROM has set whatever the bootstrap missed and thus the system successfully communicates with the NAND Flash. Unfortunately the boot ROM code is not available to compare with the bootstrap to see if this is true.

I think that is not quite correct. We also modified the SamBa to be able to write to our serial flash. Then we run till the message "Start AT91Bootstrap...". When do not get tha NAND error. I don't understand why there should be a NAND error. Maybe just for the understanding: We have bootstrap, uboot and kernel in the serial flash. In the NAND there should only be thf filesystem. So the bootstrap has to load the uboot to RAM and the uboot has to load the kernel to RAM. No NAND access is necessary here. It is first needed under Linux. The problem we have is that the bootstrap is not able to read from the serial flash. Maybe you have only the bootstrap in the serial flash in your application. This is not the best idea imho because the first ECC NAND correction is available under Linux afaik. So till there everything has to be failsafe. Maybe someone can tell me if there really is an ECC correction implemented in the Linux filesystem cause I am not 100% sure about this.

Looking at the bootstrap code, I see nothing that supports a serial flash device, only DataFlash, NOR flash, and NAND flash. So if you are trying to use the dataflash bootstrap, the bootstrap will run only till it gets to the point where it tries to open the Dataflash and does not finds one. And there is no debug message in the code to tell you if no Dataflash is found. In fact, I would bet that you need to write your own serial flash driver in order to boot from serial flash. Try putting the following in the Dataflash.c code in the df_init process in the default section of "switch (dfcode)"

default:
#ifdef CFG_DEBUG
dbg_print("\n\r-E- No Flash detected !!!\n\r");
#endif
status = 0;
break;

Then you will at least get an error message if the flash is not detected.

Also, you may need to modify uboot to run from serial flash. According to the linux4sam website, there are two versions of uboot that they supply binaries for, NAND Flash and DataFlash. If you are trying to use the DataFlash version of uboot it may not work properly with a serial flash. For one thing, they use odd sized pages in a data flash, so file locations may not be the same. Dataflash also has page RAM internal that serial Flashpart do not.

This fits with my experiences.

Use the bootstrap loader from the software package, it has the serial flash support.

If you use the bootloader from the linux4sam or the 1.6 Atmel package it has no serial flash support.

Z,

Even if the bootloader works, a uboot serial flash implementation still has to be done.

U-boot has SPI serial flash support.

You have to add an extra line to drivers/mtd/spi/sst.c to support your chip.

Z.

Hello,
if the bootstrap located at the spi flash,
and starts uboot from the nand flash,
the problem with ecc than still exist or?

after which boot step is ecc enabled?
and what is the solution for this problem?
thx

Figured it out!! zoltan mentioned a bootstrap in the software package. I pulled down the 9g20 software package and there is a version of the bootstrap code that seems to use modules similar to the SAM-BA modules. Using this code, I was able to compile a serialflash bootstrap that loads and executes u-boot from the NAND flash. It looks like there is a EccNandFlash.c file in the package so maybe you can add ECC support, prinzenrolle. Check the file link below. There is a at91bootstrap-at91sam9g20.zip file in the zip file pointed to by the link. One thing I had to do was change the destination address from 0x20000000 to 0x23F00000.

http://www.atmel.com/dyn/resources/prod ... ck-1.8.zip

thx falingtrea for your answer.
but i ve som addional questions:

which module enables ecc (uboot/linux kernel)?

if the bootstrap located in the nand flash or spi,
after which boot step is ecc enabled?

how can you update the kernel or your custom program in the field?
if the bootstrap support no ecc, i cant customize the bootstrap to update the nand flash.
(update kernel)

thx for your answer!

All modules which do not implement ECC have to be in the serial flash plus the first module implementing ECC so it can safely load data from the NAND Flash.

I do not know if there is a bootstrap or uboot implementation supporting full ECC (Read and Write), which is needed.

thanks tkl for your answer.

i think the right/correct way is to implement ecc into the bootstrap routine.
have somebody did it?

where can i check if uboot and the kernel use ecc?

thx for your answer

As far as I can tell, the MTD drivers in Linux support ECC. So if you update your files from Linux, your files should have ECC. They typically use software ECC to stay consistant across systems. I also believe SAM-BA uses ECC for read and write, but I could be wrong. There is a EccNandFlash.c file in the applets\at91lib\memories\nandflash directory of SAM-BA. Since the bootstrap code in the software package seems to be using the same structure as SAM-BA, you may be able to use the EccNandFlash.c file in the bootstrap code. If you use a serial flash for the bootstrap then you only need ECC read capability in the bootstrap. I also checked uboot and the 2009-06 rc6 code I have has a nand_ecc module in the MTD driver section so it looks like uboot does some sort of ECC as well.

Which compiler did you use to compile the bootstrap?

We already tried different versions, but all builds failed:
- gcc-arm-angstrom-linux-gnueabi version 4.2.4
o Different errors in linker sections

- gcc version 4.2.0 Microcross GNU X
o Linkererror: region sram1 is full

- gcc arm-linux-uclibcgnueabi version 4.3.4

o Error: selected processor does not support ‘blx r0’

It seems, that the new version of the bootstrap highly depends on the std files coming with the software package and does not fit to the declarations coming with the compiler.

I used Code Sourcery G++ Lite ARM EABI Sourcery G++ Lite 2008q1-126 and the compiler arm-none-eabi-gcc-4.2.3.exe. I had to make a copy of the file and remove the -4.2.3 so it would work with the makefile. I also use the cs_make.exe to run the makefile. All from Windows XP. here is my command line, trace level 5 gave me more debug info:

cs-make CHIP=at91sam9g20 BOARD=at91sam9g20-ek ORIGIN=nandflash DESTINATION=sdram BIN_SIZE=0x31000 FROM_ADDR=0x20000 DEST_ADDR=0x23F00000 OP_BOOTSTRAP=on STR_DESCR=\\\"appli\\\" TRACE_LEVEL=5 clean all