kobs-ng / imx-kobs for IMX6UL

andrewparlane2 · ‎06-15-2018

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

igorpadykov · ‎06-17-2018

Hi Andrew

one can to try with nxp bsp releases on

linux-imx - i.MX Linux kernel

or with demo images from

i.MX Software|NXP

kobs-ng sources

cafatgithub/imx-kobs - i.MX tool for flashing NAND boot to nand flash

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

andrewparlane2 · ‎06-19-2018

Hi Igor, thanks for the reply.

The source you linked to is the same as is github at the link I posted. So it's good to know I've got the latest. Unfortunately it being the same means it won't fix my issues.

I can't test the demo images, since I'm using a custom board, so an image for the imx6ul-evk won't boot for me.

I could try building and booting an NXP kernel, but we're pretty keen to stick with the mainline kernel for compatibility with other projects.

I guess at this point, I'm more interested in the finger print mismatch. Copied from my first post:

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

Is the TRM wrong or the imx-kobs tool?

Also The value from the TRM is: 0x4E434220 which is actually Ascii "NCB ", but as you can see the comment says it is "FCB". The imx-kobs uses "FCB ".

This can't be attributed to the kernel being mainline 4.14.

Any suggestions?

andrewparlane2 · ‎06-19-2018

Updates - the plot thickens.

1) The TRM states that the FCB starts at offset zero. It claims the second word "fingerprint2" is "FCB ", but gives hex values for "NCB ". The latest imx-kobs tool writes "FCB ", but to offset 0x16 = 22.

2) Figure 8-5 in the TRM is the FCB search flow state machine. Note that the final state is "NCB found". There are no other references to NCB in the entire TRM.

3) The imx-kobs tool tries to read the BCH geometry from /sys/kernel/debug/gpmi.nand/bch_geometry, which was introduced in this patche: linux-2.6-imx.git - Freescale i.MX Linux Tree However The data written to debugfs is the bch_geometry structure defined here: linux-2.6-imx.git - Freescale i.MX Linux Tree (note: this is at the time of the above patch). This data gets read by the imx-kobs tool intol it's nfc_geometry struct. However the nfc_geometry struct found here: mtd.h\src - cafatgithub/imx-kobs - i.MX tool for flashing NAND boot to nand flash does not match the bch_geometry struct used in linux. The bch_geometry struct has not changed between this version at the time of the above linux patch, and my current 4.14 kernel. So I'm not sure how the imx-kobs tool is meant to work.

4) When I cherry-picked the debugfs patch to my kernel, and fixed the imx-kobs tool to properly read that data, I find that the NFC geometry that was read vs that which was calculated differ. Specifically:

calculated: Page Size in Bytes : 2112

read: Page Size in Bytes : 2110

5) The imx-kobs dump command looks for a NCB. mtd_load_all_boot_structures() calls mtd_load_boot_structure() with: magic1 504D5453, magic2 2042434E, magic3 4E494252, magic_offset 12, offs 0. This reads the first page and casts that read data to be a NCB_BootBlockStruct_t. It checks if fingerprint1 == magic1, and fingerprint2 == magic2 and fingerprint3 == magic3. If they aren't, it tries again at magic_offset (12 bytes). Remember the TRM makes precisely 1 reference to a NCB, and that looks like a typo. Additionally the imx-kobs tool doesn't seem to write a NCB for the imx6ul. So maybe the imx-kobs tool doesn't support the dump command for imx6ul?

6) In the imx-kobs tool, ncb.c fcb_encrypt() takes a parameter "version". The comment defines it as:

* version: The version number of the NCB.

At the end of that function there's a switch(version). In the default case there is:

fprintf(stderr, "FCB version == %d? Something is wrong!\n", version);

So which is it? The NCB or the FCB version? I'm assuming NCB, since for the IMX6UL the FCB version should be 1 (from the TRM), and in the imx6ul case this version is set to be 3.

7) This blog: Booting from NAND flash on i.MX6-based platforms - DAVE Developer's Wiki states that the NCB is block that is inside the FCB. However none of the members of the FCB in either the TRM or the code is related to NCB. The only time the code uses the NCB fingerprint "NCB" is in v0_rom_mtd_init() which is only called for IMX23 devices.

8) In the imx-kobs tool, bch.c encode_bch_ecc() m is set to 32. This seems to be the metadata size, and causes the FCB data to be offset 32 bytes in the NAND block. However the linux GPMI driver sets metadata_size to 10 (mainline 4.14 and the NXP version with the debugfs patch). So this difference is 12 bytes explains why the FCB data turns up at an offset of 12 when I call nanddump. I'm not really sure what this metadata is, or how it's used. However having hardcoded values that differ between kobs and linux sounds like a bad idea.

So, what's going on here? I can't see how the latest imx-kobs tool has ever worked with the IMX6UL no matter which kernel version.

Has anyone had any experience with this?

Can I get in touch with an engineer who worked on this tool?

Is there any additional documentation about what structures are expected to be in NAND and where so that the IMX6UL boot ROM will detect and boot an image.

I'm confident I can "fix" the imx-kobs tool to correctly detect and dump my boot structures, however without knowing for sure what structures are expected where, I can't expect my fixes to actually let me boot a board.

Thanks,

Andrew

edit: Added 6), 7) and 8)

parthitce · ‎07-11-2019

Dear Andrew, andrewparlane‌ andrewparlane2‌

I am currently in the same situation for the Phytec SoM (i.MX 6UL NXP ARM Cortex-A7 System on Module | PHYTEC ). I am still not successful in booting the SPL from NAND.

Do you have further update or success with this problem of using kobs-ng with imx6UL?

Thanks in advance,

Parthiban N

maxvankessel1 · ‎04-06-2020

For people still looking for an answer on this matter, I've successfully created a SPL with support for NAND booting.

This is part of the readme I've created to flash. I hope this will explain some of the questions

## Partitions

U-Boot partitions are stored in a configuration `CONFIG_MTDPARTS_DEFAULT` and 
 this is stored in the environment, which has a fixed offset (compiled in)

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

I would recommend to leave the `nandbcb`, `spl` as is. Others can be changed, 
but note other variables/configuration might have to change as well.
The `SPL` has fixed address to scan `nand` for `u-boot` image. 
Which is `0x60000` (384kB).

`U-Boot ` does the same for as the `SPL` for the environment.
Only recompilation of the whole set can make it work again.

### Flasing u-boot (with SPL)

`$ nand read $loadaddr spl [filesize]`

`$ nand erase.part spl`

`$ nandbcb update $loadaddr spl <filesize>`

`$ nand read $loadaddr u-boot [filesize]`

`$ nand erase.part u-boot`

`$ reset`

_NOTE: Max file size of spl is 65kB_

Sorry for the formatting.

Note that the SPL size if 65kB max, this is for the i.MX6ULL this is the OCRAM size. The SPL is run from this location, so it can initialize the DDR memory. (see reference manual)

Also note the nandbcb partition, this isn't used you might think. It is actually, by nandbcb. It takes the first 2 pages (256kB pagesize * 2 = 512kB) (which is described in the reference manual) and writes them with the correct settings for nand operations. So I've declared it explicit.

You might think, why is the nand reading and writting so slow, then you might want to check the clock domain for the ENFC

 /* Set ENFC_ROOT clock to 200MHz (pll2_pfd2 div 2), 198MHz maxspeed? */
 /* Default value is 176MHz (pll2 pfd0 div 2) */
 setup_gpmi_io_clk(MXC_CCM_CS2CDR_ENFC_CLK_SEL(3) | MXC_CCM_CS2CDR_ENFC_CLK_PRED(1));

parthitce · ‎08-26-2020

nandbcb update option is renamed/removed in recent version of u-boot. I did add a README to my board in u-boot here: board/myir/mys_6ulx/README · master · U-Boot / U-Boot · GitLab using "nandbcb init"

andrewparlane · ‎07-11-2019

Nope, we gave up and put some SPI flash on the board instead. There is (or was) no useful documentation on how to write bootable code to NAND flash, and I found no working code. Then nobody here had any useful tips either.

Hopefully there's been some updates and you'll find something useful.

Sorry I couldn't help. Good luck.

mihaitaivascu · ‎07-02-2018

Hi,

I have also a kobs-ng tool related issue on a imx6ul from Phytec: whenever I try to flash the barebox.bin bootloader using kobs-ng from inside MFG xml commands I get the following crash:

UTP: received command '$ kobs-ng init -x -v --chip_0_device_path=/dev/mtd0 $FILE'
UTP: executing "kobs-ng init -x -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
-- 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: Linux 4.8
mtd: use new bch layout raw access mode
mtd: opening: "/dev/mtd0"
Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry"
NFC geometr[ 6.260720] ------------[ cut here ]------------
[ 6.266720] Kernel BUG at c057cdfc [verbose debug info unavailable]
[ 6.273007] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 6.278162] Modules linked in:
[ 6.281264] CPU: 0 PID: 111 Comm: kobs-ng Not tainted 4.8.0 #18
[ 6.287200] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 6.293399] task: c3e23c00 task.stack: c3e54000
[ 6.297963] PC is at nand_fill_oob+0x44/0xac
[ 6.302258] LR is at mtd_ooblayout_free+0x5c/0x74
[ 6.306988] pc : [<c057cdfc>] lr : [<c055f88c>] psr: a0000013
[ 6.306988] sp : c3e55ca0 ip : c3e55bf0 fp : c3e55cc4
[ 6.318488] r10: c3e84000 r9 : 00000100 r8 : 00000000
[ 6.323732] r7 : 00000000 r6 : c3e55dc8 r5 : de42e0b8 r4 : 00000010
[ 6.330278] r3 : c3e55c50 r2 : c3e55c50 r1 : 00000001 r0 : ffffffde
[ 6.336826] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 6.343978] Control: 10c5387d Table: 83e7c06a DAC: 00000051
[ 6.349741] Process kobs-ng (pid: 111, stack limit = 0xc3e54210)
[ 6.355765] Stack: (0xc3e55ca0 to 0xc3e56000)
[ 6.360151] 5ca0: 00000000 c3e55cb0 de42e0b8 00000800 00000800 00000000 c3e55d34 c3e55cc8
[ 6.368354] 5cc0: c057d19c c057cdc4 c3e55cec c3e55cd8 c0964e78 c0173f98 de42e0b8 de42e710
[ 6.376554] 5ce0: c3e55d34 0000003f 00000000 00000000 00000000 00000010 00000010 c3e84000
[ 6.384757] 5d00: 00000100 00000000 60000013 c3e55dc8 de42e0b8 00080000 00000000 00000800
[ 6.392958] 5d20: 00000000 00000000 c3e55d5c c3e55d38 c057d6a8 c057ce70 c3e55dc8 c3e55d48
[ 6.401160] 5d40: 00000000 00000000 00080800 00000000 c3e55d84 c3e55d60 c0562670 c057d614
[ 6.409361] 5d60: c3e55dc8 00000800 c0562604 00000051 c3cf8800 be92cac8 c3e55da4 c3e55d88
[ 6.417564] 5d80: c055ec9c c0562610 c3e55dc8 be92cac8 00000800 0144a110 c3e55edc c3e55da8
[ 6.425764] 5da0: c0564b8c c055ec64 c3e55dc8 00000002 c0f229e8 00000000 c3e55e4c c3e55dc8
[ 6.433966] 5dc0: c016f49c c016e4e8 00000001 00000800 00000000 00000000 00000000 00000000
[ 6.442168] 5de0: c3e84000 00000010 00080000 00000000 00000800 00000000 00000000 00000000
[ 6.450371] 5e00: 01449910 00000000 0144a110 00000000 00000001 00080000 c3e54000 00000000
[ 6.458574] 5e20: c3e55e54 c3e55e30 c016ec14 c016e4e8 c096101c c3e23c00 00000001 c173d414
[ 6.466776] 5e40: c3e23c00 c3e54000 c3e55e74 c3e55e58 c016ed78 c016ebb4 c0f35cc4 60000013
[ 6.474977] 5e60: c0f35cc8 c173d414 c3e55e84 c3e55e78 c016ee44 c016ec48 c3e55edc c3e55e88
[ 6.483180] 5e80: c096101c c016ee3c 00000001 00000000 c056554c c3e55ea0 c0962da4 c014e30c
[ 6.491381] 5ea0: 00000001 c3e55ea0 c3e55edc c0f35cc4 00000000 c0f35cc4 c3e40780 c0304d18
[ 6.499583] 5ec0: be92cac8 00000007 c3e54000 00000000 c3e55efc c3e55ee0 c056555c c0564130
[ 6.507785] 5ee0: be92cac8 de7f7ba8 c3e40780 c02319c4 c3e55f7c c3e55f00 c0230fc0 c0565530
[ 6.515987] 5f00: de645648 c022d69c 00000002 de5e22f8 ffffff9c c3dc0000 00000000 00000000
[ 6.524188] 5f20: c3e54000 0000002a de645640 de5e22f8 00000002 de645648 c3e54000 00000000
[ 6.532390] 5f40: c3e55f7c c3e55f50 c021e030 c02610a0 00000000 c3e40780 00000007 c3e40780
[ 6.540592] 5f60: c0304d18 be92cac8 c3e54000 00000000 c3e55fa4 c3e55f80 c02319c4 c0230f30
[ 6.548794] 5f80: 01448838 00000000 00000001 00000036 c0107fc4 c3e54000 00000000 c3e55fa8
[ 6.556994] 5fa0: c0107e20 c0231994 01448838 00000000 00000007 c0304d18 be92cac8 00000000
[ 6.565197] 5fc0: 01448838 00000000 00000001 00000036 01449910 00000800 00000800 01448838
[ 6.573398] 5fe0: 0003f064 be92ca9c 0001470c b6f03b9c 20000010 00000007 e7fddef0 e7fddef0
[ 6.581588] Backtrace:
[ 6.584094] [<c057cdb8>] (nand_fill_oob) from [<c057d19c>] (nand_do_write_ops+0x338/0x41c)
[ 6.592375] r7:00000000 r6:00000800 r5:00000800 r4:de42e0b8
[ 6.598153] [<c057ce64>] (nand_do_write_ops) from [<c057d6a8>] (nand_write_oob+0xa0/0xc0)
[ 6.606343] r10:00000000 r9:00000000 r8:00000800 r7:00000000 r6:00080000 r5:de42e0b8
[ 6.614296] r4:c3e55dc8
[ 6.616881] [<c057d608>] (nand_write_oob) from [<c0562670>] (part_write_oob+0x6c/0x7c)
[ 6.624810] r7:00000000 r6:00080800 r5:00000000 r4:00000000
[ 6.630584] [<c0562604>] (part_write_oob) from [<c055ec9c>] (mtd_write_oob+0x44/0x5c)
[ 6.638426] r7:be92cac8 r6:c3cf8800 r5:00000051 r4:c0562604
[ 6.644206] [<c055ec58>] (mtd_write_oob) from [<c0564b8c>] (mtdchar_ioctl+0xa68/0x1400)
[ 6.652222] r4:0144a110
[ 6.654808] [<c0564124>] (mtdchar_ioctl) from [<c056555c>] (mtdchar_unlocked_ioctl+0x38/0x50)
[ 6.663346] r10:00000000 r9:c3e54000 r8:00000007 r7:be92cac8 r6:c0304d18 r5:c3e40780
[ 6.671301] r4:c0f35cc4
[ 6.673887] [<c0565524>] (mtdchar_unlocked_ioctl) from [<c0230fc0>] (do_vfs_ioctl+0x9c/0xa64)
[ 6.682424] r7:c02319c4 r6:c3e40780 r5:de7f7ba8 r4:be92cac8
[ 6.688195] [<c0230f24>] (do_vfs_ioctl) from [<c02319c4>] (SyS_ioctl+0x3c/0x64)
[ 6.695518] r10:00000000 r9:c3e54000 r8:be92cac8 r7:c0304d18 r6:c3e40780 r5:00000007
[ 6.703473] r4:c3e40780
[ 6.706055] [<c0231988>] (SyS_ioctl) from [<c0107e20>] (ret_fast_syscall+0x0/0x1c)
[ 6.713638] r9:c3e54000 r8:c0107fc4 r7:00000036 r6:00000001 r5:00000000 r4:01448838
[ 6.721520] Code: 0a00000c 3a000002 e3530002 0a000000 (e7f001f2)
[ 6.727641] ---[ end trace 7b232f3f07a2af01 ]---
y :
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 = 4718592
mtd: boot_stream_size_in_bytes = 547983
mtd: boot_stream_size_in_pages = 268
mtd: #1 0x00100000 - 0x00580000 (0x00185c8f)
mtd: #2 0x00580000 - 0x00a00000 (0x00605c8f)
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 = 2816
m_u32PagesInFirmware1 = 268
m_u32PagesInFirmware2 = 268
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 = 0
Firmware: image #0 @ 0x100000 size 0x86000 - available 0x480000
Firmware: image #1 @ 0x580000 size 0x86000 - available 0x480000
-------------- 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) *
[ 185.850179] random: crng init done

Anybody knows what could be the issue here?

Thanks,

Mihaita

mahi · ‎07-11-2019

@Parthiban Nallathambi @Mihaita Ivascu

You have to mount debugfs in order to use kobs-ng.

According to the error message "Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry" this has not been done.

Execute the following command before running kobs-ng:

 mount -t debugfs debugfs /sys/kernel/debug

mihaitaivascu · ‎10-15-2019

Hello,

Do you have any other idea why I could still get that crash even though debugfs is mounted?

Thanks,

Mihaita

mahi · ‎10-15-2019

Does the kernel Oops also happen also when trying to cat /sys/kernel/debug/gpmi-nand/bch_geometry?

Perhaps there is an issue in the kernel support for your specific flash device.
If you post the flash relevant parts of dmesg (e.g. dmesg | grep -i -A5 nand), perhaps someone can tell more.

mihaitaivascu · ‎10-17-2019

Hello,

UTP: executing "dmesg | grep -i -A5 nand"
[ 2.512511] jffs2: version 2.2. (NAND) \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc.
[ 2.517233] fuse init (API version 7.25)
[ 2.541473] io scheduler noop registered
[ 2.541526] io scheduler deadline registered
[ 2.542723] io scheduler cfq registered (default)
[ 2.544588] imx-weim 21b8000.weim: Driver registered.
--
[ 3.595652] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
[ 3.602143] nand: Micron MT29F4G08ABADAH4
[ 3.606208] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 3.615956] gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
[ 3.624249] Bad block table found at page 262080, version 0x01
[ 3.631413] Bad block table found at page 262016, version 0x01
[ 3.639059] 6 ofpart partitions found on MTD device gpmi-nand
[ 3.644956] Creating 6 MTD partitions on "gpmi-nand":
[ 3.650075] 0x000000000000-0x000000500000 : "barebox"
[ 3.672468] 0x000000500000-0x000000540000 : "barebox-environment"
[ 3.687630] 0x000000540000-0x000000580000 : "maker"
[ 3.701764] 0x000000580000-0x000006980000 : "fit1"
[ 3.830075] 0x000006980000-0x00000cd80000 : "fit2"
--
[ 4.087156] gpmi-nand 1806000.gpmi-nand: driver registered.
[ 4.099959] libphy: Fixed MDIO Bus: probed
[ 4.107371] CAN device driver interface
[ 4.117182] usbcore: registered new interface driver asix
[ 4.123101] usbcore: registered new interface driver ax88179_178a
[ 4.129548] usbcore: registered new interface driver cdc_ether
UTP: sending Success to kernel for command $ dmesg | grep -i -[ 6.540889] utp_poll: pass returned.

There is no /sys/kernel/debug/gpmi-nand/bch_geometry even though UTP reported that debugfs has been mounted

UTP: received command '$ mount -t debugfs debugfs /sys/kernel/debug'
UTP: executing "mount -t debugfs debugfs /sys/kernel/debug"
UTP: sending Success to kernel for command $ mount -t debugfs debugfs /sys/kernel/debug.
[ 6.019658] utp_poll: pass returned.

but

UTP: executing "find / -name gpmi-nand"
/sys/bus/platform/drivers/gpmi-nand

...........................................

UTP: received command '$ ls /sys/kernel/debug'
UTP: executing "ls /sys/kernel/debug"
asoc dma_buf ieee80211 pwm ubi
bdi dri iio ras ubifs
bluetooth extfrag memblock regmap usb
ci_hdrc.0 fault_around_bytes opp regulator wakeup_sources
ci_hdrc.1 gpio pinctrl sleep_time
clk hid pm_qos suspend_stats
UTP: sending Success to kernel for command $ ls /sys/kernel/debug.

Thanks,

Mihaita

parthitce · ‎10-15-2019

Hi mihaitaivascu‌

In my side I have checked only with imx6UL + NAND and it worked fine. But I don't have imx6ULL + NAND based versions with me, so I couldn't check this. But this should ideally work.

I don't recommend using kobs-ng with mainline kernel as the details which is required by the utility are specific to vendor kernel. I never had success with this utility so far (both in vendor kernel + mainline version). The way GPMI nand driver sees the value which are flashed is not the same between two kernels.

Regarding the nandbcb command part, did you already check flashing using it in u-boot latest version? This patch is still not merged in mainline u-boot due to some errors with imx6q/dl versions. So flashing in u-boot and dump it in Linux using mtd-utils may not show the same values. Could you erase and re-flash using nandbcb and share the dump which in u-boot for the NAND?

Ideally I don't see any big difference in RM of UL and ULL regarding this.

Thanks,

Parthiban N

mihaitaivascu · ‎10-17-2019

Hello,

Thanks a lot for your reply. Could you give me a alternative command to kobs-ng? I try to flash on an mtd partition the barebox bootloader from MFGTools

and his kobs-ng utility always complains about NAND BCH geometry.

Do you have a working solution/script for imx6ul for NAND that I could use as an example?

I will try checking with nandbcb as suggested. Have not done anything so far.

Thanks,

Mihaita

parthitce · ‎10-18-2019

Hi,

I don't think we have an alternative utility for the same purpose. Assuming you have nand chip and using the u-boot gpmi parts, the below example command will help you flash nand with SPL + u-boot.

Commands:

setenv mtdparts "gpmi-nand:512k(spl),1m(uboot),1m(uboot-dup),-(ubi)"

nand erase.part spl
nand erase.part uboot

tftp $loadaddr pn/SPL
nandbcb update $loadaddr spl $filesize
tftp $loadaddr pn/u-boot-dtb.img
nand write ${loadaddr} uboot ${filesize}

This is how I copy the SPL and u-boot into memory and write into nand. This also assumed that you have the same u-boot offset and redundant offset configured in menuconfig for SPL. Else SPL will look for u-boot in wrong offset and it won't boot.

But you need a running SPL and u-boot hush shell to do this. If you have SD, you can boot from SD and flash the NAND or else you can load the SPL and u-boot using imx_usb_loader.

Latest version: [U-Boot,v3] i.MX6: nand: extend nandbcb command for imx6UL(L) - Patchwork

Thanks,

Parthiban N

Contact: pn@denx.de

mihaitaivascu · ‎09-25-2019

I do this already.

UTP: received command '$ mount -t debugfs debugfs /sys/kernel/debug'
UTP: executing "mount -t debugfs debugfs /sys/kernel/debug"
UTP: sending Success to kernel for command $ mount -t debugfs debugfs /sys/kernel/debug.
[ 6.012666] utp_poll: pass returned.
UTP: received command '$ flash_erase /dev/mtd0 0 0'
UTP: executing "flash_erase /dev/mtd0 0 0"
Erasing 128 Kibyte @ 4100340[ 6.273122] utp_poll: pass returned.
Erasing 128 Kibyte @ 64004e0000 -- -1 % complete
UTP: sending Success to kernel for command $ flash_erase /dev/mtd0 0 0.
UTP: received command 'send'
UTP: sending Success to kernel for command send.
UTP: received command '$ kobs-ng init -x -v --chip_0_device_path=/dev/mtd0 $FILE'
UTP: executing "kobs-ng init -x -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
-- 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: Linux 4.8
mtd: use new bch layout raw access mode
mtd: opening: "/dev/mtd0"
Cannot open BCH geometry node: "/sys/kernel/debug/gpmi-nand/bch_geometry"
NFC geometry[ 6.447061] ------------[ cut here ]------------
[ 6.454235] Kernel BUG at c057cdfc [verbose debug info unavailable]
[ 6.460533] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 6.465696] Modules linked in:
[ 6.468812] CPU: 0 PID: 108 Comm: kobs-ng Not tainted 4.8.0 #18
[ 6.474754] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 6.480962] task: c3d64800 task.stack: c3e66000
[ 6.485533] PC is at nand_fill_oob+0x44/0xac
[ 6.489840] LR is at mtd_ooblayout_free+0x5c/0x74
[ 6.494579] pc : [<c057cdfc>] lr : [<c055f88c>] psr: a0000013
[ 6.494579] sp : c3e67ca0 ip : c3e67bf0 fp : c3e67cc4
[ 6.506085] r10: c3d89800 r9 : 00000100 r8 : 00000000
[ 6.511339] r7 : 00000000 r6 : c3e67dc8 r5 : de42e0b8 r4 : 00000010
[ 6.517893] r3 : c3e67c50 r2 : c3e67c50 r1 : 00000001 r0 : ffffffde
[ 6.524448] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 6.531608] Control: 10c5387d Table: 83e6806a DAC: 00000051
[ 6.537378] Process kobs-ng (pid: 108, stack limit = 0xc3e66210)
[ 6.543410] Stack: (0xc3e67ca0 to 0xc3e68000)

So it must be another reason for the crash when running kobs-ng command.

Thanks,

Mihaita

mihaitaivascu · ‎09-26-2019

Could somebody give me some guidance in this topic still?

Thanks,

Mihaita

parthitce · ‎07-12-2019

mahi‌ andrewparlane andrewparlane2 Thanks for your response. The main problem here is, am using mainline Linux Kernel 4.19.58 for my custom board. I have debugfs mounted, but I don't have the fsl patches for gpmi-nand, which exports the fields needed by kobs-ng.

But I also see patches in imx-kobs which handles when there is no gpmi-nand (i.e kernel without fsl patch) here: imx-kobs: Allow kobs-ng to flash the SPL on the 4.x kernel - Patchwork This patch is already merged into kobs-ng tool, so I am not sure whether this is really problem or restriction to use fsl kernel alone.

To add, I am currently re-working on u-boot patch for a new command 'nandbcb' which handles to write the FCB and DBBT along with Firmware itself : [U-Boot,v6,1/3] i.MX6: nand: add nandbcb command for imx - Patchwork I see this patch supports imx6q, but not imx6ul still. Only difference between q and ul from TRM 8.5.2.2 is BCH/ECC is 40 bits for UL if I am not wrong. Adding to that, barebox already supports this feature of writing to NAND using imx-bbu-nand-fcb.c\common - barebox - barebox master repository handler.

parthitce · ‎07-18-2019

mahi‌ andrewparlane‌ andrewparlane2‌

I have extended the support for nandbcb command in u-boot for imx6UL and imx6ULL and I have pushed the patch for review [U-Boot,1/2] i.MX6: nand: extend nandbcb command for imx6UL(L) - Patchwork

With this patch together with it's dependency (U-Boot - Patchwork ) SPL can be flashed to nand using nandbcb command and worked fine.

henrideveer · ‎07-10-2020

Hi Parthiban,

Thanks for all the effort you did for adjusting/making the nandbcb to work on the i.MX6UL.

I have a question about this: Is it possible to write a DCD / FCB / DBBT + U-Boot instead of an SPL to make a bootable board with the nandbcb tool?

Or is it really required to build an SPL with the correct DRAM init?

regards,

Henri