i.MX6DL: flashing the NAND with kobs-ng does not work in mainline kernel 4.1.0

[javiermartin]

Hello,

we have a custom platform based on an i.MX6DL which has got the following NAND flash as detected by Linux:

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc

nand: Micron MT29F4G08ABADAWP

nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64

In that platform we are trying to flash our custom SPL image so that the system can boot from NAND instead of booting from the SD card.

In order to flash the NAND we are using two different SD card images:

1. Yocto BSP Image based on kernel 3.14.38.
2. Our custom image which is based on mainline kernel 4.1.0

The procedure we use to flash the SPL image is in both cases the following:

flash_erase /dev/mtd0 0 0 2>/dev/null
kobs-ng init -x /root/SPL --search_exponent=1 -v

And the version of "kobs-ng" is the same in both SD card images:

kobs-ng version : [ 1.3 ] git hash (3587349d075b7b2d22210ab77e55ef78b9cbbd9e)

Downloaded from: http://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-kobs-5.1.tar.gz

When we flash the SPL using the SD card image 1 everything works as expected. The system can properly boot the SPL from NAND.

However, when we flash the SPL using the SD card image 2 it does not work and the data in NAND seems to be arranged differently when compared with the previous case.

I have attached the output of "nanddump -c /dev/mtd0" in both cases.

Is there something preventing "kobs-ng" from working with latest mainline kernels? Is there a new version that we can use that works with kernel 4.1.0? Using kernel 3.14.38 is not an option for us since we need the latest kernel 4.1.0 to have access to modern versions of some drivers.

Original Attachment has been moved to: nand-dump-bad.bin.zip

Original Attachment has been moved to: nand-dump-good.bin.zip

[bba]

We have modified the iMX6ul EVK with NAND flash. Than we are able to flash the u-boot bootloader with

"kobs-ng init -x -v --chip_0_device_path=/dev/mtd0 u-boot.imx"

running on original fsl kernel version linux-imx-4.1.5 and using the imx-kobs_5.4.bb receipe.

Furthermore kobs-ng is running on a modified fslc kernel version 4.4. Here we had to add the gpmi-nand support. We took the sources from linux-imx-4.1.5 - /drivers/mtd/nand/gpmi-nand.

We don't know if the fslc kernel version 4.6 supports gpmi-nand on imx6ul.

Regards,

Birger

[wimdewitte]

I added a 0.1€ 1MB SPI NOR flash for booting to avoid all this hocus-pocus.

[bba]

Hello Javier,

yes, some behavior with kernel > 3.14 prevents kobs-ng from writing the nand flash as with previous kernel versions. See following thread for details:

kobs-ng with kernel 3.19.x

Regards

[javiermartin]

Hi,

thanks for your answer.

The solution suggested in the thread you pointed out is hacking the 4.1.0 kernel sources so that it uses the gpmi-nand driver from your 3.14.28 based BSP.

This does not sound as a proper solution to us for two reasons:

• The gpmi-nand driver in kernel 4.1.0 is supposed to follow the mainline kernel standards and has been approved by the community. So replacing it with out-of-tree code does not seem sensible.
• Accommodating a kernel driver so that an application can work properly with it seems like doing things upside down. It should be the application the one that should be adapted to a particular kernel.

Is there a new version of "kobs-ng" that works with recent mainline kernels?

Is there a patch we can apply to get it working with recent mainline kernels?

Is there an alternative application we can use that works with recent mainline kernels?

Regards,

Javier.

[alejandrolozan1]

We are working on this issue and if you are checking the mtd community recent post, you can find our discussion about it.

Kernel 4.1 support is still under developing, we will change the kobs-ng to fix the issue in our release. I was wondering if you could wait for our formal release or you just want a workaround?

Best Regards,

Alejandro

[wimdewitte]

We're starting an imx6ul project and need a solution too.

Totally agree with Javier.

Please provide us - the community - a descent solution for this problem.

In the meantime, we shifted already to kernel version 4.4 (on a imx6dl product and different AM335x products) ... I'm not interested in a freescale (sorry NXP - not yet used to it) fork of the kernel for different reasons. I hope no one will give me the idiotic suggestion to use an official BSP 3.14.28.

So I hope that the fix is kernel version independent.

Can you publish your patch as soon as possible - can you indicate a publication date?

Is it possible to have access to a development git of kobs-ng?

Is this new version also compatible with SPL and non-SPL u-boot?

This problem is already hanging for 9 months; it's a shame NXP  is not helping their customers!

Regards,

Wim

[alejandrolozan1]

Hi,

wimdewitte​, helio​, Could you contact your local FAE?

He will help you for sure!.

Best Regards,

Alejandro

[wimdewitte · Accepted solution]

Many thanks to our FAE Rodrigue Simonneau.

Upcoming kobs-ng is compatible with 4.1 ... don't see changes regarding dependent drivers in newer kernels (4.4 - 4.5)

[psidhu]

Hello,

We are also using a 4.4 kernel with the latest kob-ng version (kobs-ng version : [ 1.3 ] git hash (d66a0b1891e75fde0efb366d8cd08a3a4e2beb25 [imx-kobs-5.4.tar.gz]), but I'm running into an issue where the FCB is written with a 20 byte offset.

Please see the below nanddumps:

# Before kobs-ng (good)

00000000  00 00 92 fb ff ff 46 43  42 20 00 00 00 01 50 3c  |......FCB ....P<|

00000010  19 06 00 00 00 00 00 08  00 00 40 08 00 00 40 00  |..........@...@.|

# After kobs-ng (bad)

00000000  00 00 00 00 00 00 00 00  00 00 00 00 92 fb ff ff  |................|

00000010  46 43 42 20 00 00 00 01  50 3c 19 06 00 00 00 00  |FCB ....P<......|

00000020  00 08 00 00 40 08 00 00  40 00 00 00 00 00 00 00  |....@...@.......|

Were you able to get kobs-ng working with a 4.4 kernel?