Unable to boot from NAND with mainline u-boot and custom iMX28 board

1,545 Views

Struggling with this one. I can boot Linux from SD card with no problem and boot from the USB recover port etc. but no matter what I do I can't seem to get the board to boot from NAND flash. I'm using a normal geometry Spansion NAND (2048/64/131072) which I can read and write to perfectly adequately from u-boot. Using the 'mxsboot nand u-boot.sb u-boot.sd' to generate the NAND image and then using u-boot 'update_nand_firmware_full' appears to do everything it is supposed to, including making bad blocks as the nand write.raw bit is used in the script. I have checked the boot pins settings to make sure they are set to NAND 3v3, but restarting the board zippo.

Has anyone successfully managed to get the NAND boot working using the u-boot and mxsboot tools? I'm going to try to port kobs-ng into mainline Linux 2.19.8 which I'm currently using but don't like that approach much.

Any help of hints gratefully appreciated.

4 Replies

1,022 Views

Having now got the nand boot and just about everything on the custom iMX287 board working perfectly with mainline Linux kernel 3.19.8 and u-boot 2015.04, there is still one nagging problem with programming the nand boot from within Linux. Using the Freescale BSP kobs-ng tool for the imx28evk board fails as the mainlilne kernel uses the nand_gpmi driver rather than the nand_mil_nfc drivers, so it doesn't publish the geometry in the procfs pool. I used kobs-ng-3.0.35-4.0.0 from the imx6q BSP, which calculates the geometry if the procfs tag is missing, and it appears to understand the device and write the FDT, DBBT and boot code correctly to the nand (within itself) but still no boot. The hexdump /dev/mtd0 view looks right, but a nand dump 0 shows an additional 10 bytes of data at the start of the nand.

hexdump /dev/mtd0

# hexdump /dev/mtd0

0000000 0000 0000 0000 0000 0000 0000 fb12 ffff

0000010 4346 2042 0000 0100 3c50 0619 0000 0000

0000020 0800 0000 0840 0000 0040 0000 0000 0000

0000030 0000 0000 0000 0000 0004 0000 0200 0000

0000040 0200 0000 0004 0000 000a 0000 0003 0000

0000050 0000 0000 0000 0000 0000 0000 0000 0000

u-boot nand dump 0

=> nand dump 0

Page 00000000 dump:

00 ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00

00 00 00 00 00 00 12 fb ff ff 46 43 42 20 00 00

00 01 50 3c 19 06 00 00 00 00 00 08 00 00 40 08

00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 04 00 00 00 00 02 00 00 00 02 00 00 04 00

Any clues?

1,022 Views

Found someone already answered this latest little problem.

The post at https://community.freescale.com/thread/355464 shows that the nand_gpmi driver was modified by 3.19.8 to remove raw access to the nand device (why, I have no idea). Copying the nand_gpmi drivers from the linux 3.14.28 build resolved the issue.

1,022 Views

Found the solution to the problem was a missing 47k pullup resistor on the GPMI_RDY0 and GPMI_CE0 leads. I had modified the u-boot SPL code to add an internal pullup which got u-boot working with the nand, but obviously (to me now) that isn't in effect when the bootrom is attempting. I blew the OCOTP fuse

ENABLE_NAND0_CE_RDY_PULLUP and all works well now. Will add the physical resistors for the next build to save having to blow fuses during manufacture.