AnsweredAssumed Answered

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

Question asked by mahi on Apr 27, 2018
Latest reply on May 2, 2018 by 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.

Outcomes