[PATCH] mtd: rawnand: nand_base: Handle algorithm selection
Linus Walleij
linus.walleij at linaro.org
Thu Jan 26 09:59:41 CET 2023
Hi William,
so this is the patch that actually solved my bug in the end :)
On Thu, Jan 26, 2023 at 2:14 AM William Zhang
<william.zhang at broadcom.com> wrote:
> On 01/21/2023 03:43 PM, Linus Walleij wrote:
> > For BRCMNAND with 1-bit BCH ECC (BCH-1) such as used on the
> > D-Link DIR-885L and DIR-890L routers, we need to explicitly
> > select the ECC like this in the device tree:
> >
> > nand-ecc-algo = "bch";
> > nand-ecc-strength = <1>;
> > nand-ecc-step-size = <512>;
> >
> > This is handled by the Linux kernel but U-Boot core does
> > not respect this. Fix it up by parsing the algorithm and
> > preserve the behaviour using this property to select
> > software BCH as far as possible.
>
> For 1 bit HW ECC, the BRCMNAND driver only uses HAMMING ECC. The
> brcmnand_setup_dev function should take care of it with just these two
> properties in the device tress without any code changes:
> nand-ecc-strength = <1>;
> nand-ecc-step-size = <512>;
> unless these D-Link device has always been using software BCH-1 and
> wants to continue to use software BCH-1.
>
> BTW, I didn't see this change from master branch of linux nand base
> driver. The "nand-ecc-algo" is only used by the ecc engine code(ecc.c)
> but this code is not in the u-boot obviously. Were you porting this from
> a different version of linux nand driver?
Rafał has provided the answer already: the D-Link DIR-885L and DIR-890L
did choose to use BCH-1 ECC. The brcmnand controller does support it
in hardware too, if configured correctly.
The way the device tree properties work is that:
nand-ecc-strength = <1>;
nand-ecc-step-size = <512>;
will indeed result in 1-bit Hamming just like you say while:
nand-ecc-algo = "bch";
nand-ecc-strength = <1>;
nand-ecc-step-size = <512>;
will explicitly hammer it down to BCH-1. Currently the D-Link devices
are the two only devices I know that does this in the entire world, but
one of them happens to be on my desktop and I think Rafal has the
other one so we need this.
It does not use software ECC, this is just a (maybe non-standard)
way of using the hw ECC in the brcmnand controller.
In brcmnand.c we reach this:
if (chip->ecc.algo == NAND_ECC_UNKNOWN) {
if (chip->ecc.strength == 1 && chip->ecc.size == 512)
/* Default to Hamming for 1-bit ECC, if unspecified */
chip->ecc.algo = NAND_ECC_HAMMING;
else
/* Otherwise, BCH */
chip->ecc.algo = NAND_ECC_BCH;
}
if (chip->ecc.algo == NAND_ECC_HAMMING && (chip->ecc.strength != 1 ||
chip->ecc.size != 512)) {
dev_err(ctrl->dev, "invalid Hamming params: %d bits
per %d bytes\n",
chip->ecc.strength, chip->ecc.size);
return -EINVAL;
}
Since we now have ecc.algo == NAND_ECC_BCH none of these branches
will be taken and we will not default to hamming.
Next:
switch (chip->ecc.size) {
case 512:
if (chip->ecc.algo == NAND_ECC_HAMMING)
cfg->ecc_level = 15;
else
cfg->ecc_level = chip->ecc.strength;
cfg->sector_size_1k = 0;
break;
Here cfg->ecc_level will be set to 1 since algo is NAND_ECC_BCH.
And this is what these D-Link devices are using.
I understand that from a Broadcom perspective this may look like
a bit of abusive and unintended way of using the hardware, but
D-Link use it and have burnt this specific usecase into the ROM of
a few million routers so...
Yours,
Linus Walleij
More information about the U-Boot
mailing list