I've created a custom circuit board with the AT91SAM9RL64 processor and the NAND16GW3F2AN6E flash from Numonyx/Micron. I believe that this flash has a 16 Gbit capacity. The datasheet can still be found here: http://www.numonyx.com/Documents/Datash ... GW3F2A.pdf.

I've attempted to use SAM-BA to start up this NAND flash, but the applet hangs when trying to retrieve bad block information. The following is the output from the DBGU when the applet attempts to load:

-I- -- NandFlash ISP applet 2.10 --
-I- -- AT91SAM9RL64-EK
-I- -- Compiled: Mar 25 2011 10:39:31 --
-I- INIT command
-D- SkipBlockNandFlash_Initialize()
-D- RawNandFlash_Initialize()
-D- RawNandFlash_Reset()
-D- No model provided, trying autodetection ...
-D- RawNandFlash_ReadId()
-I- Nandflash ID is 0xA651D520
-D- * deviceId = 0xD5
-D- * deviceSizeInMegaBytes = 4
-D- * blockSizeInkBytes = 8
-D- * pageSizeInBytes = 512
-D- * options = 0x00
-D- Retrieving bad block information ...
-D- RdPg(B#0:P#0)
-D- Block #0 is bad
-D- RdPg(B#1:P#0)
-D- Block #1 is bad
-D- RdPg(B#2:P#0)
-D- Block #2 is bad
-D- RdPg(B#3:P#0)
-D- Block #3 is bad
-D- RdPg(B#4:P#0)
-D- Block #4 is bad
-D- RdPg(B#5:P#0)
-D- Block #5 is bad
-D- RdPg(B#6:P#0)
-D- Block #6 is bad
-D- RdPg(B#7:P#0)
-D- Block #7 is bad
-D- RdPg(B#8:P#0)
-D- Block #8 is bad
-D- RdPg(B#9:P#0)
-D- Block #9 is bad
-D- RdPg(B#10:P#0)
-D- Block #10 is bad
-D- RdPg(B#11:P#0)
-D- Block #11 is bad
-D- RdPg(B#12:P#0)
-D- Block #12 is bad
-D- RdPg(B#13:P#0)
-D- Block #13 is bad
-D- RdPg(B#14:P#0)
-D- Block #14 is bad
-D- RdPg(B#15:P#0)
-D- Block #15 is bad
-D- RdPg(B#16:P#0)
-D- Block #16 is bad
-D- RdPg(B#17:P#0)
-D- Block #17 is bad
-D- RdPg(B#18:P#0)
-D- Block #18 is bad
-D- RdPg(B#19:P#0)
-D- Block #19 is bad
-D- RdPg(B#20:P#0)
-D- Block #20 is bad
-D- RdPg(B#21:P#0)

In the \SAM-BA v2.10\applets\at91lib\memories\nandflash\NandFlashModelList.c file, I've found a list of various supported memories, and I am wondering if this is the file that must be changed to make the Numonyx NAND flash work with SAM-BA.

I've attempted to add the following entry to the table of supported NAND flashes, but this doesn't seem to do anything.

{0xD5, NandFlashModel_DATABUS8 | OPTIONS, 0, 2048, 0, &nandSpareScheme2048}

What am I doing wrong, and what would I have to change to use this NAND flash with SAM-BA?

SAM-BA 2.7 has this entry, suggesting a 512 byte page, like the auto-detect

{0xd5, 4, 8192, 512, NandFlashModel_DATABUS8, &nandSpareScheme512},

Whilst the data sheet talks about 4096+128 byte pages, for which you don't have a scheme. And 256KB + 8K Block sizes.

Looking at SAM-BA 2.10, which has a 4096 scheme, it strikes me that the table entry will look like this.

{0xD5, NandFlashModel_DATABUS8 | OPTIONS, 0, 2048, 0, &nandSpareScheme4096}

Thank you very much for your response, CptTitanic; this is greatly appreciated!

I added the suggested line to the NAND flash table:

{0xD5, NandFlashModel_DATABUS8 | OPTIONS, 0, 2048, 0, &nandSpareScheme4096}

In the file \SAM-BA v2.10\applets\at91lib\memories\nandflash\NandFlashModelList.h, I had to change the size of the array, since I added another entry to the table:

#define NandFlashModelList_SIZE 59

However, when I attempt to start up NAND flash using SAM-BA, the autodetection scheme hangs; here is the output of the DBGU:

-I- -- NandFlash ISP applet 2.10 --
-I- -- AT91SAM9RL64-EK
-I- -- Compiled: Mar 26 2011 08:54:53 --
-I- INIT command
-D- SkipBlockNandFlash_Initialize()
-D- RawNandFlash_Initialize()
-D- RawNandFlash_Reset()
-D- No model provided, trying autodetection ...
-D- RawNandFlash_ReadId()
-I- Nandflash ID is 0xA651D520
-D- * deviceId = 0xD5
-D- * deviceSizeInMegaBytes = 4
-D- * blockSizeInkBytes = 8
-D- * pageSizeInBytes = 512
-D- * options = 0x00
-D- Retrieving bad block information ...
-D- RdPg(B#0:P#0)

It appears that no model has been provided. Do I have to change something in the code to bypass autodetection so that the entry in the NAND flash table is used?

Looking in the \applets\isp-project\nandflash\main.c file, it appears that the table of NAND flash parts is not being passed into the SkipBlockNandFlash_Initialize() function:

if (SkipBlockNandFlash_Initialize(&skipBlockNf,
0, // the table is not passed in here
cmdBytesAddr,
addrBytesAddr,
dataBytesAddr,
nfCePin,
nfRbPin)) {


So I replaced the above code with the following:

if (SkipBlockNandFlash_Initialize(&skipBlockNf,
nandFlashModelList,
cmdBytesAddr,
addrBytesAddr,
dataBytesAddr,
nfCePin,
nfRbPin)) {

In addition, I included the NAND flash model list at the top of the \applets\isp-project\nandflash\main.c source code listing:

#include <nandflash/NandFlashModelList.h>

The NAND flash applet still hangs after making these changes, but the NAND flash autodetect code is not being run:

-I- -- NandFlash ISP applet 2.10 --
-I- -- AT91SAM9RL64-EK
-I- -- Compiled: Mar 26 2011 09:55:16 --
-I- INIT command
-D- SkipBlockNandFlash_Initialize()
-D- RawNandFlash_Initialize()
-D- RawNandFlash_Reset()
-D- Retrieving bad block information ...
-D- RdPg(B#0:P#0)

I am now wondering if it is possible that the NAND flash is not supported by SAM-BA. Or perhaps I need to change something else in the source code?

Now if the NAND flash is not compatible with SAM-BA, would it be possible to do the following:

(1) Place AT91bootstrap in SPI Dataflash;
(2) Place U-boot in SPI Dataflash;
(3) Place the Linux kernel and filesystem on the NAND flash

I am using the 2 Mbit AT45DB021D SPI Dataflash from Atmel, and I believe that this does not have the space for the Linux kernel.

Personally, I think you need to review the NAND documentation, and make the required changes for SAM-BA to work. You're pretty much going to have to cross that bridge to get AT91BootStrap working, and understanding how your part works is always helpful.

You should be able to prove both AT91BootStrap, and uBoot, by loading and running them in SRAM and SDRAM respectively from SAM-BA. You wouldn't need to put them in any flash memory to prove there viability.

Thank you again for your response, CptTitanic.

I think that I've found another clue that helps to suggest what might be causing this issue. The NAND chip select pin was wired to NCS3-NANDCS (PB6) by a zero ohm jumper. I removed this zero ohm jumper and installed another jumper to a PIO (pin PD12).

Then, in the file \SAM-BA v2.10\applets\at91lib\boards\at91sam9rl-ek\board.h, I had to change the following defines for my own custom board:

#define BOARD_NF_CE_PIN {1 << 12, AT91C_BASE_PIOD, AT91C_ID_PIOD, PIO_OUTPUT_1, PIO_DEFAULT}

#define BOARD_NF_RB_PIN {1 << 9, AT91C_BASE_PIOD, AT91C_ID_PIOD, PIO_INPUT, PIO_PULLUP}

Remarkably, autodetection of the NAND memory now works well, but SAM-BA still reports that there are bad blocks, as shown by the DBGU output below:

-I- -- NandFlash ISP applet 2.10 --
-I- -- AT91SAM9RL64-EK
-I- -- Compiled: Mar 26 2011 15:18:55 --
-I- INIT command
-D- SkipBlockNandFlash_Initialize()
-D- RawNandFlash_Initialize()
-D- RawNandFlash_Reset()
-D- No model provided, trying autodetection ...
-D- RawNandFlash_ReadId()
-I- Nandflash ID is 0xA651D520
-D- Fetch from ID4(0xxA651D520
-D- * deviceId = 0xD5
-D- * deviceSizeInMegaBytes = 2048
-D- * blockSizeInkBytes = 256
-D- * pageSizeInBytes = 4096
-D- * options = 0x02
-D- Retrieving bad block information ...
-D- RdPg(B#0:P#0)
-D- Block #0 is bad
-D- RdPg(B#1:P#0)
-D- Block #1 is bad
-D- RdPg(B#2:P#0)
-D- Block #2 is bad
-D- RdPg(B#3:P#0)
-D- Block #3 is bad
-D- RdPg(B#4:P#0)
-D- Block #4 is bad
-D- RdPg(B#5:P#0)
-D- Block #5 is bad
-D- RdPg(B#6:P#0)
-D- Block #6 is bad
-D- RdPg(B#7:P#0)
-D- Block #7 is bad
-D- RdPg(B#8:P#0)
-D- Block #8 is bad
-D- RdPg(B#9:P#0)
-D- Block #9 is bad
-D- RdPg(B#10:P#0)
-D- Block #10 is bad
-D- RdPg(B#11:P#0)
-D- Block #11 is bad
-D- RdPg(B#12:P#0)
-D- Block #12 is bad
-D- RdPg(B#13:P#0)
-D- Block #13 is bad
-D- RdPg(B#14:P#0)
-D- Block #14 is bad
-D- RdPg(B#15:P#0)
-D- Block #15 is bad
-D- RdPg(B#16:P#0)
-D- Block #16 is bad
-D- RdPg(B#17:P#0)
-D- Block #17 is bad
-D- RdPg(B#18:P#0)

I think that the problem may be associated with the fact that the EBI CS3 (for NAND flash) is memory mapped to address 0x4000 0000, the size of which is 256MBytes.

However, the size of the NAND flash is 2 GBytes.

So there is a good possibility that these addresses in the file \SAM-BA v2.10\applets\at91lib\boards\at91sam9rl-ek\board.h may be incorrect for this particular NAND flash chip:

/// Address for transferring command bytes to the nandflash.
#define BOARD_NF_COMMAND_ADDR 0x40400000
/// Address for transferring address bytes to the nandflash.
#define BOARD_NF_ADDRESS_ADDR 0x40200000
/// Address for transferring data bytes to the nandflash.
#define BOARD_NF_DATA_ADDR 0x40000000

You access the NAND array like an IDE hard drive, you write the address you want to access into registers, and then pull out a block of data as a stream. It does not map into a linear block of memory, you cannot access it directly or run code from it. The fact it is 2GB is pretty much irrelevant to your issue here.

You should look at what data is in the 4K and 256K pages/blocks on the device now, to understand why the bad-checks are failing.

Thanks again for your very helpful suggestions, CptTitanic!

After some investigation, I strongly believe that the NAND flash is operating normally, and the bad checks are failing because the AT91lib (on which SAM-BA is based) does not support this type of flash with large pages. There is a possibility that SAM-BA needs to be modified. The modification could be done along the lines of another thread (viewtopic.php/f,9/t,19290/). At this time, I am uncertain with respect to what I need to change in the code to be able to get this up and running.

However, all is not lost, since I loaded At91bootstrap to an external Atmel SPI Dataflash (AT45DB021D). The At91bootstrap was then used to load U-Boot, which was also loaded to the Dataflash. I will then be able to copy the Linux kernel to the NAND flash using U-Boot. Consequently, U-Boot should be able to boot the kernel from the NAND flash.

To add support for the AT45DB021D on my custom board, I had to un-comment a section of code in the /Bootstrap-v1.16/driver/dataflash.c file. This section of code had possibly been commented out by a programmer at Atmel, who found that adding it would cause the size of the binary to be larger than 4k. However, without including this code, At91bootstrap refuses to copy the U-Boot binary from Dataflash to SDRAM.

I modified the Makefile of At91bootstrap to use the CodeSourcery arm-none-linux-gnueabi-gcc toolchain. I then compiled At91bootstrap using this toolchain. On Windows 7 (64-bit), I had to use the MSYS compilation environment from the MinGW toolchain.

I also modified the crt0_gnu.S assembler file to bypass the main crystal oscillator, since my custom circuit board uses an external clock instead of a crystal. This entailed commenting out and changing the following line of code in the _enable_mosc function:

/*ldr r2,=AT91C_CKGR_MOSCEN*/
/*This code modified to bypass the main oscillator*/
ldr r2,=AT91C_CKGR_OSCBYPASS

I then used SAM-BA to send the boot file to Dataflash using the SAM-ICE. To ensure that the file was transferred correctly, I had to use the "Send boot file" option in the SAM-BA GUI. I believe that this is required since the SAM-BA boot ROM program looks for ARM interrupt vectors at the beginning of the flash memory, and one of these vectors is automatically modified by the SAM-BA scripts.

I then modified the U-Boot 2010.09 sources for my custom board. Most importantly, I updated this definition for my custom board (found in the header file /include/configs/at91sam9rlek.h):

#define CONFIG_SYS_NAND_READY_PIN AT91_PIN_PD9

I couldn't use the most recent version of U-Boot since various changes have been implemented that prevents code for the AT91SAM9RL-EK evaluation board from compiling without errors. Searching the mailing lists, it appears that the AT91 evaluation board code is slowly being fixed. However, the U-Boot 2010.09 sources works well for me. I used the arm-none-linux-gnueabi-gcc toolchain running on Ubuntu Linux 10.10 to compile U-Boot.

Using the SAM-BA GUI and the SAM-ICE on Windows XP, I loaded the U-Boot .bin file to address 0x8400 on Dataflash.

Correspondingly, I had to update the AT91bootstrap code with the appropriate image address and image size:

#define IMG_ADDRESS 0x8400 /* Image Address in DataFlash */
#define IMG_SIZE 0x1AE34

I then replaced the NAND flash chip select jumper to NCS3-NANDCS (port pin PB6).

Booting the processor, I was then able to load U-Boot and examine NAND flash. As U-Boot shows, there appears to be nothing wrong with NAND flash, and I can examine the bad blocks. Note that I've added some additional debug messages to the AT91bootstrap code:

RomBOOT
>Start AT91Bootstrap...
Loading from dataflash
Jumping to address
Serial hardware up


U-Boot 2010.09 (Mar 27 2011 - 18:04:56)

DRAM: 64 MiB
NAND: 2048 MiB
DataFlash:AT45DB021
Nb pages: 1024
Page Size: 264
Size= 270336 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C00041FF (RO) Bootstrap
Area 1: C0004200 to C00083FF Environment
Area 2: C0008400 to C0041FFF (RO) U-Boot
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
Outside available DataFlash
Wrong Image Format for bootm command
ERROR: can't get kernel image!
U-Boot> nand info

Device 0: NAND 2GiB 3,3V 8-bit, sector size 256 KiB
U-Boot> nand device

Device 0: NAND 2GiB 3,3V 8-bit, sector size 256 KiB
U-Boot> nand bad

Device 0 bad blocks:
01040000
0fd80000
121c0000
20600000
27a00000
27b00000
30740000
343c0000
3b080000
46900000
49a00000
4b1c0000
52180000
52200000
7f540000
U-Boot>


Also from U-Boot, I was able to fully erase NAND flash.

So in closing, although I am still uncertain as to what I should change in the SAM-BA code to be able to support this particular NAND flash, I know that I can indeed access it through U-Boot.

Moreover, to boot with SPI Dataflash is perhaps more reliable. To completely boot from NAND flash requires an error-free page 0, and this may make the part more difficult to obtain.

For me, this solution works well, but I am now more certain that the inability to read this NAND flash is associated with the AT91lib.

(Switching between various operating systems was made much easier by the VirtualBox software.)