i.mx53 Booting from NAND flash using kobs-ng

[MarkRoy]

Hey folks,

So I've been having some difficulties getting my board to boot from NAND. 

I have a working customized u-boot that I can load and run just fine using the serial loader or through JTAG.  

I have burned the fuses on to the i.mx536 to boot from NAND as follows:

0x80C BOOT_CFG1 = 0xC8 (boot from nand on EIM pins, no interleaving, 5 address cycles)  

0x810 BOOT_CFG2 = 0x80 (4KB + 128B with 4-bit ECC, 8-bit bus width,  AXI = DDR / 12)

0x814 BOOT_CFG3 = 0x02 (stride size = 1 block, non LBA, no R/B signals,  automatic ECC, 64 pages / block)

0x804 BT_FUSE_SEL = 1

With these settings,  I have previously hooked up my oscilloscopes digital signal inputs to the bus and I can see that the ROM appears to be correctly reading at least some of the data.

To write my u-boot to flash, I am use the following command on a pretty much virgin nand flash chip:

kobs-ng init -v u-boot.imx 

This command completes and if I do a hexdump of  /dev/mtd0 I see what looks like sensible data.

After rebooting the board to attempt to boot from flash,  it seems like the ROM is loading the image and possibly attempting to run it,  but I get no output on my serial console and it doesn't seem to boot.  It also does not fall back to the serial boot, which seems to indicate that it is finding what it thinks is a valid image and attempting to run it unsuccessfully.   

The strange thing is that when I connect my JTAG to the board that has tried to boot from flash, I cant get it to halt.   The only way I can get it to boot again is to switch from Boot Mode 10 to boot mode 11 which allows me to serial boot again.   Once booted if I go in and erase the flash and try to boot again from NAND, the ROM functions correctly and falls through to the serial boot when it doesn't find a valid FCB.

I suspect it might have something to do with the DCD.   When I am booting from serial or from the JTAG,  it first loads the DCD from the u-boot image and then loads the actual image into memory where it can then execute.   How does this happen during NAND flash boot?  How can the ROM load the program image to DDR memory when the memory has yet to be initialized?

[dioneva_k]

My board boots from NAND, but hangs on startup as shown below:

U-Boot 2019.10-g5d9e602-dirty (Feb 19 2020 - 13:06:47 -0300)

CPU: Freescale i.MX53 rev2.1 at 800 MHz
Reset cause: POR
Board: i.MX53 TV
I2C: ready
DRAM: 1 GiB

Does anyone know why?

[MarkRoy]

Looking around at some other threads such as these:

MX53 NAND MT29F16G08ADACAH4-IT boot problem

How to boot i.MX53 from Nand?

It seems that it might be a problem with ROM support for the flash chip?   I am currently attempting to use the MT29F16G08ADBCA and I have had to make quite a few changes to the drivers in both U-Boot and Linux to get this to work well, but it seems to be working fine using 128B oob (4-bit ECC) in both the kernel and u-boot.   Some of the changes I had to make are to do with the larger chip size.  

The u-boot.imx image looks like this:

00000000  d1 00 20 40 00 00 80 77  00 00 00 00 2c f4 7f 77  |.. @...w....,..w|

00000010  20 f4 7f 77 00 f4 7f 77  00 00 00 00 00 00 00 00  | ..w...w........|

00000020  00 f0 7f 77 00 90 07 00  00 00 00 00 d2 01 a0 40  |...w...........@|

00000030  cc 01 9c 04 53 fa 85 54  00 30 00 00 53 fa 85 58  |....S..T.0..S..X|

00000040  00 30 00 40 53 fa 85 60  00 30 00 00 53 fa 85 64  |.0.@S..`.0..S..d|

00000050  00 30 00 40 53 fa 85 68  00 30 00 40 53 fa 85 70  |.0.@S..h.0.@S..p|

....

I am wondering if there is a problem with the addresses provided in the program image. 

It looks to me like the IVT is:

entry =  0x77800000

reserved 1 = 0x00000000

dcd = 0x777FF42C

boot_data = 0x777FF420

self = 0x777FF400

csf = 0x00000000

reserved 2 = 0x00000000

The odd thing about this is the 777FF000 offset that it seems to be adding to the data.   This is placed squarely in the DDR sdram, which to my understanding has not been initialized at this point.  So is it just trying to copy the image into a black hole of unitialized DDR and then tripping over the DCD?

In u-boot, it has CONFIG_SYS_TEXT_BASE set to 0x77800000.  This may be where the 0x777FF400 address comes from (which is preciesly 0xC00 less than 0x77800000).  

Does this mean that maybe I should modify CONFIG_SYS_TEXT_BASE so that the vectors are all located within internal ram ?  However, if I need to load it first into internal ram, then my boot image is too large and I might need to go to an SPL boot or something.

[MarkRoy · Accepted solution]

I seem to have solved it.

The issue was that the kobs-ng tool does not add the appropriate 0x400 offset to the program image when burning it to flash.  To fix this was as simple as using dd to add an offset to the image before sending it to kobs-ng.  

ie:

$ dd if=u-boot.imx of=u-boot-offset.imx bs=512 seek=2

$ kobs-ng init -v u-boot-offset.imx

Note, I also had to modify kobs-ng and also the linux kernel to support 4K pages.  This was because my ECC configuration has 72 eccpos bytes whereas the old nand_oobinfo struct in mtd-abi.h only has 32 bytes for this.  I modified mtd-abi.h to include 128 bytes so that  the legacy IOCTL MEMGETOOBSEL works correctly for kobs-ng.    This has to be changed in two places, in the mtd-abi.h located in the kernel and also in the mtd-abi.h located with the compiler.  I'm not sure why LTIB doesnt build kobs-ng against the linux kernel includes.

[jaganteki]

Hi,
I'm experience an ioctl issue with kobs-ng 3 while working 4.8 and I'm trying to build 5.4 but couldn't do that either any help?

chip_0_device_path = "/dev/mtd0"
  chip_1_device_path = "(null)"
  search_exponent = 2
  data_setup_time = 80
  data_hold_time = 60
  address_setup_time = 25
  data_sample_time = 6
  row_address_size = 3
  column_address_size = 2
  read_command_code1 = 0
  read_command_code2 = 48
  boot_stream_major_version = 1
  boot_stream_minor_version = 0
  boot_stream_sub_version = 0
  ncb_version = 3
  boot_stream_1_address = 0
  boot_stream_2_address = 0
         -- We add the 1k-padding to the uboot.
.tmp_kobs_ng: verifying using key '00000000000000000000000000000000'
.tmp_kobs_ng: is a valid bootstream for key '00000000000000000000000000000000'
mtd: opening: "/dev/mtd0"
mtd: device /dev/mtd0 can't ioctl MEMGETOOBSEL: -1
Unable to open mtd device(s)

[GopiNagaBharath]

Hello,

I am also trying to boot our i.MX53 Linux based system from NAND Flash K9LBG08U0D (4K page size, 128 pages per block) . It is interfaced on the EIM Data pins and the boot mode pins are set accordingly to boot from NAND device.

We have written the u-boot image to NAND device by booting the linux from SD card and using the kobs-ng command. We have done nand dump and verified that the FCB is added by the kobs-ng while writing the image. The board was unable to boot from NAND device. By probing the NAND pins, i was able to know that the controller is accessing NAND device on CS0.

We have also added offset in the u-boot file by using the dd command as per your suggestions above. But still we were unable to get this running.

Do you have any idea what could be the issue? Also, would you please let me know what are changes necessary changes which you have made in kobs-ng & u-boot sourced?

Thanks in advance !

[MarkRoy]

Sorry for the late reply.   Hopefully you have figured out your problem by now.

If you haven't, then all I can think for you to try is to make sure that your u-boot image is working by loading it via serial,  also make sure that your nand and ECC is working correctly by reading/writing to NAND and verifying that it is correct.  

Finally, you might be having an issue with your NAND driver/ECC.   I had to make some changes and do some debugging to get NAND ECC to work correctly.   Note that your nand  ECC fuses must be set exactly the same as the ECC settings in the kernel.    If the kernel is writing/checking ECC one way and the boot ROM is doing it another way, then it may not be reading the data back correctly from the ROM.  

Also, when you try to boot from flash, does it just hang or does it fall back to the serial boot?  If it falls back to the serial boot mode then it means that the ROM wasn't able to get a proper image and it gave up.  If it just hangs, then it means the boot ROM found what it thinks is a good image and tries to boot it but the image is bad and it fails.

If you have figured it out, please post your solution here so that others with the same problem in the future might be able to fix the problem.

Best Regards,

Mark Roy