kobs-ng / imx-kobs for IMX6UL

[andrewparlane2]

Hi, I have a custom board with an IMX6UL on it. It's set up to boot from NAND flash, specifically: MT29F1G08ABAEAWP.

Currently NAND is empty, and I'm booting using the serial download protocol over UART. Note this board doesn't have USB, so the IMX6 manufacturing tool which I believe also has support for writing the bootloader into NAND won't work for me, as that only support the serial download protocol over USB.

So I boot my custom u-boot, built with:

IMAGE_VERSION 2

BOOT_OFFSET     FLASH_OFFSET_STANDARD

and from there I network boot linux (v4.14 mainline).

Now I'm not really sure what's going on with the kobs-ng tool. I've tried a few different versions of it:

1) It's included in buildroot as:

IMX_KOBS_VERSION = b402243a04e5a6760a860445e5ff6a931d86f794
IMX_KOBS_SITE = $(call github,NXPmicro,imx-kobs,$(IMX_KOBS_VERSION))

Not sure what's going on there, because NXPmicro's github page states there are no public repositories. However it does download, build and run with:

kobs-ng version : [ 1.3 ] git hash (d9473bdcea05d046330c045ca3c32715883b61e5)
ROM Version 5

2) http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/imx-kobs-5.5.tar.gz

which I can build and run, and gives me:

kobs-ng version : [ 1.3 ] git hash (32f144e46f48bcc237f9c686daa3e5a8b2a3d7b1)
ROM Version 5

3) Finally I found it GitHub - codeauroraforum/imx-kobs: Tool to create and write Freescale/NXP I.MX NAND boot related boo... 

kobs-ng version : [ 1.3 ] git hash (c70685de47cfb67c5e16e1631b7033023ca3e97c)
ROM Version 5

So that's three different locations to get the same version (1.3) but with different git hashes.

Then when I try and use it (any version) I get:

Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry"

However with -v I get:

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
/usr/uboot.imx: verifying using key '00000000000000000000000000000000'
/usr/uboot.imx: is a valid bootstream for key '00000000000000000000000000000000'
mtd: Linux 4.14
mtd: use new bch layout raw access mode
mtd: opening: "/dev/mtd0"
mtd: '/dev/mtd0' bad block @ 0x7f80000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x7fa0000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x7fc0000 (MTD)
mtd: '/dev/mtd0' bad block @ 0x7fe0000 (MTD)
Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry"
NFC geometry :
ECC Strength : 8
Page Size in Bytes : 2112
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 = 66584576
mtd: boot_stream_size_in_bytes = 309016
mtd: boot_stream_size_in_pages = 151
mtd: #1 0x00100000 - 0x04080000 (0x0014b718)
mtd: #2 0x04080000 - 0x08000000 (0x040cb718)
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 = 2112
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 = 33024
m_u32PagesInFirmware1 = 151
m_u32PagesInFirmware2 = 151
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
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 = 1
BBTN#0
uNAND = 0
uNumberBB = 4
BADBLOCKS:
0x3fc 0x3fd 0x3fe 0x3ff
Firmware: image #0 @ 0x100000 size 0x4b800 - available 0x3f80000
Firmware: image #1 @ 0x4080000 size 0x4b800 - available 0x3f80000
-------------- Start to write the [ FCB ] -----
mtd: erasing @0:0x0-0x20000
mtd: Writing FCB0 [ @0:0x0 ] (840) *
mtd: erasing @0:0x20000-0x40000
mtd: Writing FCB1 [ @0:0x20000 ] (840) *
mtd: erasing @0:0x40000-0x60000
mtd: Writing FCB2 [ @0:0x40000 ] (840) *
mtd: erasing @0:0x60000-0x80000
mtd: Writing FCB3 [ @0:0x60000 ] (840) *
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

mtd: PUTTING down DBBT0 BBTN0 @0x82000 (0x800)
mtd: PUTTING down DBBT1 BBTN0 @0xa2000 (0x800)
mtd: PUTTING down DBBT2 BBTN0 @0xc2000 (0x800)
mtd: PUTTING down DBBT3 BBTN0 @0xe2000 (0x800)
---------- Start to write the [ /usr/uboot.imx ]----
mtd: Writting /usr/uboot.imx: #0 @0: 0x00100000 - 0x0014b800
mtd: erasing @0:0x100000-0x120000
mtd: erasing @0:0x120000-0x140000
mtd: erasing @0:0x140000-0x160000
mtd: The last page is not full : 1816
mtd: We write one page for save guard. *
mtd: Writting /usr/uboot.imx: #1 @0: 0x04080000 - 0x040cb800
mtd: erasing @0:0x4080000-0x40a0000
mtd: erasing @0:0x40a0000-0x40c0000
mtd: erasing @0:0x40c0000-0x40e0000
mtd: The last page is not full : 1816
mtd: We write one page for save guard. *

Which looks like it's actually working.

If I try to dump the flash:

# nanddump /dev/mtd0 -c -l 1 -o

ECC failed: 0
ECC corrected: 24
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00000001...
ECC: 8 corrected bitflip(s) at offset 0x00000000
0x00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0x00000010: 00 00 00 00 00 00 2f fb ff ff 46 43 42 20 00 00 |....../...FCB ..|
0x00000020: 00 01 50 3c 19 06 00 00 00 00 00 08 00 00 40 08 |..P<..........@.|
0x00000030: 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 |..@.............|

Note the bit about 8 corrected bitflips.

Then I use kobs-ng to dump the data

# kobs-ng dump
Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry"
mtd: fingerprints mismatch @0:0x0
mtd: fingerprints mismatch @0:0x20000
mtd: fingerprints mismatch @0:0x40000
mtd: fingerprints mismatch @0:0x60000
mtd: NCB0 not found
mtd: fingerprints mismatch @0:0x80000
mtd: fingerprints mismatch @0:0xa0000
mtd: fingerprints mismatch @0:0xc0000
mtd: fingerprints mismatch @0:0xe0000
mtd: NCB1 not found
mtd: neither NCB1 or NCB2 found ERROR
Unable to load boot structures

So it's not happy, and predictably if I reboot it doesn't actually boot (Although I haven't set up the boot 

In the IMX6UL TRM section 8.5.2.3 Firmware Configuration Block, in table 8-11, it says finger print should be

32 bit word with a value of 0x4E434220, in ascii
"FCB"

Whereas in the output from kobs-ng init -v I have: m_u32FingerPrint = 0x20424346

Which is close, but there is 0x46 vs 0x4E, + the endieness. This is also shown in the nanddump.

So my questions:

1) Where should I be getting kobs-ng / imx-kobs from? Is there source available directly from NXP?

2) Do I need to do anything special to write the correct data to NAND for an IMX6UL?

Thanks,

Andrew

[maxvankessel1]

Hello Henri,

Short answer: yes

Long answer:

The function of the SPL is the enable and configure the DRAM, timings etc.

A SPL is not required, even NXP does not provide support for SPL on the iMX6ULL series. But...

NXP has proprietary plugin code (which is available after signing a NDA), this does the same things as the SPL.

The function of the SPL or the Plugin is required, since some piece of code must start the DRAM, otherwise no program could be loaded from NAND to DRAM. (You can't execute directly from NAND)

All this code (SPL or plugin) needs to fit inside the OCRAM sector, which is about 65kB, which is quite small for a full blown uboot. This is executed by the ROM code, inside the processor, the outline of this procedure is described in the reference manual.

There might be one more boot procedure, but it's been a while for me.

We've changed the DRAM type, PCB layout and PCB itself, which all had an influence on the DRAM calibration. So I've found configuring the DRAM through SPL more clear.

I hope this helps you

Max

[henrideveer]

I know the OCRAM is incorrectly specified for the imx6ul, it is 128KiB. It is incorrect in the U-Boot arch-imx6/imx-regs.h specified as IRAM_SIZE 0x40000 and should have been 0x20000 for the imx6ul. The rom loader also uses it for internal housekeeping and stack so you are probably correct that effectively 65K is left over. But that is irrelevant here.

We have an old image containing an IVT +  DCD + U-Boot (The DCD contains the DRAM init write sequence and calibration stuff) that does work already, so no SPL as far as i know (all dated 2015 from a yocto build).

But it was programmed via the kobs-ng in the past, so I don't know if there was an SPL added via some way in the past (via kobs-ng?).

Note: I have seen some plugin "....S" file in the old project tree but not seen any docs or comments what it does or how it is used, but it looks to me that it is duplicating the DCD writes. But the plugin only contains some macros which could write the MMDC registers (so it is probably included by the SPL source code?).

But now I'm upgrading to the latest U-Boot and kernel (with buildroot) and struggling to get all the headers, FCB, DBBT, and u-boot.imx at the right place to get a booting board (so without using the kobs-ng tool but with using nandbcb).

It is not clear to me what should be exactly in the headers of the very first block(s) and if there is a pointer in the FCB to the IVT+DCD+U-Boot image (=u-boot.imx) or some other mechanism how the rom loader finds its stuff.

Flashing the u-boot.imx file via the nandbcb command at sector 0 does not result in a working U-Boot yet. So the question is how is the flash layout exactly organized?

Henri

[maxvankessel1]

I see you studied both u-boot and the reference manual. It took me quite a while to see the complete picture.

The u-boot.imx is the complete image (with IVT and DCD) but without the BCB (FCB & DBBT). So this image could be flashed to any media device.

I wonder at what place (address) you do flash your images? And what type of NAND chip you are using?

Might it be you try to flash the image at address 0? I might have the wrong feeling, but the problem you describe sounds like that.

So, we have a 128MiB NAND flash chip. And the following mtdparts:

gpmi-nand:256k(nandbcb),128k(spl),512k(u-boot),128k(u-boot-env),8m(kernel),128k(dtb),16m(ramdisk),-(ubi)

Note that the nandbcb sector is just a place holder.

Following text is from (an internally) how to flash document:

Prerequisite: the device is booted with u-boot.imx through UUU

Flash both SPL and u-boot(.img) to the device at the correct partitions.

So first the SPL (u-boot.imx in your case) is written to NAND, because we couldn't write directly to DRAM, otherwise you can skip this step and write straight into DRAM.

$ nand read $loadaddr spl [filesize]

$ nand erase.part spl

This step re-writes the SPL in the `spl` partition, and takes account for various offsets.

The first MTD sector (nandbcb) is not mentioned, because the u-boot code finds the first 2 pages and writes it, and makes a backup at the next sector.

$ nandbcb update $loadaddr spl <filesize>

$ reset

Its for a SPL, but I believe it's the same for an u-boot.imx

There is also a Boot Utility (Java program) from NXP, which attaches to the SDP (romloader) and reports the bootstages and errors. It's available on this forum, somewhere.

[james_mccusker]

The nandbcb command is to be released in the 2019.10 version of U-Boot, correct? Is there (do you have/can you share) an example of how to use this command? (Much appreciated, btw!)

[parthitce]

jamesmccusker james.mccusker@us.bosch.com You need to get the SPL into RAM (either using TFTP or SDP) from u-boot. I do this with TFTP. Sample commands below,

setenv autoload no

dhcp

setenv serverip xx.xx.xx.xx (do this if your DHCP server is not providing the correct TFTP server)

tftp $loadaddr SPL

setenv mtdparts "gpmi-nand:512k(spl),512k(uboot),512k(uboot-dup),-(ubi)" (tune it as per your needs)

nandbcb update $loadaddr spl $filesize (here spl is the name of the MTD SPL partition)

Yes, the patch is not yet merged. But I already send v2 yesterday : U-Boot - Patchwork I hope it will be merged soon, but am not sure about stable release it will be in. As there isn't much dependency, you can cherry-pick them.

[maxvankessel1]

Hello Parthiban,

I've followed your instruction for flashing, u-boot v2019.10-rc2 with your patch to extend nandbcb for iMX6ULL.

But the ROM code fails to load the SPL, the page address which is loading from is 0. See bootlog below

And artifacts of this this page can be found on address: 0x907400

I've dumped the nand contents from both u-boot and linux.

Linux tells me the (Firmware1_startingPage) byte 104 has value 0x00000080.

It looks like the iMX6UL(L) takes Firmware2_startingPage to start, which is not present.

Because this is a bootlog when I use kobs-ng:

I've highlighted the bytes below (104)

Page 00000000 dump:
    [00] 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    [10] 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    [20] 40 fc  ff ff  46  43  42  20  00 00 00 01 50 3c 19 06
    [30] 00 00 00 00 00 08 00 00  40 08 00 00 40 00 00 00
    [40] 00 00 00 00 00 00 00 00  00 00 00 00 04 00 00 00
    [50] 00 02 00 00 00 02 00 00  04 00 00 00 0a 00 00 00
    [60] 03 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    [70] 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
    [80] 00 00 00 00 00 00 00 00  80 00 00 00 00 00 00 00
    [90] 20 00 00 00 00 00 00 00  01 00 00 00 cf 07 00 00

Could you tell me what I'm looking at or why it could not boot?

Max

[parthitce]

Hi maxvankessel‌ maxvankessel@betronic.nl‌,

Today I had access to imx6ULL + NAND based board (MYS-6ULX | NXP iMX6UL, iMX6ULL SBC Board for IoT and Industry Applications-Welcome to MYIR ) and checked the nandbcb command. nandbcb command worked perfectly fine with ULL as well.

Thanks,

Parthiban N

[maxvankessel1]

Hi parthitce,

We also have good results with uboot v2020.01,

small modification in the bcbonly cmd for fw2 when fw1 fails (jumps to (hardcoded) 0).

Thank you for the work you've done on u-boot, it's appreciated.

[igorpadykov]

could you try with nxp releases and tools described on i.mx official software page

i.MX Software|NXP 

Best regards
igor