imx8MQ NAND Boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8MQ NAND Boot

Jump to solution
2,332 Views
rhubert
Contributor II

Hi,

I'va a custom board with a i.MX8MQ and a Micron MT29F2G08A which should be used as boot device.

The flash is detected in linux and u-boot (using SD-boot) and I made some flashcp / dd tests in linux to verify the connection works.

However I'm not able to boot from the flash after writing the image using either kobs-ng in linux or nandbcb in u-boot.

Using the Lauterbach I can see parts of the u-boot-spl loaded to the internal RAM, but starting at a offset of ~9K there is some wrong code ever 2K for 32bytes.

instead of:

00002380 db ff ff 97 00 00 80 52 fd 7b c1 a8 c0 03 5f d6 |.......R.{...._.|
00002390 a0 02 80 12 c0 03 5f d6 fd 7b be a9 e6 03 01 2a |......_..{.....*|

there is

00002380 c0 2b 7e 00 00 00 00 00 04 02 00 00 00 00 00 d6 |.+~.............|
00002390 a0 2b 7e 00 00 00 00 00 04 02 00 00 00 00 00 d6 |.+~.............|

 and 2K later:

00002b80 21 00 80 52 80 09 80 52 e4 ff ff 17 a0 00 00 b0 |!..R...R........|
00002b90 00 38 12 91 d4 0d 00 14 fd 7b be a9 fd 03 00 91 |.8.......{......|
00002b80 c0 33 7e 00 00 00 00 00 05 02 00 00 00 00 00 b0 |.3~.............|
00002b90 00 33 7e 00 00 00 00 00 05 02 00 00 00 00 00 b0 |.3~.............|

 and so on. Reading back the flash from linux the spl-content is correct.

 

u-boot=> nandbcb dump 0
device 0 whole chip
NAND FCB read from 0x0 offset 0x400 read: OK
NAND FCB read from 0x20000 offset 0x400 read: OK
NAND FCB read from 0x40000 offset 0x400 read: OK
NAND FCB read from 0x60000 offset 0x400 read: OK
NAND DBBT read from 0x80000 offset 0x14 read: OK
DBBT data read from 0x82000 offset 0x800 read: OK
NAND DBBT read from 0xa0000 offset 0x14 read: OK
DBBT data read from 0xa2000 offset 0x800 read: OK
NAND DBBT read from 0xc0000 offset 0x14 read: OK
DBBT data read from 0xc2000 offset 0x800 read: OK
NAND DBBT read from 0xe0000 offset 0x14 read: OK
DBBT data read from 0xe2000 offset 0x800 read: OK
FCB
checksum = 0xfffffc34
fingerprint = 0x20424346
version = 0x01000000
datasetup = 80
datahold = 60
addr_setup = 25
dsample_time = 6
pagesize = 2048
oob_pagesize = 2176
sectors = 64
nr_nand = 0
nr_die = 0
celltype = 0
ecc_type = 4
ecc_nr = 512
ecc_size = 512
ecc_level = 4
meta_size = 10
nr_blocks = 3
ecc_type_sdk = 0
ecc_nr_sdk = 0
ecc_size_sdk = 0
ecc_level_sdk = 0
nr_blocks_sdk = 0
meta_size_sdk = 0
erase_th = 0
bootpatch = 0
patch_size = 0
fw1_start = 512
fw2_start = 65792
fw1_pages = 52
fw2_pages = 52
dbbt_start = 256
bb_byte = 1999
bb_start_bit = 0
phy_offset = 2048
bchtype = 0
readlatency = 0
predelay = 0
cedelay = 0
postdelay = 0
cmdaddpause = 0
datapause = 0
tmspeed = 0
busytimeout = 0
disbbm = 0
spare_offset = 0
onfi_sync_enable = 0
onfi_sync_speed = 0
onfi_sync_nand_data = 0
disbbm_search = 0
disbbm_search_limit = 0
read_retry_enable = 0
DBBT :
checksum = 0x00000000
fingerprint = 0x54424244
version = 0x01000000
dbbtpages = 1
0 Firmware: image #0 @ 0x200 size 0x1a000
Firmware: image #1 @ 0x10100 size 0x1a000

 

I have no idea what could cause this? As it's 32Bytes ever 2K it might be the metadata??

 

BR

Ralf

0 Kudos
Reply
1 Solution
2,195 Views
rhubert
Contributor II

For the records: after soldering a 2048+64Byte NAND the ROM-Code is able to boot the image.

View solution in original post

0 Kudos
Reply
9 Replies
2,196 Views
rhubert
Contributor II

For the records: after soldering a 2048+64Byte NAND the ROM-Code is able to boot the image.

0 Kudos
Reply
2,328 Views
igorpadykov
NXP Employee
NXP Employee

Hi Ralf

 

yes this is metadata, description can be found in sect.6.1.5.1.7.2 Metadata

i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual

For nand boot one can look at

https://community.nxp.com/t5/i-MX-Processors/i-MX8MQLite-boot-with-GPMI-raw-nand/m-p/1018402

for nand programming recommended to use uuu tool

https://github.com/NXPmicro/mfgtools

sample uuu scripts can be found in Demo Images (folder ../samples) from link

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

 

Best regards
igor

0 Kudos
Reply
2,325 Views
rhubert
Contributor II

Hi igor,

thanks for the information. I've seen them before. The metadata description is not very useful at all so I can't see that's the metadata from the binary dump. However - why is it in the RAM?

I can't use the uuu as there is no USB on the custom board, but I looked into the xml files to grep the kobs-ng command from uuu. Don't see any difference here.

The MT29F2G08 has a OOB size of 128Byte and 2K pages. Is this supported by the ROM?

BR

Ralf

0 Kudos
Reply
2,313 Views
igorpadykov
NXP Employee
NXP Employee

Hi Ralf

 

>The MT29F2G08 has a OOB size of 128Byte and 2K pages. Is this supported by the ROM?

 

for supported options please look at Table 6-39. NAND Boot Fusemap

i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual

 

> ..why is it in the RAM?

 

seems SPL is loaded to IRAM.

 

Best regards
igor

0 Kudos
Reply
2,311 Views
rhubert
Contributor II

the fusemap doesn't say anything about the OOB size.

https://github.com/NXPmicro/imx-kobs/blob/master/src/mtd.c#L996

This if looks broken?

0 Kudos
Reply
2,290 Views
igorpadykov
NXP Employee
NXP Employee

what is "broken" ? Fuse Map just adds additional specific for i.MX8MQ  restriction

for kobs-ng supported modes.

0 Kudos
Reply
2,282 Views
rhubert
Contributor II

The NAND Boot Fusemap (Table 6-39  of the TRM) shows "Pages in Block" and "NAND Row Address Bytes" as well as some other non relevant configuration options. It doesn't tell anything about the supported NAND flash geometry.

The "if" condition in kobs-ng is always true, either if the SOC matches or if the flash geometry matches (and kobs-ng is executed on a totally different SOC). IMO it should check if the SOC and the geometry is supported, not only one of both. And if the check would work like this it would fail for our flash.

 

Anyway - the question is: Is a NAND-Flash with 2K pages and a oob-size of 128Bytes supported or not? (And if so, what could be the reason for the metadata corrupting the image in IRAM when loaded by the ROM-Code?)

Looking into the BCH registers after the ROM Code has loaded the SPL the BCH_FLASH0LAYOUT1 register shows a PAGE_SIZE of 2112 Bytes (oob-size = 64) which is wrong.

0 Kudos
Reply
2,276 Views
igorpadykov
NXP Employee
NXP Employee

>the question is: Is a NAND-Flash with 2K pages and a oob-size of 128Bytes supported or not?

 

yes supported.

 

>(And if so, what could be the reason for the metadata corrupting the image in IRAM when loaded by the ROM-Code?)

 

please try to follow "officially" supported option: use uuu tool for nand programming.

Please use oficial NXP linux documentation:

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

Other nand programming methods may be supported using NXP Professional Services:


https://contact.nxp.com/new-prof-svcs-sw-tech

 

Best regards
igor

0 Kudos
Reply
2,220 Views
rhubert
Contributor II

The last days I debugged the ROM Code.

At first the AHPB-DMA loads the correct (!) data from the NOR flash into the IRAM. After that the BadBlock marker swapping is executed using the CPU.This works fine as long as I single-step the ROM-Code. As soon as I let it run, the BB-swap corrupts my data! For me this looks like a caching issue / bug in the ROM code.

Can anybody confirm that NAND Boot is really working on i.MX8MQ?

0 Kudos
Reply