NAND Boot Attempt: "No BCB" Error 0x80508001

[dingram1z]

To IMX Community:

I am trying to boot Linux 2.6.35.3 (FSL 10.12.01 BSP) on i.MX28 EVK Rev D from NAND, with UBIFS root FS on NAND.  I am getting immediate 0x80508001 error on boot attempt.

Background Info

• NAND Device:             32 GiB 8-bit MLC NAND (MicronMT29F32G08CBACA)
• Page size:                   4096 + 224
• Block size:                   256 pages (1 MiB + 56 KiB)
• Device size:                4096 blocks (32GiB)
• UBIFS PEB size:        1024 KiB (1,048,576 bytes)
• UBIFS LEB size:        1024 KiB - 2 * 4 KiB = 1016 KiB (1,040,384 bytes)
•                                     (256pages - 2 pages UBI overhead) * 4096 = 1,040,384 bytes
• Max PEB count:          4095 (4096 blocks - 1 for overhead)

I modified kernel MTD driver files (nand_ids.c, nand_device_info.c, nand_base.c, gpmi-nfc-hal-common.c) to support this NAND device.  Device is recognized during EVK NFS boot and parameters are as intended.

UBIFS for root FS seems to be working fine using ".img" file generated by LTIB.  (Flashed using NFS rootfs export from dev host.)

1. From LTIB dir:                          cp rootfs ubifs.img.rootfs /tmp
2. From EVK debug:                     ubiformat /dev/mtd1 -e 0 -f /tmp/rootfs.ubifs.img
3. To check, from EVK debug (just to observe files):     

• ubiattach /dev/ubi_ctrl -m1
• mkdir /mnt/ubifs
• mount -t ubifs ubi0:rootfs /mnt/ubifs
• ls -l /mnt/ubifs
• umount /mnt/ubifs

I prepare NAND boot partition as follows:

1. From LTIB dir:                                 /ltib -p boot_stream.spec -f
2. From EVK debug:                           flash_eraseall/dev/mtd0
3.                                                         kobs-ng init /boot/imx28_ivt_linux.sb

I set EVK boot switches for NAND and attempt to boot EVK. On EVK debug I get immediate "0x80508001", and nothing else.  From documentation this is:

            0x80508001    ERROR_ROM_NAND_DRIVER_NO_BCB

            Unable to find one of the Boot Control Blocks (FCB or DBBT)

Troubleshooting:

1. Extracted 'kobs-ng-11.03.00' package from i.MX53 'L2.6.35_11.03_ER_source_bundle.tar.gz'. 
   Required minor change to 'discover_boot_rom_version()' in 'main.c' to detect i.MX28, but exactly same results using 'init'.
2. Wrote EVK test program to read and analyze NAND boot partition /dev/mtd0:

• Detected 4 FCB's at expected address offsets for "stride" parameter
• Verified checksum for FCB's
• Verified Hamming SEC-DED 8 data + 5 parity for 512-byte FCB page
• Detected 4 DBBT's at expected address offsets for "stride" parameter
• Verified checksum for DBBT's

Observations:

1. If I attempt to boot from NAND with erased /dev/mtd0, I get same 0x80508001 error
2. If I attempt to boot with no NAND device, I get 0x80508002 error ERROR_ROM_NAND_DRIVER_NO_FCB ("Unable to find FCB")

Questions:

1. Does anyone have details on i.MX boot ROM conditions for generating 0x80508001 error?
2. Does anyone have any later kobs-ng patches that address this issue?  (It needs a lot of work, e.g., neither "dump" or "extract" work for i.MX28)
3. Does anyone have any other ideas or information regarding debugging this error code?

Thanks,

Darrell

[admin]

try this flash 

MT29F16G08ABACAWP-IT:C   manufactured by Micron

it works for me directly without anyt code or configuration change.

[DougMartens]

I am using the MT29F16G08ABACAWP-IT:C and I cannot boot from NAND.  The very same board can boot with the MT29F02G08ABABAWP-IT with different settings on the GPIO's.  We know that this isn't a board issue since we can talk to the NAND and pull the kernel from the NAND once we have booted the RAM version of u-boot via the mfgtool.  We have verified the FCB, DBBT, and the DCD prefixed U-boot.  We have double and triple checked the GPIO settings and we believe there are no issues, but we still cannot boot.  To get the NAND programmed with the correct FCB and DBBT we had to make some changes to kobs-ng.  There were a bunch of constants within kobs-ng (instead of reading the values from the NAND config and setting the appropriate variables) that were set incorrectly.  There is some concern, though that we are setting the incorrect ECC settings.  The Micron part is 4k + 224 bytes with an ECC of 8bits.  In one section of the manual, it doesn't show direct support for that particular ECC settings.  The user manual states 4k + 218bytes with ECC of 8bits.  Further within the manual they state that 4k + 224bytes is supported via the 4k + 218 settings.

Can you please share with me what you set the GPIO settings to?

Background Info

• NAND Device:             16 GiB 8-bit MLC NAND (MicronMT29F16G08ABACA)
• Page size:                  4096 + 224
• Block size:                 128 pages
• Device size:                4096 blocks (16GiB)

GPIO Pin Settings

BOOT_CFG1[7] ==> "1" boot from nand
BOOT_CFG1[6] ==> "0" PATA pads
BOOT_CFG1[5:4] ==> "00" No interleaving
BOOT_CFG1[3:2] ==> "10" 5 address cycles
BOOT_CFG2[7:6] ==> "11" 4KBytes + 218 the NAND chips has 224 but this option is not available
BOOT_CFG2[5] ==> "0"  8 bit bus width
BOOT_CFG2[5] ==> "1" AXI DDR divide by 28
BOOT_CFG3[7] ==> "0" 1 block
BOOT_CFG3[6] ==> "0" Non LBA
BOOT_CFG3[5] ==> "1" Use R/B signal
BOOT_CFG3[4:3] ==> "00" ECC 8 bits
BOOT_CFG3[2:1] ==> "10" 128 pages in block

Thanks for your help.

[spearson]

You cannot boot from this device. 

1) When booting out of NAND flash, the Freescale i.MX287 mask ROM checks the NAND for BA-NAND support.

2) If BA-NAND support is not found, normal booting from NAND @ 0x0000 0000 commences. (good)

3) A chip is thought to be NAND-BA compatible if the Parameter Page 0xEC - Byte 6 - Bit 7 is set.

4) An ONFI 3.0 NAND reuses this bit to indicate whether extended parameter paging is supported.

5) An ONFI 3.0 NAND with parameter paging will hang the i.MX287 boot.

On your MT29F16G08ABACAWP the Parameter Page (0xEC) bit is set (extended parameter page).  This means that you cannot boot from this NAND device.

I got burned by this too.  I had to downgrade to a 1G SLC part to find one with the correct Parameter Page byte setting.

[DougMartens]

Simon,

Sorry actually I should've told you that I am using the iMX536.  The Micron MT29F16G08ABACAWP does not have bit 7 set in byte 6.  Do you have a different data sheet than I have?  My datasheet states Rev. G 5/12.

[spearson]

You are correct, Bye 6-7 is 0x58 so no issue with NAND-BA.

[soban]

We are also using micron MT29F8G08ABABA after downloading the images using mfg tool , after power cycle the board is not at all booting. See our log while downloading the images.

UTP: received command '$ kobs-ng init -v --chip_0_device_path=/dev/mtd0 $FILE'
UTP: executing "kobs-ng init -v --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

/tmp/file.utp: verifying using key '00000000000000000000000000000000'
/tmp/file.utp: is a valid bootstream for key '00000000000000000000000000000000'

mtd: opening: "/dev/mtd0"
mtd: '/dev/mtd0' bad block @ 0x400000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1000000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1080000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1100000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1180000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1200000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x1280000 (MTD)

mtd: opened '/dev/mtd0' - '(null)'
mtd: max_boot_stream_size_in_bytes = 8388608
mtd: boot_stream_size_in_bytes = 219148
mtd: #1 0x00400000 - 0x00c00000 (0x0043580c)
mtd: #2 0x00c00000 - 0x01400000 (0x00c3580c)

FCB
m_u32Checksum = 0
m_u32FingerPrint = 541213510
m_u32Version = 1
m_NANDTiming.m_u8DataSetup = 0
m_NANDTiming.m_u8DataHold = 0
m_NANDTiming.m_u8AddressSetup = 0
m_NANDTiming.m_u8DSAMPLE_TIME = 0
m_u32PageDataSize = 0
m_u32TotalPageSize = 0
m_u32SectorsPerBlock = 0
m_u32NumberOfNANDs = 0
m_u32TotalInternalDie = 0
m_u32CellType = 0
m_u32EccBlockNEccType = 0
m_u32EccBlock0Size = 0
m_u32EccBlockNSize = 0
m_u32EccBlock0EccType = 0
m_u32MetadataBytes = 0
m_u32NumEccBlocksPerPage = 0
m_u32EccBlockNEccLevelSDK = 0
m_u32EccBlock0SizeSDK = 0
m_u32EccBlockNSizeSDK = 0
m_u32EccBlock0EccLevelSDK = 0
m_u32NumEccBlocksPerPageSDK = 0
m_u32MetadataBytesSDK = 0
m_u32EraseThreshold = 0
m_u32BootPatch = 0
m_u32PatchSectors = 0
m_u32Firmware1_startingPage = 1024
m_u32Firmware2_startingPage = 3072
m_u32PagesInFirmware1 = 54
m_u32PagesInFirmware2 = 54
m_u32DBBTSearchAreaStartAddress = 512
m_u32BadBlockMarkerByte = 0
m_u32BadBlockMarkerStartBit = 0
m_u32BBMarkerPhysicalOffset = 0
DBBT
m_u32Checksum = 0
m_u32FingerPrint = 1413628484
m_u32Version = 1
m_u32NumberBB = 7
m_u32Number2KPagesBB = 1

Firmware: image #0 @ 0x0 size 0x0 - available 0x0
Firmware: image #1 @ 0x0 size 0x0 - available 0x1400000

nand_erase_nand: attempt to erase a bad block at page 0x00000080
nand_erase_nand: attempt to erase a bad block at page 0x00000100
nand_erase_nand: attempt to erase a bad block at page 0x00000180

-------------- Start to write the [ FCB ] -----
mtd: erasing @0:0x0-0x80000
mtd: device 0 fails MEMERASE (0x0 - 0x80000)
mtd: Failed to erase block @0x0
mtd: Writing FCB1 [ @0:0x40000 ] (1000) *
mtd: erasing @0:0x80000-0x100000
mtd: device 0 fails MEMERASE (0x80000 - 0x80000)
mtd: Failed to erase block @0x80000
mtd: Writing FCB3 [ @0:0xc0000 ] (1000) *
mtd_commit_bcb(FCB): status 2

-------------- Start to write the [ DBBT ] -----
mtd: erasing @0:0x100000-0x180000
mtd: device 0 fails MEMERASE (0x100000 - 0x80000)
mtd: Failed to erase block @0x100000
mtd: Writing DBBT1 [ @0:0x140000 ] (1000) *
mtd: erasing @0:0x180000-0x200000
mtd: device 0 fails MEMERASE (0x180000 - 0x80000)
mtd: Failed to erase block @0x180000
mtd: Writing DBBT3 [ @0:0x1c0000 ] (1000) *
mtd_commit_bcb(DBBT): status 2

mtd: PUTTING down DBBT0 BBTN0 @0x204000 (0x1000)
mtd: PUTTING down DBBT1 BBTN0 @0x284000 (0x1000)
mtd: PUTTING down DBBT2 BBTN0 @0x304000 (0x1000)
mtd: PUTTING down DBBT3 BBTN0 @0x384000 (0x1000)

mtd: Writting firmware image #0 @0: 0x00400000 - 0x00436000
mtd: Skipping bad block at 0x400000
mtd: erasing @0:0x480000-0x500000
UTP: sending Success to kernel for command $ kobs-ng init -v --chip_0_device_path=/dev/mtd0 $FILE.

[dingram1z]

Thanks, Vladan, for the update.  I have already moved on to another NAND chip, but it is good to know what was behind my problems.  Hopefully it will help someone else to avoid this pitfall.

[VladanJovanovic]

After looking into the issue it seems there's an issue with how ROM code identifies this NAND at boot and then looks for wrong data in the NAND. Detailed description:

This is a known issue with certain ONFI-compatible NANDs and the ROM.

At some point a while back, BA-NANDs were dropped from the ONFI spec. After that, Micron/ONFI made the very poor decision to reuse the "is BA-NAND" bit in the ONFI param page to mean something entirely different. Thus, when the ROM reads the param page on these newer NANDs, it sees what it thinks is the "is BA-NAND" bit set.

There is no workaround except to boot a patch, or to get modified NANDs from Micron that have that bit disabled in the param page.

[spearson]

See the i.mx287 Errata pdf

TKT140334 ONFI 3.0 NAND boot-up issue

"ROM in existing silicon (TO1.2) supports ONFI BA-NAND boot-up. During boot-up it reads Bit 7 of Byte 6-7 (1=supports Block Abstracted access mode) in ONFI NAND device’s parameter page to determine if the NAND device is ONFI BA-NAND. BA-NAND memory devices are no longer  part of the ONFI spec and memory vendors do not support these devices anymore. However in ONFI 3.0 Spec, that bit has been re-used to specify whether the NAND device supports extended parameter page"

The MT29F32G08CBACA is an ONFI 2.2 device that implements the ONFI 3.0 "Supports extended parameter page" bit and in doing so is in conflict with the i.mx287.

[dingram1z]

I get the same results using kobs-ng from the i.MX28 10.12.01 release as from the i.MX53 11.03 release.  I just tried the latter as an experiment.  The output listed below is from the i.MX28 10.12.01 version, unmodified, with the "-v" option.

================================================

FYI, here is the output from the "NAND Scan" dring kernel booting:

Scanning for NAND Flash chips...
nand_get_flash_type ##### Micron MT29F32G08CBACA detected! #####
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x68 (Micron NAND 512MiB 3,3V 8-bit
)
-----------------------------
NAND Flash Device Information
-----------------------------
Manufacturer      : Micron (0x2c)
Device Code       : 0x68
Cell Technology   : MLC
Chip Size         : 4 GiB
Pages per Block   : 256
Page Geometry     : 4096+224
ECC Strength      : 16 bits
ECC Size          : 512 B
Data Setup Time   : 15 ns
Data Hold Time    : 10 ns
Address Setup Time: 20 ns
GPMI Sample Delay : 6 ns
tREA              : 20 ns
tRLOH             : 5 ns
tRHOH             : 15 ns
Description       : MT29F32G08CBABA (4GB, 1CE); MT29F32G08CBACA (4GB, 1CE); MT29
F64G08CEABA (8GB, 2CE); MT29F64G08CFABA (8GB, 2CE)
-----------------
Physical Geometry
-----------------
Chip Count             : 1
Page Data Size in Bytes: 4096 (0x1000)
Page OOB Size in Bytes : 224
Block Size in Bytes    : 1048576 (0x100000)
Block Size in Pages    : 256 (0x100)
Chip Size in Bytes     : 4294967296 (0x100000000)
Chip Size in Pages     : 1048576 (0x100000)
Chip Size in Blocks    : 4096 (0x1000)
Medium Size in Bytes   : 4294967296 (0x100000000)
------------
NFC Geometry
------------
ECC Algorithm          : BCH
ECC Strength           : 16
Page Size in Bytes     : 4320
Metadata Size in Bytes : 10
ECC Chunk Size in Bytes: 512
ECC Chunk Count        : 8
Payload Size in Bytes  : 4096
Auxiliary Size in Bytes: 20
Auxiliary Status Offset: 12
Block Mark Byte Offset : 3904
Block Mark Bit Offset  : 0
-----------------
Boot ROM Geometry
-----------------
Boot Area Count            : 1
Boot Area Size in Bytes    : 20971520 (0x1400000)
Stride Size in Pages       : 64
Search Area Stride Exponent: 2
Scanning device for bad blocks
Bad eraseblock 90 at 0x000005a00000
Bad eraseblock 91 at 0x000005b00000
Bad eraseblock 2350 at 0x000092e00000
Bad eraseblock 3721 at 0x0000e8900000
Boot area protection is enabled.
Creating 2 MTD partitions on "gpmi-nfc-main":
0x000000000000-0x000001400000 : "gpmi-nfc-0-boot"
0x000001400000-0x000100000000 : "gpmi-nfc-general-use"
Creating 2 MTD partitions on "gpmi-nfc-general-use":
0x000000000000-0x000080000000 : "gpmi-nfc-ubi-0"
0x000080000000-0x0000fec00000 : "gpmi-nfc-ubi-1"

================================================

 Here is the output from flashing the NAND boot partition:

root@imx28evk ~$ kobs-ng init -v /boot/imx28_ivt_linux.sb
WARNING: Parameter 'chip_count' is no longer used, ignoring
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 = 22020096
/boot/imx28_ivt_linux.sb: verifying using key '00000000000000000000000000000000'

boot image header:
  m_digest = dbd32a21925cd39866991c8645489b1140f5beca
  m_signature = STMP
  m_majorVersion = 1
  m_minorVersion = 1
  m_flags = ROM_DISPLAY_PROGRESS (1)
  m_imageBlocks = 158823
  m_firstBootTagBlock = 9
  m_firstBootableSectionID = 0
  m_keyCount = 1
  m_keyDictionaryBlock = 7
  m_headerBlocks = 6
  m_sectionCount = 1
  m_sectionHeaderSize = 1
  m_timestamp = Thu Nov 17 12:48:46 2011
  m_productVersion.m_major = 0x9909
  m_productVersion.m_minor = 0x9909
  m_productVersion.m_revision = 0x9909
  m_componentVersion.m_major = 0x9909
  m_componentVersion.m_minor = 0x9909
  m_componentVersion.m_revision = 0x9909
  m_driveTag = 0
* Using user supplied key='00000000000000000000000000000000'
section header #0:
  m_identifier = 0
  m_offset = 10
  m_length = 158811
  m_flags = ROM_SECTION_BOOTABLE (0x1)
* calculated-mac = ec09ba86b06b388e489db43c4e422096
dek dictionary entry #0:
  m_mac = ec09ba86b06b388e489db43c4e422096
  m_dek = 38fef40f4f646906803f669f30034bcd
* Key matched at #0
* session_key = 205c6c61d6a9d94053bdbaff83d3d19c
LOAD m_address=0x00000000 m_count=0x00000dcc
LOAD m_address=0x00000dcc m_count=0x00000348
LOAD m_address=0x00001114 m_count=0x0000004c
LOAD m_address=0x00001160 m_count=0x00000084
LOAD m_address=0x000011e4 m_count=0x000000a0
LOAD m_address=0x00001284 m_count=0x00000024
LOAD m_address=0x000012a8 m_count=0x00000024
LOAD m_address=0x000012cc m_count=0x00000008
LOAD m_address=0x000012d4 m_count=0x00000010
LOAD m_address=0x000012e4 m_count=0x0000006c
LOAD m_address=0x00001350 m_count=0x0000007c
LOAD m_address=0x000013cc m_count=0x0000000c
LOAD m_address=0x000013d8 m_count=0x00000064
LOAD m_address=0x0000143c m_count=0x00000050
LOAD m_address=0x0000148c m_count=0x00000134
LOAD m_address=0x000015c0 m_count=0x00000050
LOAD m_address=0x00001610 m_count=0x00000144
LOAD m_address=0x00001754 m_count=0x00000030
LOAD m_address=0x00001784 m_count=0x00000030
LOAD m_address=0x000017b4 m_count=0x0000005c
LOAD m_address=0x00001810 m_count=0x00000030
LOAD m_address=0x00001840 m_count=0x000000c0
LOAD m_address=0x00001900 m_count=0x0000005c
LOAD m_address=0x0000195c m_count=0x00000084
LOAD m_address=0x000019e0 m_count=0x000000a8
LOAD m_address=0x00001a88 m_count=0x00000068
LOAD m_address=0x00001af0 m_count=0x0000001c
LOAD m_address=0x00001b0c m_count=0x00000028
LOAD m_address=0x00001b34 m_count=0x0000001c
LOAD m_address=0x00001b50 m_count=0x00000028
LOAD m_address=0x00001b78 m_count=0x00000020
LOAD m_address=0x00001b98 m_count=0x00000140
LOAD m_address=0x00001cd8 m_count=0x00000034
LOAD m_address=0x00001d0c m_count=0x00000014
LOAD m_address=0x00001d20 m_count=0x00000034
LOAD m_address=0x00001d54 m_count=0x00000014
LOAD m_address=0x00001d68 m_count=0x00000030
LOAD m_address=0x00001d98 m_count=0x00000034
LOAD m_address=0x00001dcc m_count=0x00000030
LOAD m_address=0x00001dfc m_count=0x00000004
LOAD m_address=0x00001e00 m_count=0x00000020
LOAD m_address=0x00001e20 m_count=0x0000003c
LOAD m_address=0x00001e5c m_count=0x00000014
LOAD m_address=0x00001e70 m_count=0x00000018
LOAD m_address=0x00001e88 m_count=0x00000018
LOAD m_address=0x00001ea0 m_count=0x00000018
LOAD m_address=0x00001eb8 m_count=0x00000020
LOAD m_address=0x00001ed8 m_count=0x00000020
LOAD m_address=0x00001ef8 m_count=0x00000024
LOAD m_address=0x00001f1c m_count=0x00000024
LOAD m_address=0x00001f40 m_count=0x00000054
LOAD m_address=0x00001f94 m_count=0x00000030
LOAD m_address=0x00001fc4 m_count=0x00000038
LOAD m_address=0x00001ffc m_count=0x000000dc
LOAD m_address=0x000020d8 m_count=0x00000068
LOAD m_address=0x00002140 m_count=0x00000024
LOAD m_address=0x00002164 m_count=0x00000018
LOAD m_address=0x0000217c m_count=0x00000024
LOAD m_address=0x000021a0 m_count=0x00000018
LOAD m_address=0x000021b8 m_count=0x00000024
LOAD m_address=0x000021dc m_count=0x00000008
LOAD m_address=0x000021e4 m_count=0x00000018
LOAD m_address=0x000021fc m_count=0x00000028
LOAD m_address=0x00002224 m_count=0x0000000c
LOAD m_address=0x00002230 m_count=0x000000d8
LOAD m_address=0x00002308 m_count=0x0000001c
LOAD m_address=0x00002324 m_count=0x00000164
LOAD m_address=0x00002488 m_count=0x00000078
LOAD m_address=0x00002500 m_count=0x00000064
LOAD m_address=0x00002564 m_count=0x00000038
LOAD m_address=0x0000259c m_count=0x00000008
LOAD m_address=0x000025a4 m_count=0x000000bc
LOAD m_address=0x00002660 m_count=0x0000008c
LOAD m_address=0x000026ec m_count=0x000000b0
LOAD m_address=0x0000279c m_count=0x00000010
LOAD m_address=0x000027ac m_count=0x00000048
LOAD m_address=0x000027f4 m_count=0x0000002c
LOAD m_address=0x00002820 m_count=0x00000005
FILL m_address=0x00002828 m_count=0x00000024 m_data=0x00000000
LOAD m_address=0x00008000 m_count=0x00000020
CALL m_address=0x00008000 m_data=0x00000000
LOAD m_address=0x00000000 m_count=0x000018a4
LOAD m_address=0x000018a4 m_count=0x000000f4
LOAD m_address=0x00008000 m_count=0x00000020
CALL m_address=0x00008000 m_data=0x00000000
LOAD m_address=0x00002000 m_count=0x00000144
LOAD m_address=0x00002160 m_count=0x0000073c
LOAD m_address=0x000028a0 m_count=0x00000004
LOAD m_address=0x000028c0 m_count=0x00000008
LOAD m_address=0x000028c8 m_count=0x00000028
LOAD m_address=0x00002900 m_count=0x0000019c
LOAD m_address=0x00002aa0 m_count=0x000000a8
FILL m_address=0x00002b60 m_count=0x00000014 m_data=0x00000000
LOAD m_address=0x00008000 m_count=0x00000020
CALL m_address=0x00008000 m_data=0x00000000
LOAD m_address=0x40008000 m_count=0x00267008
LOAD m_address=0x00008000 m_count=0x00000020
JUMP m_address=0x00008000 m_data=0x00000000
* read SHA1 = 7020718ff6dc7a53e7ce926ef819003ddb2d19c4
* calc SHA1 = 7020718ff6dc7a53e7ce926ef819003ddb2d19c4
/boot/imx28_ivt_linux.sb: is a valid bootstream for key '00000000000000000000000
000000000'
mtd: opening: "/dev/mtd0"
NFC Geometry
  ECC Algorithm          : BCH
  ECC Strength           : 16
  Page Size in Bytes     : 4320
  Metadata Size in Bytes : 10
  ECC Chunk Size in Bytes: 512
  ECC Chunk Count        : 8
  Payload Size in Bytes  : 4096
  Auxiliary Size in Bytes: 20
  Auxiliary Status Offset: 12
  Block Mark Byte Offset : 3904
  Block Mark Bit Offset  : 0
mtd: opened '/dev/mtd0' - '(null)'
mtd: max_boot_stream_size_in_bytes = 9437184
mtd: boot_stream_size_in_bytes = 2541168
mtd: #1 0x00200000 - 0x00b00000 (0x0046c670)
mtd: #2 0x00b00000 - 0x01400000 (0x00d6c670)
  m_u32Checksum = 0
  m_u32FingerPrint = 541213510
  m_u32Version = 16777216
FCB
  m_NANDTiming.m_u8DataSetup = 80
  m_NANDTiming.m_u8DataHold = 60
  m_NANDTiming.m_u8AddressSetup = 25
  m_NANDTiming.m_u8DSAMPLE_TIME = 6
  m_u32DataPageSize = 4096
  m_u32TotalPageSize = 4320
  m_u32SectorsPerBlock = 256
  m_u32NumberOfNANDs = 0
  m_u32TotalInternalDie = 0
  m_u32CellType = 0
  m_u32EccBlockNEccType = 0
  m_u32EccBlock0Size = 512
  m_u32EccBlockNSize = 512
  m_u32EccBlock0EccType = 0
  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_u32BootPatch = 0
  m_u32PatchSectors = 0
  m_u32Firmware1_startingSector = 512
  m_u32Firmware2_startingSector = 2816
  m_u32SectorsInFirmware1 = 621
  m_u32SectorsInFirmware2 = 621
  m_u32DBBTSearchAreaStartAddress = 256
  m_u32BadBlockMarkerByte = 3904
  m_u32BadBlockMarkerStartBit = 0
  m_u32BBMarkerPhysicalOffset = 4096
  m_u32NumberBB = 102317136
  m_u32Number2KPagesBB = 0
Firmware: image #0 @ 0x200000 size 0x26d000 - available 0x900000
Firmware: image #1 @ 0xb00000 size 0x26d000 - available 0x900000
NCB versions differ, 3 is used.
mtd: erasing @0:0x0-0x100000
mtd: Writing FCB0 @0:0x0(10e0)
mtd: Writing FCB1 @0:0x40000(10e0)
mtd: Writing FCB2 @0:0x80000(10e0)
mtd: Writing FCB3 @0:0xc0000(10e0)
mtd: erasing @0:0x0-0x100000
mtd: Writing FCB0 @0:0x0(10e0)
mtd: Writing FCB1 @0:0x40000(10e0)
mtd: Writing FCB2 @0:0x80000(10e0)
mtd: Writing FCB3 @0:0xc0000(10e0)
mtd_commit_bcb(FCB): status 0
mtd: erasing @0:0x100000-0x100000
mtd: Writing DBBT0 @0:0x100000(1000)
mtd: Writing DBBT1 @0:0x140000(1000)
mtd: Writing DBBT2 @0:0x180000(1000)
mtd: Writing DBBT3 @0:0x1c0000(1000)
mtd: erasing @0:0x100000-0x100000
mtd: Writing DBBT0 @0:0x100000(1000)
mtd: Writing DBBT1 @0:0x140000(1000)
mtd: Writing DBBT2 @0:0x180000(1000)
mtd: Writing DBBT3 @0:0x1c0000(1000)
mtd_commit_bcb(DBBT): status 0
mtd: Writting firmware image #0 @0: 0x00200000 - 0x0046d000
mtd: erasing @0:0x200000-0x100000
mtd: erasing @0:0x300000-0x100000
mtd: erasing @0:0x400000-0x100000
mtd: Writting firmware image #1 @0: 0x00b00000 - 0x00d6d000
mtd: erasing @0:0xb00000-0x100000
mtd: erasing @0:0xc00000-0x100000
mtd: erasing @0:0xd00000-0x100000
root@imx28evk ~$

================================================

Here is a dump of the first 32 bytes of '/dev/mtd0', with only 2 '0x00' bytes before the start of the checksum instead of the correct 12 bytes:

root@imx28evk ~$ hexdump -C -n 32 /dev/mtd0
00000000  00 00 07 fc ff ff 46 43  42 20 00 00 00 01 50 3c  |......FCB ....P<|
00000010  19 06 00 00 00 00 00 10  00 00 e0 10 00 00 00 01  |................|
00000020
================================================

Finally, here is the error I receive when I power down from NFS boot+root fs, reset the EVK boot switches, then attempt to boot from NAND:

The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Power down.
HW_RTC_PERSISTENT0 = 0x220100
HW_RTC_PERSISTENT0 = 0x200100
0x80508001

Thanks for your help,

Darrell

[VladanJovanovic]

Can you also attach output of kobs-ng as it formats the NAND? You mention you take kobs-ng from 11.03 release for i.MX53. Have you tried using kobs-ng from 10.12.01 release for i.MX28?

[dingram1z]

I have done a little more investigation and experimentation, but still no success.  I even tried inserting the missing 10 zero bytes at the beginning of each FCB page.  This makes the hexdump appear correct, but I still get the immediate 0x80508001 error on a NAND boot attempt.  What I really need to know is what are the specific conditions within the boot ROM code that generate this error, or what conditions must be met to make it past this error.  I have had to pursue other things, but I will be returning to this soon.  Any information would be helpful.  I am considering obtaining a different NAND device to try, hopefully a part that is already present in the kernel NAND tables.  The 32 GiB part I am using is really larger than I need, which is something like 4 GiB.

Thanks for your followup,

Darrell

[VladanJovanovic]

Did you find out what went wrong here? It does look like an error in how data is written, but where did it come from - bug in kobs-ng for that particular NAND configuration or something else?

[dingram1z]

Hi Vladan:

Looking at the hexdump you requested, I see a problem in the FCB blocks.  At the beginning of each FCB page, there should be 12 zero bytes, followed by a 4-byte checksum, followed by the "FCB " tag.  For all 4 FCB's shown in the dump, there are only 2 zero bytes, not 12:

    From 'hexdump':

    00000000  00 00 f7 fb ff ff 46 43  42 20 00 00 00 01 50 3c  |......FCB ....P<|
    00000010  19 06 00 00 00 00 00 10  00 00 e0 10 00 00 00 01  |................|

Inside "kobs-ng init", however, dumping the raw buffer that is written to '/dev/mtd0' shows that the 12 zero bytes are present:

    After fcb_encrypt():
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    0x00 0x00 0x00 0x00 0xf7 0xfb 0xff 0xff
    0x46 0x43 0x42 0x20 0x00 0x00 0x00 0x01
    0x50 0x3c 0x19 0x06 0x00 0x00 0x00 0x00

    mtd: erasing @0:0x0-0x100000
    mtd: Writing FCB0 @0:0x0(10e0)
    After pwrite():
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    0x00 0x00 0x00 0x00 0xf7 0xfb 0xff 0xff
    0x46 0x43 0x42 0x20 0x00 0x00 0x00 0x01
    0x50 0x3c 0x19 0x06 0x00 0x00 0x00 0x00

This pattern is not observed for the "DBBT" blocks, however, and all 12 zero bytes are observed in both the hexdump and in the buffer dump within kobs-ng:

    From 'hexdump':

    00100000  00 00 00 00 00 00 00 00  00 00 00 00 e2 fe ff ff  |................|
    00100010  44 42 42 54 00 00 00 01  00 00 00 00 00 00 00 00  |DBBT............|
    00100020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Inside "kobs-ng init" dumping the raw buffer that is written to '/dev/mtd0' shows that the 12 zero bytes are present:

    mtd: erasing @0:0x100000-0x100000
    mtd: Writing DBBT0 @0:0x100000(1000)
    After pwrite():
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
    0x00 0x00 0x00 0x00 0xe2 0xfe 0xff 0xff
    0x44 0x42 0x42 0x54 0x00 0x00 0x00 0x01
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

 At this point, I have no idea why the 10 zero bytes are missing from the beginning of each FCB, but you have triggered a new insight into my problem and opened a new avenue of attack.

Thanks for your help,

Darrell

[dingram1z]

Hi Vladan:

Thanks for looking at this.  Here is the hexdump.  I had to dump 2MiB to get all 4 FCB's + all 4 DBBT's.  I used this command:

hexdump -C -n 2097152 /dev/mtd0 > hexdump-dev-mtd0-2M.txt

Darrell

[VladanJovanovic]

Can you take a hexdump of /dev/mtd0 and put it here as zipped attachment? First 1MB should be fine I guess...

br,

Vladan