i.MX ProcessorsのトピックRe: kobs-ng with 4.4+ kernels on imx6 processors

kobs-ng with 4.4+ kernels on imx6 processors

psidhu — Thu, 23 Jun 2016 17:58:42 GMT

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

Re: kobs-ng with 4.4+ kernels on imx6 processors

jimmychan — Tue, 28 Jun 2016 01:38:46 GMT

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

Re: kobs-ng with 4.4+ kernels on imx6 processors

psidhu — Tue, 28 Jun 2016 16:20:42 GMT

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.

Re: kobs-ng with 4.4+ kernels on imx6 processors

jimmychan — Wed, 29 Jun 2016 01:59:40 GMT

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

Re: kobs-ng with 4.4+ kernels on imx6 processors

jimmychan — Thu, 30 Jun 2016 02:35:58 GMT

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.

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

Re: kobs-ng with 4.4+ kernels on imx6 processors

timharvey — Thu, 30 Jun 2016 21:10:14 GMT

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