i.MX6Q NAND boot issues - once more...

[mahi]

Hi Community,

I know there are many threads about this topic here, but I couldn't find a solution yet. My board always goes into serial download mode.

NAND Flash device is a Micron MT29F2G08ABBGAH4-IT:G.

Bootstream is written with kobs-ng init -x -v -w --chip_0_device_path=/dev/mtd0 $FILE without problems - see log below.

I ran several passes of nandtest (mtd-utils) without errors.

Boot configuration is done via pins:

BootMode[1:0] = 0b10
BOOT_CFG1[7:0] = 0b10000000
BOOT_CFG2[7:0] = 0b00000010
BOOT_CFG3[7:0] = 0b00000000
BOOT_CFG4[7:0] = 0b00000000

Perhaps someone can interpret the bootlog for me:

J-Link>mem32 0xd0 4
000000D0 = 0000724B 00902190 F8524A23 68000020
J-Link>mem 0x902190 100
00902190 = 02 00 01 00 F0 00 02 00 00 00 03 00 00 00 04 00
009021A0 = 01 00 05 00 00 00 06 00 00 00 07 00 F0 00 07 00
009021B0 = 00 00 08 00 00 05 00 00 F0 00 08 00 00 00 08 00
009021C0 = 02 05 00 00 33 00 08 00 00 00 09 00 33 1E 0A 00
009021D0 = FF 1F 06 00 00 00 0C 00 00 00 00 00 00 00 00 00
009021E0 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
009021F0 = 00 00 ...

The only thing I found, is that the Fingerprint of the FCB has offset 6 instead of 4, but there is another post in this community, where this is also the case, but not mentioned as issue. Running kobs-ng dump tells me "fingerprints mismatch" for all the FCBs and DBBTs and doesn't find NCBs.

All copies at 0x00000, 0x20000, 0x40000, 0x60000 look identical.

bash-4.3# hexdump -n 256 -s 0x00000 -C /dev/mtd0
00000000  00 00 1b fc ff ff 46 43  42 20 00 00 00 01 50 3c  |......FCB ....P<|
00000010  19 06 00 00 00 00 00 08  00 00 80 08 00 00 40 00  |..............@.|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 00  |................|
00000030  00 00 00 02 00 00 00 02  00 00 04 00 00 00 0a 00  |................|
00000040  00 00 03 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 02 00 00 00 05  |................|
00000070  00 00 3e 01 00 00 3e 01  00 00 00 01 00 00 cf 07  |..>...>.........|
00000080  00 00 00 00 00 00 00 08  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100

U-Boot has 1k offset, is that correct? Running kobs-ng without -x writes without the offset, but it is not booting as well.

bash-4.3#  hexdump -n 1280 -s 0x100000 -C /dev/mtd0
00100000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100400  d1 00 20 40 00 00 80 17  00 00 00 00 2c f4 7f 17  |.. @........,...|
00100410  20 f4 7f 17 00 f4 7f 17  00 00 00 00 00 00 00 00  | ...............|
00100420  00 f0 7f 17 00 f0 09 00  00 00 00 00 d2 03 00 40  |...............@|
00100430  cc 02 fc 04 02 0e 07 98  00 0c 00 00 02 0e 07 58  |...............X|

Any ideas?

Best regards

 Martin

kobs-ng log:

UTP: executing "kobs-ng init -x -v -w --chip_0_device_path=/dev/mtd0 $FILE"
MTD CONFIG:
  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: use new bch layout raw access mode
mtd: opening: "/dev/mtd0"
NFC geometry :
        ECC Strength       : 8
        Page Size in Bytes : 2110
        Metadata size      : 10
        ECC Chunk Size in byte : 512
        ECC Chunk count        : 4
        Block Mark Byte Offset : 1999
        Block Mark Bit Offset  : 0
====================================================
mtd: opened '/dev/mtd0' - '(null)'
mtd: max_boot_stream_size_in_bytes = 1572864
mtd: boot_stream_size_in_bytes = 651264
mtd: boot_stream_size_in_pages = 318
mtd: #1 0x00100000 - 0x00280000 (0x0019f000)
mtd: #2 0x00280000 - 0x00400000 (0x0031f000)
FCB
  m_u32Checksum = 0x00000000
  m_u32FingerPrint = 0x20424346
  m_u32Version = 0x01000000
  m_NANDTiming.m_u8DataSetup = 80
  m_NANDTiming.m_u8DataHold = 60
  m_NANDTiming.m_u8AddressSetup = 25
  m_NANDTiming.m_u8DSAMPLE_TIME = 6
  m_u32PageDataSize = 2048
  m_u32TotalPageSize = 2176
  m_u32SectorsPerBlock = 64
  m_u32NumberOfNANDs = 0
  m_u32TotalInternalDie = 0
  m_u32CellType = 0
  m_u32EccBlockNEccType = 4
  m_u32EccBlock0Size = 512
  m_u32EccBlockNSize = 512
  m_u32EccBlock0EccType = 4
  m_u32MetadataBytes = 10
  m_u32NumEccBlocksPerPage = 3
  m_u32EccBlockNEccLevelSDK = 0
  m_u32EccBlock0SizeSDK = 0
  m_u32EccBlockNSizeSDK = 0
  m_u32EccBlock0EccLevelSDK = 0
  m_u32NumEccBlocksPerPageSDK = 0
  m_u32MetadataBytesSDK = 0
  m_u32EraseThreshold = 0
  m_u32Firmware1_startingPage = 512
  m_u32Firmware2_startingPage = 1280
  m_u32PagesInFirmware1 = 318
  m_u32PagesInFirmware2 = 318
  m_u32DBBTSearchAreaStartAddress = 256
  m_u32BadBlockMarkerByte = 1999
  m_u32BadBlockMarkerStartBit = 0
  m_u32BBMarkerPhysicalOffset = 2048
  m_u32BCHType = 0
  m_NANDTMTiming.m_u32TMTiming2_ReadLatency = 0
  m_NANDTMTiming.m_u32TMTiming2_PreambleDelay = 0
  m_NANDTMTiming.m_u32TMTiming2_CEDelay = 0
  m_NANDTMTiming.m_u32TMTiming2_PostambleDelay = 0
  m_NANDTMTiming.m_u32TMTiming2_CmdAddPause = 0
  m_NANDTMTiming.m_u32TMTiming2_DataPause = 0
  m_NANDTMTiming.m_u32TMSpeed = 0
  m_NANDTMTiming.m_u32TMTiming1_BusyTimeout = 0
  m_u32DISBBM = 0
  m_u32BBMarkerPhysicalOffsetInSpareData = 0
DBBT
  m_u32Checksum = 0x00000000
  m_u32FingerPrint = 0x54424244
  m_u32Version = 0x01000000
  m_u32DBBTNumOfPages = 0
Firmware: image #0 @ 0x100000 size 0x9f000 - available 0x180000
Firmware: image #1 @ 0x280000 size 0x9f000 - available 0x180000
-------------- Start to write the [ FCB ] -----
mtd: erasing @0:0x0-0x20000
mtd: Writing FCB0 [ @0:0x0 ] (880) *
mtd: erasing @0:0x20000-0x40000
mtd: Writing FCB1 [ @0:0x20000 ] (880) *
mtd: erasing @0:0x40000-0x60000
mtd: Writing FCB2 [ @0:0x40000 ] (880) *
mtd: erasing @0:0x60000-0x80000
mtd: Writing FCB3 [ @0:0x60000 ] (880) *
mtd_commit_bcb(FCB): status 0

-------------- Start to write the [ DBBT ] -----
mtd: erasing @0:0x80000-0xa0000
mtd: Writing DBBT0 [ @0:0x80000 ] (800) *
mtd: erasing @0:0xa0000-0xc0000
mtd: Writing DBBT1 [ @0:0xa0000 ] (800) *
mtd: erasing @0:0xc0000-0xe0000
mtd: Writing DBBT2 [ @0:0xc0000 ] (800) *
mtd: erasing @0:0xe0000-0x100000
mtd: Writing DBBT3 [ @0:0xe0000 ] (800) *
mtd_commit_bcb(DBBT): status 0

---------- Start to write the [ .tmp_kobs_ng ]----
mtd: Writting .tmp_kobs_ng: #0 @0: 0x00100000 - 0x0019f000
mtd: erasing @0:0x100000-0x120000
mtd: erasing @0:0x120000-0x140000
mtd: erasing @0:0x140000-0x160000
mtd: erasing @0:0x160000-0x180000
mtd: erasing @0:0x180000-0x1a0000
mtd: We write one page for save guard. *
mtd: Writting .tmp_kobs_ng: #1 @0: 0x00280000 - 0x0031f000
mtd: erasing @0:0x280000-0x2a0000
mtd: erasing @0:0x2a0000-0x2c0000
mtd: erasing @0:0x2c0000-0x2e0000
mtd: erasing @0:0x2e0000-0x300000
mtd: erasing @0:0x300000-0x320000
mtd: We write one page for save guard. *
UTP: sending Success to kernel for command $ kobs-ng init -x -v -w --chip_0_device_path=/dev/mtd0 $FILE.

[igorpadykov]

Hi Martin

right, U-Boot has 1k offset, that is Image Vector Table Offset is 0x400.

Recommended to use mfg tool for nand programming from link

i.MX Software|NXP 

Also one can attach jtach debugger and check 0x907400 (ROM uses 0x907000 as starting address),

you should see your IVT header here if the NAND access is ok.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mahi]

Hi Igor,

just had a look with the debugger... IVT is there:

J-Link>mem8 907400 200
00907400 = D1 00 20 40 00 00 80 17 00 00 00 00 2C F4 7F 17
00907410 = 20 F4 7F 17 00 F4 7F 17 00 00 00 00 00 00 00 00
00907420 = 00 F0 7F 17 00 F0 09 00 00 00 00 00 D2 03 00 40
00907430 = CC 02 FC 04 02 0E 07 98 00 0C 00 00 02 0E 07 58
00907440 = 00 00 00 00 02 0E 05 88 00 00 00 28 02 0E 05 94
00907450 = 00 00 00 28 02 0E 05 90 00 00 30 00 02 0E 05 98
00907460 = 00 00 30 00 02 0E 05 6C 00 00 00 28 02 0E 05 78

...

It is identical to the contents of my uboot.imx file (at least 0x907400 to 0x907FFF).

When loading the same u-boot.imx with imx-usb, it is running. Only from NAND, it doesn't work...

Any ideas?

Best regards

 Martin

[igorpadykov]

Hi  Martin

one can try to create very small image, for example just toggle gpio or

output symbol from uart, place first in OCRAM then DDR, check if this works.

Best regards
igor

[mahi]

Hi Igor,

OK, I will try to get in touch with the bare-metal SDK...

Right now I started u-boot via usb-imx and from there loaded and started the Linux kernel, dtb and rootfs from NAND without issues.

So my only problem is u-boot not starting from NAND...

Best regards

 Martin

[mahi]

I finally found it... There was an error in my DCD. Due to a typo, GPMI-clock configuration was invalid.

Nevertheless, thanks for the support!

[jianansun]

Hi  Martin,  I have the same problem as you. How did you solve it? Thank you for your help.

[mahi]

Hi Jianan,

unfortunately I cannot really remember the issue - it is more than a year ago and my first commit in our git was after successfully booting for the first time.

Either the cause was an error in the Linux devicetree or in the u-boot "Device Configuration Data" (those board-specific *.cfg files in u-boot's board folder). I think it was the latter one...

Best regards
 Martin

[mahi]

Hi Igor,

thanks for your reply. I am already using mfgtool.

I will check 0x907400 on wednesday (unfortunately, I don't have access to my debugger until then).

I'm still a little confused about the results of kobs-ng with the FCB being at offset 6 while I am expecting offset 4 when looking in the reference manual...

Best regards,

 Martin