We have developed a board based on the Mx53 which can boot from NAND or from SD chaging some switches. There are two different models of this board, one with 1 GByte of NAND flash and the other one with 2 GByte of NAND flash.
The 1 GByte model uses the NAND chip MT29F8G08ABACAH4-IT:C and the 2 GByte model the MT29F16G08ADACAH4-IT.
We use NAND boot mode without bit swapping, so the flash header first 1024 bytes are like that for both NANDs:
hexdump -C -n 1024 ../../build/uboot/u-boot.bin
00000000 7e 01 00 ea 46 43 42 20 01 00 00 00 00 00 00 00 |~...FCB ........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400
And before flashing the u-boot to the NAND we disable bad blocks and bit swapping:
echo 1 > /sys/devices/platform/mxc_nandv2_flash.0/ignorebad
echo 1 > /sys/devices/platform/mxc_nandv2_flash.0/disable_bi_swap
flash_eraseall /dev/mtd0
dd if=u-boot.bin of=/dev/mtdblock0 bs=1024
echo 0 > /sys/devices/platform/mxc_nandv2_flash.0/ignorebad
echo 0 > /sys/devices/platform/mxc_nandv2_flash.0/disable_bi_swap
As the 2GByte chip was not supported by freescale BSP we have to add it to nand_device_info.c:
{
.end_of_table = false,
.manufacturer_code = 0x2c,
.device_code = 0xd5,
.cell_technology = NAND_DEVICE_CELL_TECH_SLC,
.chip_size_in_bytes = 2LL*SZ_1G,
.block_size_in_pages = 64,
.page_total_size_in_bytes = 4*SZ_1K + 224,
.ecc_strength_in_bits = 8,
.ecc_size_in_bytes = 512,
.data_setup_in_ns = 25,
.data_hold_in_ns = 15,
.address_setup_in_ns = 10,
.gpmi_sample_delay_in_ns = 6,
.tREA_in_ns = -1,
.tRLOH_in_ns = -1,
.tRHOH_in_ns = -1,
"MT29F16G08FABWG",
},
Both models boot ok from the SD, and we can write/read the flash without any problem, so we boot from SD and flash the NAND with the u-boot, kernel, filesystem ... We check that with both models we write and read ok using hexdump and cmp linux shell utilities.
When we try to boot the card from NAND the 1GByte model boots perfectly well, but the 2 GByte model does not even start to executing the u-boot code (check that with a BDI3000). We see nothing coming from the serial port. We think that the boot ROM code is finding some problem reading the u-boot from the 2GByte chip.
These are the boot pin settings we have for the 2GByte model:
BOOT_CFG1[7] ==> "1" boot from nand
BOOT_CFG1[6] ==> "0" PATA pads
BOOT_CFG1[5:4] ==> "00" No interleaving
BOOT_CFG1[3:2] ==> "10" 5 address cycles
BOOT_CFG2[7:6] ==> "11" 4KBytes + 218 the NAND chips has 224 but this option is not available
BOOT_CFG2[5] ==> "0" 8 bit bus width
BOOT_CFG2[5] ==> "0" AXI DDR divide by two
BOOT_CFG3[7] ==> "0" 1 block
BOOT_CFG3[6] ==> "0" Non LBA
BOOT_CFG3[5] ==> "1" Use R/B signal
BOOT_CFG3[4:3] ==> "11" ECC off
BOOT_CFG3[2:1] ==> "01" 64 pages in block
Has anyone tried booting the Mx53 with this NAND chip?
We think it should be able to boot from this chip, just a point, the chip has 224 oob size but Mx53 just has the option to use 218 may be this can be the problem?
Has anyone used a 2GByte NAND BGA 3.3 V chip to boot the MX53 so we can use it instead of this one?
Best Regards, Pedro
Your page size should be 128.
Pedro have you been successfully booting from the MT29F16G08ADACAH$-IT? We are using the MT29F16G08ABACAWP without any luck. Our platform has no issues with booting from the MT29F2G08ABABAWP but refuses to boot from the larger part.
We had to make changes in kobs-ng and mutiple other pieces of software and were still having issues.
Interesting. I am having problems booting with MT29F8G08ADADAH4 but I can boot with MT29F1G08ABADAH4 just fine. I dug through the kobs-ng file and noticed that in the mtd.c file there are several rom inits. In v0_rom_mtd_init there is a setting for dies per chip and planes per die. On the bigger chip these are both 2. But the rom init used by the imx53 is v2_rom_mtd_init which has no such selection. I don't know if this is an issue or not. The NAND is fine as I can put Linux in it and run the Linux image. From Linux I write out the uboot image and it verifies. From serial uboot I can read the FCBs and the image and they read fine. So I am assuming that the imx53 ROM boot is having an issue dealing with the chip geometry.
Since I recompiled kobs-ng to try something out, the compiler informed me of a potential bug:
My compiler reported a warning when compiling kobs-ng-11.09.01:
mtd.c:787:37: warning: array subscript is above array bounds [-Warray-bounds]
In mtd.c in function mtd_open on that line is the following check:
if (md->part[1].fd >= 0 && md->part[2].fd >=0)
The declaration of the variable at the beginning of the function is:
struct mtd_data *md;
I checked for the declaration of the structure and its in mtd.h:
struct mtd_data {
struct mtd_part part[2];
So there array in question has 2 elements. The if check is checking elements 1 and 2. Perhaps it should be checking elements 0 and 1. Nowhere else in the code is element 2 referred to.
So I assume the intended check should be:
if (md->part[0].fd >= 0 && md->part[1].fd >=0)
Just in case anyone has found the same problem,
We had a couple of days to work on this matter and finally found what was happening. You should never put OOB to 224 even if your NAND has that OOB space because the Mx53 just supports 218. If you use 224 you can write and read properly from linux userspace but you would not be able to boot from the NAND.
Besides if you use 224 and after that change to 218 make sure to delete all the NAND with the nand scrub uboot command.
Once you use 218 OOB with a 4KByte page the mxc nand driver will always use 16 bit ecc strength error code, no matter what you put in the nand_devices_info table.
Hope this helps to someone!