kobs-ng with 4.4+ kernels on imx6 processors

[psidhu]

Hi All,

I am having a difficult time getting kobs-ng (5.4, latest version or any version before) to work with a 4.4 mainline kernel. At first, I was seeing the following:

# 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  |....@...@.......|

As you can see, there is a 10 byte padding that was added which causes no serial on boot (or boot to even occur). I then looked into the source code of kobs-ng and saw two separate modes that mtd could use to access nand.

By default, kobs-ng was using "legacy raw access mode". I forced kobs-ng to then use the "new bch layout raw access mode", which seemed to improve things, but still cause failures (can't boot). Please see below:

# 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  |..........@...@.|

00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 00  |................|

00000030  00 00 00 02 00 00 00 02  00 00 04 00 00 00 0a 00  |................|

# After kobs-ng (bad)

00000000  00 00 94 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  |..........@...@.|

00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 00  |................|

00000030  00 00 00 00 00 00 00 02  00 00 04 00 00 00 0a 00  |................|

On close inspection of the two, you can see that there are very slight byte differences, namely the third byte (92 to 94 shown). This also causes boot failures in the same way.

My question is: will kobs-ng be updated for mainline kernel support? I do not want to replace the gpmi-nand driver to the 3.14 version as I've seen other forum postings say to do as a workaround nor do I want to use a older kernel than this. Is there a patch I can apply to kobs-ng to fix this behavior? Thanks.

KevinWong​

andychen_ca​

[timharvey · Accepted solution]

I did some debugging and was able to get to the bottom of this. Here are the details if anyone else is running into this issue:

RAW nand access was added to the nand-gpmi driver in the 3.19 mainline linux kernel and a recent version of kobs-ng is needed to support that. However, I found that kobs-ng-5.4 relies on some features that the Freescale downstream vendor kernel has that are not in mainline Linux:

- MLK-12395: mtd: gpmi: add debugfs flag to indicate NAND driver use new raw access mode​

- MLK-11719-2: mtd: gpmi: save the bch layout setting in debugfs​

The first patch is how kobs-ng determines if raw nand access should be used and the 2nd is how it determines the BCH flash geometry with the ECC details. As these do not exist in mainline some patches are necessary to kobs-ng in order to it to work on mainline kernels.

I chose to use the uname() system call to determine the kernel version and check for version > 3.18 as the 3.19 kernel added raw access mode (see 003-raw-mode.patch). If the bch_geometry debugfs node does not exist, the geometry will be determined automatically. While this used to work in prior versions of kobs-ng at some point support was added for NAND chips that had different ECC on the first block vs the other blocks and I believe this created a bug in the code if the fallback was needed to calculate the geometry. I addressed this with another patch (see 004-fix-cal_nfc_geometry.patch).

The resulting kobs-ng works fine for us on a Linux 4.4 kernel. If interested you can see our OpenWrt recipe for building kobs-ng-5.4 with gcc-5.2 here.

Tim

[jimmychan]

I got the reply from the expert:

=======================

will kobs-ng be updated for mainline kernel support?

NXP does not support kernel mainline. Only our BSP versions are guarantee to work.

I do not want to replace the gpmi-nand driver to the 3.14 version as I've seen other forum postings say to do as a workaround nor do I want to use a older kernel than this. Is there a patch I can apply to kobs-ng to fix this behavior?

There are a couple of hints i think will be useful in this for the client thought.

    1) Please ask the client if he is using kobs-ng 5.4. We have had issues in the past with kobs-ng 5.1 and 5.3 where the FCB wasn't being written correctly in the flash.

    2) Looking through the kobs-ng commit messages I can see that the BCH algorithm was changed a number of times in order to support newer i.MX SoCs and a broader range of NAND parts. Thus version alignment of those three components is critical for NAND. A side effect you should be aware of is that in some instances a kernel/U-Boot update could possibly invalidate the contents of NAND from a previous kernel. An in-field update might require replacing the entire raw contents of flash rather than just rewriting individual NAND partitions from a recovery or firmware update partition. Hopefully the new algorithm introduced in 0d7fc23, "MMT-89: support reading bch geometry setting from debugfs," will prove general enough to prevent such an upgrade problem in the future. This same algorithm is used in the 4.1.15 BSPs. Stiill besides the implementation of this new algorithm it might be the case that a condition was not taken in consideration and as it happened in the past it might be required to introduce changes to the kobs-ng source code when moving past 4.1.15 which is the latest version of the kernel we officially support.

==================================

[jimmychan]

could you tell me which board and bsp are you using?

[psidhu]

Hi Jimmy Chan,

Board is a custom board, but what's important is the nand flash. This board has the MT29F2G08 (specifically, the MT29F2G08ABAEAH4 flash part) on it.

The BSP also doesn't matter since I'm talking about a mainline 4.4 kernel.

[jimmychan]

thanks for your reply. I will ask our expert team.