wrong FCB structure written on NAND

da1 — Tue, 12 Mar 2019 07:54:54 GMT

Hi,

it seems that we have a problem with the FCB data structure written on NAND, on boards based on i.MX6ULL rev1.0 14x14 EVK, booting from a Micron MT29F32G08CBADAWP-12IT:D NAND.

From some point on, the data seems to be wrong; can anyone with experience on the subject confirm our analysis?

We tried using multiple versions of kobs-ng, including the latest from github and the one in the SDK from NXP.

What we see in the NAND, with a nanddump -o -a /dev/mtd0 is as follow (we've removed the first 0x15 bytes to be aligned with the FCB structure described in chapter 8.5.2.3 of the i.MX 6ULL Applications Processor Reference Manual:

Everything is ok up to BadBlockMarkerByte (position 0x7c, value 7692); after that, there should be 0 for BadBlockMarkerStartBit but as you can see everthing from there on seems to be wrong.

We are especially concerned about BCHType that should be 1, but is wrong and we suspect it makes ECC flipbits recovery impossible, for the ROM.

The structure, as printed by kobs-ng:

# kobs-ng init -x -v --chip_0_device_path=/dev/mtd0 u-boot.imx
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       : 40
   Page Size in Bytes : 8762
   Metadata size      : 10
   ECC Chunk Size in byte : 1024
   ECC Chunk count        : 8
   Block Mark Byte Offset : 7692
   Block Mark Bit Offset : 0
====================================================
mtd: opened '/dev/mtd0' - '(null)'
mtd: max_boot_stream_size_in_bytes = 25165824
mtd: boot_stream_size_in_bytes = 475136
mtd: boot_stream_size_in_pages = 58
mtd: #1 0x01000000 - 0x02800000 (0x01074000)
mtd: #2 0x02800000 - 0x04000000 (0x02874000)
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 = 8192
m_u32TotalPageSize = 8936
m_u32SectorsPerBlock = 256
m_u32NumberOfNANDs = 0
m_u32TotalInternalDie = 0
m_u32CellType = 0
m_u32EccBlockNEccType = 20
m_u32EccBlock0Size = 1024
m_u32EccBlockNSize = 1024
m_u32EccBlock0EccType = 20
m_u32MetadataBytes = 10
m_u32NumEccBlocksPerPage = 7
m_u32EccBlockNEccLevelSDK = 0
m_u32EccBlock0SizeSDK = 0
m_u32EccBlockNSizeSDK = 0
m_u32EccBlock0EccLevelSDK = 0
m_u32NumEccBlocksPerPageSDK = 0
m_u32MetadataBytesSDK = 0
m_u32EraseThreshold = 0
m_u32Firmware1_startingPage = 2048
m_u32Firmware2_startingPage = 5120
m_u32PagesInFirmware1 = 58
m_u32PagesInFirmware2 = 58
m_u32DBBTSearchAreaStartAddress = 1024
m_u32BadBlockMarkerByte = 7692
m_u32BadBlockMarkerStartBit = 0
m_u32BBMarkerPhysicalOffset = 8192
m_u32BCHType = 1
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
m_u32OnfiSyncEnable = 0
m_NANDONFITiming.m_u32ONFISpeed = 0
m_NANDONFITiming.m_u32ONFITiming_ReadLatency = 0
m_NANDONFITiming.m_u32ONFITiming_CEDelay = 0
m_NANDONFITiming.m_u32ONFITiming_PreambleDelay = 0
m_NANDONFITiming.m_u32ONFITiming_PostambleDelay = 0
m_NANDONFITiming.m_u32ONFITiming_CmdAddPause = 0
m_NANDONFITiming.m_u32ONFITiming_DataPause = 0
m_NANDONFITiming.m_u32ONFITiming_BusyTimeout = 0
m_u32DISBBSearch = 0
m_u32RandomizerEnable = 0
m_u32ReadRetryEnable = 0
m_u32ReadRetrySeqLength = 0
DBBT
m_u32Checksum = 0x00000000
m_u32FingerPrint = 0x54424244
m_u32Version = 0x01000000
m_u32DBBTNumOfPages = 0
Firmware: image #0 @ 0x1000000 size 0x74000 - available 0x1800000
Firmware: image #1 @ 0x2800000 size 0x74000 - available 0x1800000
-------------- Start to write the [ FCB ] -----
mtd: erasing @0:0x0-0x200000
mtd: Writing FCB0 [ @0:0x0 ] (22e8) *
mtd: erasing @0:0x200000-0x400000
mtd: Writing FCB1 [ @0:0x200000 ] (22e8) *
mtd: erasing @0:0x400000-0x600000
mtd: Writing FCB2 [ @0:0x400000 ] (22e8) *
mtd: erasing @0:0x600000-0x800000
mtd: Writing FCB3 [ @0:0x600000 ] (22e8) *
mtd_commit_bcb(FCB): status 0

-------------- Start to write the [ DBBT ] -----
mtd: erasing @0:0x800000-0xa00000
mtd: Writing DBBT0 [ @0:0x800000 ] (2000) *
mtd: erasing @0:0xa00000-0xc00000
mtd: Writing DBBT1 [ @0:0xa00000 ] (2000) *
mtd: erasing @0:0xc00000-0xe00000
mtd: Writing DBBT2 [ @0:0xc00000 ] (2000) *
mtd: erasing @0:0xe00000-0x1000000
mtd: Writing DBBT3 [ @0:0xe00000 ] (2000) *
mtd_commit_bcb(DBBT): status 0

---------- Start to write the [ .tmp_kobs_ng ]----
mtd: Writting .tmp_kobs_ng: #0 @0: 0x01000000 - 0x01074000
mtd: erasing @0:0x1000000-0x1200000
mtd: We write one page for save guard. *
mtd: Writting .tmp_kobs_ng: #1 @0: 0x02800000 - 0x02874000
mtd: erasing @0:0x2800000-0x2a00000
mtd: We write one page for save guard. *

kobs-ng correctly identifies the processor as i.MX6ULL. Our kernel is the latest from imx_4.1.15_2.0.0_ga branch from NXP.

# cat /proc/cpuinfo
processor   : 0
model name   : ARMv7 Processor rev 5 (v7l)
BogoMIPS   : 3.00
Features   : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer   : 0x41
CPU architecture: 7
CPU variant   : 0x0
CPU part   : 0xc07
CPU revision   : 5
Hardware   : Freescale i.MX6 Ultralite (Device Tree)
Revision   : 0000
Serial       : 0000000000000000

This problem was detected investigating i.MX6ULL errors correcting u-boot bitflips (still unresolved).

We also tried switching the a 2017.03 u-boot-imx (from the previous 2016.03), but nothing changed.

Thank you in advance for any help.

Re: wrong FCB structure written on NAND

da1 — Tue, 12 Mar 2019 10:45:52 GMT

it seems that the "missing" data began at offset 0xC5, and the values there are correct. What it's not clear is why there's this (BCH?) data so soon; we expected the Block0 size to be 512 bytes for i.MX6ULL.

Re: wrong FCB structure written on NAND

jimmychan — Wed, 27 Mar 2019 06:26:32 GMT

This may help you.

https://community.nxp.com/message/947634?commentID=947634#comment-947634

topic Re: wrong FCB structure written on NAND in i.MX Processors

wrong FCB structure written on NAND

Re: wrong FCB structure written on NAND

Re: wrong FCB structure written on NAND