[EXT] [PATCH] mtd: mxs_nand: default to legacy bch and rename to modern bch option

[Tim Harvey]

On Mon, Mar 21, 2022 at 1:34 AM Frieder Schrempf
<frieder.schrempf at kontron.de> wrote:
>
> Hi Ye,
>
> Am 17.03.22 um 14:54 schrieb Frieder Schrempf:
> > Hi Han,
> >
> > Am 17.03.22 um 14:33 schrieb Han Xu:
> >>
> >>
> >> On Thu, Mar 17, 2022 at 8:27 AM Frieder Schrempf
> >> <frieder.schrempf at kontron.de <mailto:frieder.schrempf at kontron.de>> wrote:
> >>
> >>     Hi Stefano,
> >>
> >>     this old patch was delegated to you in patchwork. If you're not the
> >>     correct maintainer to address, please let me know. As the NAND layer
> >>     seems to be unmaintained at the moment, I'm not sure whom to ask.
> >>
> >>     This patch fixes a regression that was introduced by 616f03dabacb ("
> >>     mtd: gpmi: change the BCH layout setting for large oob NAND") which
> >>     alters the BCH layout in a way that doesn't match with the
> >>     implementation in the Linux kernel.
> >>
> >>     This causes failures when loading an UBI image in U-Boot that was
> >>     flashed by Linux or vice versa (see [1]).
> >>
> >>     There has been an approach to fix this through an optional devicetree
> >>     property in 51cdf83eea ("mtd: gpmi: provide the option to use legacy bch
> >>     geometry"), but this is not acceptable. The "legacy" BCH layout
> >>     compatible with Linux should be used by default.
> >>
> >>     The approach to upstream the "new" layout to the kernel [2] seems to be
> >>     stalled and even if it would succeed, it would break systems that use an
> >>     old U-Boot and a new kernel, which is again not really acceptable in my
> >>     opinion.
> >>
> >>
> >> Hi Frieder,
> >>
> >> I am not in office this week. I will send another patch set to change in
> >> both kernel and u-boot to fix the compatible issue.
> >
> > You already claimed that months ago, but nothing happened:
> >
> >> I will send patches for both kernel and u-boot to use legacy bch
> >> scheme by default, and add some code to treat few MLC nand chips as
> >> corner cases.
> >
> > Sean's U-Boot patch is effectively reverting the default behavior to use
> > the "legacy" BCH scheme. So that's in line with what you want to do and
> > you can base your work on top of this fix. But we should get the basic
> > fix in regardless.
> >
> > Even more so because switching the layout in U-Boot by using
> > fsl,legacy-bch-geometry in the devicetree requires CONFIG_DM_MTD=y,
> > which causes the bootloader size to increase by around 250 KiB in my
> > case which might not be an option for some boards.
>
> Ye's reply copied over to not break the thread:
>
> > The dt nand driver will check "fsl,legacy-bch-geometry" property to
> > use legacy bch. If this can't work for you in case you don't use DM
> > driver, I prefer adding a config to select the legacy bch not
> > reverting the patch.
>
> I think you miss my point. I don't really care about your preferences.
> But I do care about not introducing breaking changes. IMHO the "correct"
> way to introduce the new BCH layout would have been:
>
> 1. Introduce the new layout in Linux and U-Boot behind a feature-flag
> (e.g. DT property)
> 2. Make all upstream board configurations and DTs in Linux and U-Boot
> use the feature-flag.
> 3. Drop the flag and make the new BCH layout the default.
>
> That way the change would be much more controlled and raise the
> awareness of board maintainers that are affected.
>
> The current situation (layout changes applied in U-Boot without any
> questioning, layout changes in Linux rejected for good reasons) leaves
> everyone who uses the GPMI NAND on i.MX in a situation where they
> probably will see failures and need to spend some hours of debugging
> until they find out the reason is that someone carelessly introduced
> breaking changes.
>
> And even with the procedure described above we break compatibility
> between old and new versions of U-Boot and Linux and create a dependency
> between the two which is what we should try to avoid wherever possible.
>
> Frieder

Frieder,

I agree that we need to get this fixed ASAP. Because of this IMX GPMI
NAND UBI has been broken since v2020.07 (6 releases ago!) and it would
be really nice to get this fixed in v2022.01 which releases in a
couple of weeks. I'm surprised neither of us noticed this problem but
likely we've both been so busy trying to keep up with forced DM
migrations we haven't fully tested the 'little things' like booting to
an actual OS. I know the boards I support using IMX GPMI NAND UBI are
still using a 2017 U-Boot where quite honestly everything worked fine
so there hasn't been a reason to push people to something new.

That said, applying this patch does 'not' fix things for my boards.
For my boards mxs_nand_set_geometry is called with:
oobsize=224 ecc_str_ds=0 ecc_step_ds=0 modern=0

and I still get ecc errors when mounting a UBI that worked fine with a
v2020.04 U-Boot:
Ventana > ubi part rootfs && ubifsmount ubi0:boot && ubifsls && ubifsumount
ubi0: attaching mtd3
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
from PEB 0:0, read 64 bytes
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
from PEB 1:0, read 64 bytes
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
from PEB 2:0, read 64 bytes
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 4096
bytes from PEB 2:4096, read 4096 bytes
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes
from PEB 3:0, read 64 bytes
ubi0 error: ubi_io_read: error -74 (ECC error) while reading 4096
bytes from PEB 3:4096, read 4096 bytes

The original offending commit 616f03dabacb ("mtd: gpmi: change the BCH
layout setting for large oob NAND") no longer reverts and I haven't
dug in to find out what I can do about that but i'm a little concerned
I get different results than you do regarding the patch from this
thread.

Thank you for pursuing this issue!

Best Regards,

Tim



Best Regards,