imx53 cannot boot from NAND

bdp42 · ‎05-22-2014

I have a custom iMX53 based platform running Android and I am attempting to boot from NAND. It does not boot up and after a while there is activity on the OTG usb interface suggesting the iMX53 ROM cannot find what it is looking for and is trying to boot over USB. I can see that there is a long access of the NAND device at the beginning followed by a short set of accesses repeated 4 times. It then stops and this suggests it can find the FCB but not the DBBT - not sure about this. I've spent some time investigating the issue and, as far as I can see, everything appears to correctly configured and setup. I've collected and presented the relevant information below and I would appreciate help in trying to diagnose what is wrong.

Nand device is MT29F32G08AFABA

SLC

Page size 4320 bytes (4096 + 224 bytes)

Block size: 128 pages (512K +28K bytes)

Hardware Boot config is as follows:

BOOT_CFG1[7] 1 - Boot from NAND

BOOT_CFG2[7:6] 11 - Page size 4K + 218 Bytes

BOOT_CFG2[5] 0 - 8 bit bus

BOOT_CFG3[7] 0 - Stride size 1 Block

BOOT_CFG3[6] 0 - Non LBA

BOOT_CFG3[5] 1 - Use R/B signal

BOOT_CFG3[4:3] 00 - 8 bits ECC

BOOT_CFG3[2:1] 10 - 128 pages per block

I can successfully boot the image from SD card and I am using the kobs-ng utility to program NAND.

kobs-ng came from the Linux BSP L2.6.35_11_09_ER_SOURCE. I added the following patch for correct iMX53 support.

https://community.freescale.com/servlet/JiveServlet/download/318027-258403/0002-set-dbbt-fingerprint...

The BSP is based on iMX53 Android R10.2 BSP

The OS is Android so I had to hand-craft an Android.mk file to build kobs-ng for an Android environment. This is building and appears to be working OK on the target. Here is the verbose output when I run the tool.

# kobs-ng init -v --search_exponent=3 --chip_0_device_path=/dev/mtd/mtd0 /sdcard/u-boot.bin

mx53 TO 2.x

MTD CONFIG:

chip_0_device_path = "/dev/mtd/mtd0"

chip_1_device_path = "(null)"

search_exponent = 3

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

/sdcard/u-boot.bin: verifying using key '00000000000000000000000000000000'

/sdcard/u-boot.bin: is a valid bootstream for key '00000000000000000000000000000000'

mtd: opening: "/dev/mtd/mtd0"

mtd: '/dev/mtd/mtd0' bad block @ 0xc00000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xc80000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xd00000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xd80000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xe00000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xe80000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xf00000 (MTD)

mtd: '/dev/mtd/mtd0' bad block @ 0xf80000 (MTD)

mtd: opened '/dev/mtd/mtd0' - '(null)'

mtd: stride size 80000 search area (bytes) 200000 search area (pages) 200 write size 1000

mtd: max_boot_stream_size_in_bytes = 6291456

mtd: boot_stream_size_in_bytes = 350652

mtd: #1 0x00400000 - 0x00a00000 (0x004559bc)

mtd: #2 0x00a00000 - 0x01000000 (0x00a559bc)

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 = 2560

m_u32PagesInFirmware1 = 86

m_u32PagesInFirmware2 = 86

m_u32DBBTSearchAreaStartAddress = 512

m_u32BadBlockMarkerByte = 3914

m_u32BadBlockMarkerStartBit = 0

m_u32BBMarkerPhysicalOffset = 0

DBBT

m_u32Checksum = 0

m_u32FingerPrint = 1145193044

m_u32Version = 1

m_u32NumberBB = 8

m_u32Number2KPagesBB = 1

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

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

NCB versions differ, 3 is used.

-------------- Start to write the [ FCB ] -----

mtd: erasing @0:0x0-0x80000

mtd: Writing FCB0 [ @0:0x0 ] (1000) *

mtd: Writing FCB1 [ @0:0x40000 ] (1000) *

mtd: erasing @0:0x80000-0x100000

mtd: Writing FCB2 [ @0:0x80000 ] (1000) *

mtd: Writing FCB3 [ @0:0xc0000 ] (1000) *

mtd: erasing @0:0x100000-0x180000

mtd: Writing FCB4 [ @0:0x100000 ] (1000) *

mtd: Writing FCB5 [ @0:0x140000 ] (1000) *

mtd: erasing @0:0x180000-0x200000

mtd: Writing FCB6 [ @0:0x180000 ] (1000) *

mtd: Writing FCB7 [ @0:0x1c0000 ] (1000) *

mtd_commit_bcb(FCB): status 0

-------------- Start to write the [ DBBT ] -----

mtd: erasing @0:0x200000-0x280000

mtd: Writing DBBT0 [ @0:0x200000 ] (1000) *

mtd: Writing DBBT1 [ @0:0x240000 ] (1000) *

mtd: erasing @0:0x280000-0x300000

mtd: Writing DBBT2 [ @0:0x280000 ] (1000) *

mtd: Writing DBBT3 [ @0:0x2c0000 ] (1000) *

mtd: erasing @0:0x300000-0x380000

mtd: Writing DBBT4 [ @0:0x300000 ] (1000) *

mtd: Writing DBBT5 [ @0:0x340000 ] (1000) *

mtd: erasing @0:0x380000-0x400000

mtd: Writing DBBT6 [ @0:0x380000 ] (1000) *

mtd: Writing DBBT7 [ @0:0x3c0000 ] (1000) *

mtd_commit_bcb(DBBT): status 0

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 - 0x00456000

mtd: erasing @0:0x400000-0x480000

Here is a dump of the relevant parts of NAND

00000000 00 00 00 00 46 43 42 20 01 00 00 00 00 00 00 00 ....FCB ........

00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00000040 00 00 00 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 04 00 00 00 0A 00 00 ................

00000070 56 00 00 00 56 00 00 00 00 02 00 00 4A 0F 00 00 V...V.......J...

00000080 00 00 00 00 00 00 00 00 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 ................

000000A0 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................

The DBBT start page number is 0x200 so the absolute start address of BBT in NAND is 0x200000 ( 0x200 * 0x1000). I'm assuming page size excludes OOB bytes.

Here's the start of the DBBT

00200000 00 00 00 00 54 42 42 44 01 00 00 00 08 00 00 00 ....TBBD........

00200010 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

00200090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

002000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

002000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

The primary image start number is 0x400 so the absolute address of the image in NAND is 0x400000 (0x400*0x1000) and the IVT is offset 0x400 from this.

The following is a short dump of 0x400400 where I expect to find the IVT and it does look correct.

00400400 D1 00 20 40 C0 05 80 77 00 00 00 00 2C 04 80 77 Ñ. @À.€w....,.€w

00400410 20 04 80 77 00 04 80 77 00 00 00 00 00 00 00 00 .€w..€w........

00400420 00 00 80 77 BC 5D 05 00 00 00 00 00 D2 01 88 40 ..€w¼]......Ò.ˆ@

00400430 CC 01 84 04 53 FA 85 54 00 38 00 00 53 FA 85 58 Ì.„.Sú…T.8..Sú…X

00400440 00 38 00 C0 53 FA 85 60 00 38 00 00 53 FA 85 64 .8.ÀSú…`.8..Sú…d

00400450 00 38 00 C0 53 FA 85 68 00 38 00 C0 53 FA 85 70 .8.ÀSú…h.8.ÀSú…p

00400460 00 38 00 00 53 FA 85 74 00 38 00 00 53 FA 85 78 .8..Sú…t.8..Sú…x

00400470 00 38 00 00 53 FA 85 7C 00 38 00 D0 53 FA 85 80 .8..Sú…|.8.ÐSú…€

00400480 00 38 00 C0 53 FA 85 84 00 38 00 00 53 FA 85 88 .8.ÀSú…„.8..Sú…ˆ

00400490 00 38 00 00 53 FA 85 90 00 38 00 C0 53 FA 85 94 .8..Sú…..8.ÀSú…”

004004A0 00 38 00 00 53 FA 86 F0 00 38 00 00 53 FA 86 F4 .8..Sú†ð.8..Sú†ô

004004B0 00 00 00 00 53 FA 86 FC 00 00 00 00 53 FA 87 14 ....Sú†ü....Sú‡.

004004C0 00 00 00 00 53 FA 87 18 00 38 00 00 53 FA 87 1C ....Sú‡..8..Sú‡.

004004D0 00 38 00 00 53 FA 87 20 00 38 00 00 53 FA 87 24 .8..Sú‡ .8..Sú‡$

004004E0 00 00 00 00 53 FA 87 28 00 38 00 00 53 FA 87 2C ....Sú‡(.8..Sú‡,

004004F0 00 38 00 00 63 FD 90 1C 00 00 80 00 63 FD 90 7C .8..cý....€.cý.|

00400500 01 4D 01 52 63 FD 90 80 01 4F 01 4E 63 FD 90 88 .M.Rcý.€.O.Ncý.ˆ

So everthing appears to be OK as per my understanding of the iMX53 reference manual.

Can anyone see anything obviously wrong here or point to something else to look at.

Thanks,

Bruno

igorpadykov · ‎05-22-2014

Hi Bruno

i.MX53 kobs-ng from Linux BSP L2.6.35_11_09

does not write correct geometry for some NANDs (for example MT29F16G08ABAC).

Please try kobs-ng from i.MX6 BSPs, seems it can generate i.MX53 uboot (but not kernel)

or try attached patch.

L3.10.17_1.0.0_IMX6QDLS_BUNDLE : Source Code Download Steps Documentation and Demo Images.

Alternatively one can try other NAND.

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

bdp42 · ‎05-22-2014

Hi Chip,

Thanks for this. I will try this and see if it fixes the problem.

Can you expand a bit on the nature of the problem with kobs-ng from Linux BSP L2.6.35_11_09?

Thanks,

Bruno

igorpadykov · ‎05-22-2014

Hi Bruno

I think you can look at patch, it fixes it.

Best regards

chip

bdp42 · ‎05-23-2014

Hi Chip,

I followed the instructions in the README file with the documentation (in Quick Start Guide paragraph) section to get the BSP but cannot fing the kobs-ng utility. Am I doing the right thing?

Is the patch for the Linux kernel or kobs-ng or both?

Thanks,

Bruno

igorpadykov · ‎05-23-2014

Hi Bruno

if you read patch you will see smth like:

"+++ linux-2.6.35.3_wip/drivers/mtd/nand/nand_base.c"

you can find this file in your sources (linux-2.6.35.3)

and remove line with "-" and add lines with "+".

Then rebuild image.

Regarding yocto please post questions on yocto workplace:

Yocto starting point

https://community.freescale.com/docs/DOC-94023

Best regards

chip

bdp42 · ‎05-23-2014

Hi Chip,

I understand how to apply the path; my question was not phrased very well. The patch is for the Linux kernel and so I don't understand how this fixes the issue you mentioned if the root cause of the problem is in kobs-ng.

You said use the iMX6 kobs OR apply the patch so if I apply the patch to the kernel can I then use my existing kobs-ng

I hope this is clearer.

Bruno

igorpadykov · ‎05-23-2014

Hi Bruno,

could you please first try and check result, will that help ?

Shortly in i.MX5 Linux NAND MTD layer is not setting

properly the geometry. kobs-ng runs on top of MTD layer and

uses kernel information about NANDs.

Best regards

chip

bdp42 · ‎05-23-2014

Hi Chip,

I applied the patch to the Linux kernel and used my original kobs-ng to program NAND. It still does not boot. The symptoms are exactly the same.

Bruno

igorpadykov · ‎05-24-2014

Hi Bruno,

just for narrow down problem:

had you tried with another NAND (preferable 218byte page size)

and boot for example Linux ?

This would help to understand if problem lies in 224 bytes NAND

configuration.

Strictly speaking 224 bytes NAND are not supported

for boot according to i.MX53 Reference Manual.

Regarding flashing NAND image, some hints below:

please refer to attached Add new_NAND support.pdf,

after that one needs to rebuild image.

NAND image should be burned with Manufacturing Tool,

it should be rebuild also (file initramfs.cpio.gz.uboot)

(with new added NAND support), please refer to sect.2.8 "Build

Manufacturing Firmware" attached Linux Guide.

Best regards

chip

bdp42 · ‎05-26-2014

Hi Chip,

We only have the one type of NAND device on our platform. We used the QSB as our reference platform and not the ARD board. So we don't have a reference platform with a NAND device by default.

Do you mean the OOB size in your comment? The actual OOB size of the device is 224 but the OOB size is set to 218 bytes in the nand device table. I did see the comment in the nand device tables source code about this.

We have an issue with the OTG port /Manufacturing tool and so can't use this right now. We boot the OS from the SD card and use this to program the NAND device. We then reconfigure the board to boot from NAND. As far as I can see this should be OK and I think other people have done this.

One this I forgot to mention is that when I run kobs-ng I had to change the search_exponent from the default value of 2 to 3. It seemed to put the Bad block table in the wrong place if I left it at 2 and I had to change it to put the BBT into what I think is the right place. This may be significant.

I will look at the documentation you sent and see if it tells me anything new.

Thanks,

Bruno

igorpadykov · ‎05-26-2014

Hi Bruno,

please follow recommended correct NAND boot sequence given before.

Yes one can boot from SD and use comands as in ucl.xml

(profile "MX53ARD-NAND(JFFS2)") in Mfg Tool folder.

One should not use QSB as reference platform because

it has not NAND on board. You should use i.MX53 ARD board and use Linux

profile (selected in ltib for this board) for software development.

Formally 224 bytes NAND are not supported for boot according to i.MX53 Reference

Manual rev.2.1 6/2012), Table 7-11 "NAND Boot eFUSE Descriptions" -

there is no selection for 224 bytes spare size BOOT_CFG2[7:6].

<http://www.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf>

Best regards

chip

bdp42 · ‎05-26-2014

Hi Chip,

I should clarify that we have a QSB board and do not have an ARD board. So we don't physically have a reference platform that has NAND on board. However we did use the ARD code as the basis for our platform so we are doing as you have suggested.

The OS is Android and so we do not use LTIB.

I am aware that OOB size of 224 is not supported. BOOT_CFG2[7:6] on our board is set to 11 and so is configured for a page size of 4K+218 Bytes. The device has OOB size of 224 but the device tables and boot configuration are both set to 218 so I think this is configured correctly.

Thanks,

Bruno

igorpadykov · ‎05-26-2014

Hi Bruno

I recommend to start with Linux and try supported NAND

(up to 218 spare size).

Also one can try 3.14 kernel below

i.MX53 Quick Start - Linux on ARM - eewiki

Best regards

chip