Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Raphael Pereira]

Hi,

I would like to know if it is possible to use the Software BCH ECC
implementation to support a GF14 (ECC size == 1024) 40 bit ECC strengh
flash (MT29F32G08CBADA) on a GF13 (ECC size == 512) 20 bit ECC strengh
only i.MX23 processor.

I know this processor uses gpmi-nand driver and it seems this driver
doesn't support software ECC implementation. What I want to know is if
it is possible to change the driver to use the current Software BCH
ECC implementation available on Linux when it detects the
configuration above which is not hardware supported and switch it to a
software implementation. Considering most flashes has a 1-bit ECC on
block 0 that would allow me to boot then switch to software ECC after
kernel load.

Best Regards,
-- 
Raphael Derosso Pereira

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Miquel Raynal]

Hi Raphael,

Raphael Pereira <raphaelpereira@gmail.com> wrote on Wed, 1 Aug 2018
18:29:32 -0300:

> Hi,
> 
> I would like to know if it is possible to use the Software BCH ECC
> implementation to support a GF14 (ECC size == 1024) 40 bit ECC strengh
> flash (MT29F32G08CBADA) on a GF13 (ECC size == 512) 20 bit ECC strengh
> only i.MX23 processor.

I am not sure to understand correctly your request. What do you mean
by "GF13 only i.MX23 processor"? I suppose you refer to the raw NAND
controller abilities? If yes, then why do you care if you use soft
BCH?

And the ECC requirements is just an indication in terms of
correctability, how is 40 bits per 1024 bytes different than 20 bits
per 512?

> 
> I know this processor uses gpmi-nand driver and it seems this driver
> doesn't support software ECC implementation.

Maybe I'm missing something but as the driver supports raw
reads/writes, I don't see why it would not support soft ECC. Boris,
Richard, any thoughts about that?

> What I want to know is if
> it is possible to change the driver to use the current Software BCH
> ECC implementation available on Linux when it detects the
> configuration above which is not hardware supported and switch it to a
> software implementation.

You can use DT properties for that (nand-ecc-mode = "soft";). Otherwise
if the driver effectively does not support the proposed layout at all,
it should just fail to probe.

> Considering most flashes has a 1-bit ECC on
> block 0 that would allow me to boot then switch to software ECC after
> kernel load.
> 
> Best Regards,

Thanks,
Miquèl

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Raphael Pereira]

Hi Miquèl,

First thanks for the response. Second, I apologize for the ignorance
on the matter, I should have studied a little more before asking for
help. I am not fully aware on how these works but I will try to
express myself better. I might still say incorrect things (:

I have a custom board with a i.MX23 processor. My board uses a 4Gb
(512Mx8) flash which has an ECC requirement that is supported by the
hardware and by the gpmi-nand driver. The gpmi-nand driver reports it
as stated below:

nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224

In a more recent production we chose a 64Gb (4Gx8) flash and it is reported as:

nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 744
gpmi-nand 8000c000.gpmi-nand: ecc strength: 52 cannot be supported by
the controller (20)
gpmi-nand 8000c000.gpmi-nand: failed gpmi_check_ecc. ecc bits: 40, ecc
size: 1024
gpmi-nand 8000c000.gpmi-nand: Error setting BCH geometry : 1

And it fails to probe. I looked at the code and found the following:

gpmi-nand.c

/*
 * If we can get the ECC information from the nand chip, we do not
 * need to calculate them ourselves.
 *
 * We may have available oob space in this case.
 */
static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
{
        struct bch_geometry *geo = &this->bch_geometry;
        struct nand_chip *chip = &this->nand;
        struct mtd_info *mtd = nand_to_mtd(chip);
        unsigned int block_mark_bit_offset;

        if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
                return -EINVAL;

        switch (chip->ecc_step_ds) {
        case SZ_512:
                geo->gf_len = 13;
                break;
        case SZ_1K:
                geo->gf_len = 14;
                break;
        default:
                dev_err(this->dev,
                        "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
                        chip->ecc_strength_ds, chip->ecc_step_ds);
                return -EINVAL;
        }
        geo->ecc_chunk_size = chip->ecc_step_ds;
        geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
        if (!gpmi_check_ecc(this))
                return -EINVAL;
...

and a little bit before that:

static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
{
        struct bch_geometry *geo = &this->bch_geometry;

        /* Do the sanity check. */
        if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
                /* The mx23/mx28 only support the GF13. */
                if (geo->gf_len == 14)
                        return false;
        }
        return geo->ecc_strength <= this->devdata->bch_max_ecc_strength;
}

That is where it is falling.

My questions are:

1. Is there any possibility to use a lower ECC strength on this flash
that is supported by the hardware (at the expense of getting a lower
device lifetime as I understand)?
2. If positive, what changes (and literature) do you recommend me to implement?
3. If positive, will I be able to boot using this flash (will ROM boot
code be able to load data from this part)?
4. If negative, can I implement support for the software BCH stack in
this driver? And will I be able to boot using this approach?
5. In both cases, do I need to change kobs-ng in order to implement
the same approach?

Again, sorry if I say nonsense, I am still getting the knowledge!

Thanks in advance!

Em sáb, 4 de ago de 2018 às 06:55, Miquel Raynal
<miquel.raynal@bootlin.com> escreveu:
>
> Hi Raphael,
>
> Raphael Pereira <raphaelpereira@gmail.com> wrote on Wed, 1 Aug 2018
> 18:29:32 -0300:
>
> > Hi,
> >
> > I would like to know if it is possible to use the Software BCH ECC
> > implementation to support a GF14 (ECC size == 1024) 40 bit ECC strengh
> > flash (MT29F32G08CBADA) on a GF13 (ECC size == 512) 20 bit ECC strengh
> > only i.MX23 processor.
>
> I am not sure to understand correctly your request. What do you mean
> by "GF13 only i.MX23 processor"? I suppose you refer to the raw NAND
> controller abilities? If yes, then why do you care if you use soft
> BCH?
>
> And the ECC requirements is just an indication in terms of
> correctability, how is 40 bits per 1024 bytes different than 20 bits
> per 512?
>
> >
> > I know this processor uses gpmi-nand driver and it seems this driver
> > doesn't support software ECC implementation.
>
> Maybe I'm missing something but as the driver supports raw
> reads/writes, I don't see why it would not support soft ECC. Boris,
> Richard, any thoughts about that?
>
> > What I want to know is if
> > it is possible to change the driver to use the current Software BCH
> > ECC implementation available on Linux when it detects the
> > configuration above which is not hardware supported and switch it to a
> > software implementation.
>
> You can use DT properties for that (nand-ecc-mode = "soft";). Otherwise
> if the driver effectively does not support the proposed layout at all,
> it should just fail to probe.
>
> > Considering most flashes has a 1-bit ECC on
> > block 0 that would allow me to boot then switch to software ECC after
> > kernel load.
> >
> > Best Regards,
>
> Thanks,
> Miquèl



-- 
Raphael Derosso Pereira

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Miquel Raynal]

Hi Raphael,

Raphael Pereira <raphaelpereira@gmail.com> wrote on Sat, 4 Aug 2018
08:22:24 -0300:

> Hi Miquèl,
> 
> First thanks for the response. Second, I apologize for the ignorance
> on the matter, I should have studied a little more before asking for
> help. I am not fully aware on how these works but I will try to
> express myself better. I might still say incorrect things (:

No problem!

> 
> I have a custom board with a i.MX23 processor. My board uses a 4Gb
> (512Mx8) flash which has an ECC requirement that is supported by the
> hardware and by the gpmi-nand driver. The gpmi-nand driver reports it
> as stated below:
> 
> nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224

Ok.

> 
> In a more recent production we chose a 64Gb (4Gx8) flash and it is reported as:
> 
> nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 744

                  ^

You have to know that Linux does not support MLC. While the controller
driver should work, there is no support *at all* with UBI/UBIFS.

> gpmi-nand 8000c000.gpmi-nand: ecc strength: 52 cannot be supported by
> the controller (20)
> gpmi-nand 8000c000.gpmi-nand: failed gpmi_check_ecc. ecc bits: 40, ecc
> size: 1024
> gpmi-nand 8000c000.gpmi-nand: Error setting BCH geometry : 1
> 
> And it fails to probe. I looked at the code and found the following:
> 
> gpmi-nand.c
> 
> /*
>  * If we can get the ECC information from the nand chip, we do not
>  * need to calculate them ourselves.
>  *
>  * We may have available oob space in this case.
>  */
> static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
> {
>         struct bch_geometry *geo = &this->bch_geometry;
>         struct nand_chip *chip = &this->nand;
>         struct mtd_info *mtd = nand_to_mtd(chip);
>         unsigned int block_mark_bit_offset;
> 
>         if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
>                 return -EINVAL;
> 
>         switch (chip->ecc_step_ds) {
>         case SZ_512:
>                 geo->gf_len = 13;
>                 break;
>         case SZ_1K:
>                 geo->gf_len = 14;
>                 break;
>         default:
>                 dev_err(this->dev,
>                         "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
>                         chip->ecc_strength_ds, chip->ecc_step_ds);
>                 return -EINVAL;
>         }
>         geo->ecc_chunk_size = chip->ecc_step_ds;
>         geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
>         if (!gpmi_check_ecc(this))
>                 return -EINVAL;
> ...
> 
> and a little bit before that:
> 
> static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
> {
>         struct bch_geometry *geo = &this->bch_geometry;
> 
>         /* Do the sanity check. */
>         if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
>                 /* The mx23/mx28 only support the GF13. */
>                 if (geo->gf_len == 14)
>                         return false;
>         }
>         return geo->ecc_strength <= this->devdata->bch_max_ecc_strength;
> }
> 
> That is where it is falling.
> 
> My questions are:
> 
> 1. Is there any possibility to use a lower ECC strength on this flash
> that is supported by the hardware (at the expense of getting a lower
> device lifetime as I understand)?

For SLC, yes. For MLC, I'm not sure it is wise to do it as the number
of expected bitlips is much more higher.

Does your NAND chip supports SLC mode?
 
> 2. If positive, what changes (and literature) do you recommend me to implement?
> 3. If positive, will I be able to boot using this flash (will ROM boot
> code be able to load data from this part)?

Only if your Boot ROM supports it, which is very likely not to be the
case with an iMX23.

> 4. If negative, can I implement support for the software BCH stack in
> this driver? And will I be able to boot using this approach?

If your Boot ROM does not support this kind of flash, then no, you
won't boot from it. However if you manage to boot, Linux can interact
with the chip with soft ECC if you can setup the chip to use SLC
mode (half of the capacity). 

> 5. In both cases, do I need to change kobs-ng in order to implement
> the same approach?

I didn't know about kobs-ng. We usually use the mtd-utils userspace
package for NAND testing.

Thanks,
Miquèl

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Raphael Pereira]

Hi Miquèl,

This old thread mentions the exact same part I am trying to use and it
seems to work on i.MX6 SOLO, which supports 40bit ECC strengh, so I
think the MLC issue is not the case, although I could not find the
solution used as it seems it is not explicit in the thread:

http://lists.infradead.org/pipermail/linux-mtd/2015-April/058901.html

Em sáb, 4 de ago de 2018 às 14:33, Miquel Raynal
<miquel.raynal@bootlin.com> escreveu:
>
> Hi Raphael,
>
> Raphael Pereira <raphaelpereira@gmail.com> wrote on Sat, 4 Aug 2018
> 08:22:24 -0300:
>
> > Hi Miquèl,
> >
> > First thanks for the response. Second, I apologize for the ignorance
> > on the matter, I should have studied a little more before asking for
> > help. I am not fully aware on how these works but I will try to
> > express myself better. I might still say incorrect things (:
>
> No problem!
>
> >
> > I have a custom board with a i.MX23 processor. My board uses a 4Gb
> > (512Mx8) flash which has an ECC requirement that is supported by the
> > hardware and by the gpmi-nand driver. The gpmi-nand driver reports it
> > as stated below:
> >
> > nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
>
> Ok.
>
> >
> > In a more recent production we chose a 64Gb (4Gx8) flash and it is reported as:
> >
> > nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 744
>
>                   ^
>
> You have to know that Linux does not support MLC. While the controller
> driver should work, there is no support *at all* with UBI/UBIFS.
>
> > gpmi-nand 8000c000.gpmi-nand: ecc strength: 52 cannot be supported by
> > the controller (20)
> > gpmi-nand 8000c000.gpmi-nand: failed gpmi_check_ecc. ecc bits: 40, ecc
> > size: 1024
> > gpmi-nand 8000c000.gpmi-nand: Error setting BCH geometry : 1
> >
> > And it fails to probe. I looked at the code and found the following:
> >
> > gpmi-nand.c
> >
> > /*
> >  * If we can get the ECC information from the nand chip, we do not
> >  * need to calculate them ourselves.
> >  *
> >  * We may have available oob space in this case.
> >  */
> > static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
> > {
> >         struct bch_geometry *geo = &this->bch_geometry;
> >         struct nand_chip *chip = &this->nand;
> >         struct mtd_info *mtd = nand_to_mtd(chip);
> >         unsigned int block_mark_bit_offset;
> >
> >         if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
> >                 return -EINVAL;
> >
> >         switch (chip->ecc_step_ds) {
> >         case SZ_512:
> >                 geo->gf_len = 13;
> >                 break;
> >         case SZ_1K:
> >                 geo->gf_len = 14;
> >                 break;
> >         default:
> >                 dev_err(this->dev,
> >                         "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
> >                         chip->ecc_strength_ds, chip->ecc_step_ds);
> >                 return -EINVAL;
> >         }
> >         geo->ecc_chunk_size = chip->ecc_step_ds;
> >         geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
> >         if (!gpmi_check_ecc(this))
> >                 return -EINVAL;
> > ...
> >
> > and a little bit before that:
> >
> > static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
> > {
> >         struct bch_geometry *geo = &this->bch_geometry;
> >
> >         /* Do the sanity check. */
> >         if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
> >                 /* The mx23/mx28 only support the GF13. */
> >                 if (geo->gf_len == 14)
> >                         return false;
> >         }
> >         return geo->ecc_strength <= this->devdata->bch_max_ecc_strength;
> > }
> >
> > That is where it is falling.
> >
> > My questions are:
> >
> > 1. Is there any possibility to use a lower ECC strength on this flash
> > that is supported by the hardware (at the expense of getting a lower
> > device lifetime as I understand)?
>
> For SLC, yes. For MLC, I'm not sure it is wise to do it as the number
> of expected bitlips is much more higher.
>
> Does your NAND chip supports SLC mode?
>
> > 2. If positive, what changes (and literature) do you recommend me to implement?
> > 3. If positive, will I be able to boot using this flash (will ROM boot
> > code be able to load data from this part)?
>
> Only if your Boot ROM supports it, which is very likely not to be the
> case with an iMX23.
>
> > 4. If negative, can I implement support for the software BCH stack in
> > this driver? And will I be able to boot using this approach?
>
> If your Boot ROM does not support this kind of flash, then no, you
> won't boot from it. However if you manage to boot, Linux can interact
> with the chip with soft ECC if you can setup the chip to use SLC
> mode (half of the capacity).
>
> > 5. In both cases, do I need to change kobs-ng in order to implement
> > the same approach?
>
> I didn't know about kobs-ng. We usually use the mtd-utils userspace
> package for NAND testing.
>
> Thanks,
> Miquèl



-- 
Raphael Derosso Pereira

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Boris Brezillon]

Hi Raphael,

On Sat, 4 Aug 2018 21:39:13 -0300
Raphael Pereira <raphaelpereira@gmail.com> wrote:

> Hi Miquèl,
> 
> This old thread mentions the exact same part I am trying to use and it
> seems to work on i.MX6 SOLO, which supports 40bit ECC strengh, so I
> think the MLC issue is not the case, although I could not find the
> solution used as it seems it is not explicit in the thread:
> 
> http://lists.infradead.org/pipermail/linux-mtd/2015-April/058901.html

Trust me, getting the proper ECC config in place is just a tiny part of
the problem. I'm not saying supporting MLC NANDs is impossible, but it
requires spending a non-negligible amount of time to make it work
reliably (see [1] and [2] if you need more details).

Regards,

Boris

[1]https://events.static.linuxfound.org/sites/events/files/slides/brezillon-mlc-nand_0.pdf
[2]https://elinux.org/images/5/54/Weinberger.pdf

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Boris Brezillon]

Hi Raphael,

On Sat, 4 Aug 2018 08:22:24 -0300
Raphael Pereira <raphaelpereira@gmail.com> wrote:

> Hi Miquèl,
> 
> First thanks for the response. Second, I apologize for the ignorance
> on the matter, I should have studied a little more before asking for
> help. I am not fully aware on how these works but I will try to
> express myself better. I might still say incorrect things (:
> 
> I have a custom board with a i.MX23 processor. My board uses a 4Gb
> (512Mx8) flash which has an ECC requirement that is supported by the
> hardware and by the gpmi-nand driver. The gpmi-nand driver reports it
> as stated below:
> 
> nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
> 
> In a more recent production we chose a 64Gb (4Gx8) flash and it is reported as:
> 
> nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 744
> gpmi-nand 8000c000.gpmi-nand: ecc strength: 52 cannot be supported by
> the controller (20)

Don't know where the 52bits/1024bytes ECC requirement is extracted
from, but assuming you're using BCH it would not even fit in the
provided OOB area (would require 784 bytes + 2 bytes for the the BBM
marker). So I guess there's something wrong in the ID/ONFI param page
decoding.

> gpmi-nand 8000c000.gpmi-nand: failed gpmi_check_ecc. ecc bits: 40, ecc
> size: 1024
> gpmi-nand 8000c000.gpmi-nand: Error setting BCH geometry : 1
> 
> And it fails to probe. I looked at the code and found the following:
> 
> gpmi-nand.c
> 
> /*
>  * If we can get the ECC information from the nand chip, we do not
>  * need to calculate them ourselves.
>  *
>  * We may have available oob space in this case.
>  */
> static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
> {
>         struct bch_geometry *geo = &this->bch_geometry;
>         struct nand_chip *chip = &this->nand;
>         struct mtd_info *mtd = nand_to_mtd(chip);
>         unsigned int block_mark_bit_offset;
> 
>         if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
>                 return -EINVAL;
> 
>         switch (chip->ecc_step_ds) {
>         case SZ_512:
>                 geo->gf_len = 13;
>                 break;
>         case SZ_1K:
>                 geo->gf_len = 14;
>                 break;
>         default:
>                 dev_err(this->dev,
>                         "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
>                         chip->ecc_strength_ds, chip->ecc_step_ds);
>                 return -EINVAL;
>         }
>         geo->ecc_chunk_size = chip->ecc_step_ds;
>         geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
>         if (!gpmi_check_ecc(this))
>                 return -EINVAL;
> ...
> 
> and a little bit before that:
> 
> static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
> {
>         struct bch_geometry *geo = &this->bch_geometry;
> 
>         /* Do the sanity check. */
>         if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
>                 /* The mx23/mx28 only support the GF13. */
>                 if (geo->gf_len == 14)
>                         return false;
>         }
>         return geo->ecc_strength <= this->devdata->bch_max_ecc_strength;
> }
> 
> That is where it is falling.
> 
> My questions are:
> 
> 1. Is there any possibility to use a lower ECC strength on this flash
> that is supported by the hardware (at the expense of getting a lower
> device lifetime as I understand)?

We're talking about MLC NANDs, don't even think about doing that. The
ECC requirements is the least you should do, and I'd even recommend
choosing stronger ECC if you have space left in the OOB area.

> 2. If positive, what changes (and literature) do you recommend me to implement?
> 3. If positive, will I be able to boot using this flash (will ROM boot
> code be able to load data from this part)?
> 4. If negative, can I implement support for the software BCH stack in
> this driver? And will I be able to boot using this approach?

I think you'll regret that. The CPU consumption is already quite high
for weaker ECC configs (4bit/512bytes), and we're talking about
52bits/1024bytes here?!

> 5. In both cases, do I need to change kobs-ng in order to implement
> the same approach?

kobs-ng is the least of your problems. Before even considering all of
this you should be aware that MLC NAND is not reliably supported in
Linux. So, unless you're willing to fix that, I'd recommend
reconsidering you HW choices and choosing an SLC NAND.

If you don't have a choice, you might want to have a look at this
ubi-mlc branch [1] and finish the work Richard and I started 3 years
ago.

Regards,

Boris

[1]https://github.com/bbrezillon/linux/commits/nand/mlc

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Boris Brezillon]

On Sat, 4 Aug 2018 11:55:55 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hi Raphael,
> 
> Raphael Pereira <raphaelpereira@gmail.com> wrote on Wed, 1 Aug 2018
> 18:29:32 -0300:
> 
> > Hi,
> > 
> > I would like to know if it is possible to use the Software BCH ECC
> > implementation to support a GF14 (ECC size == 1024) 40 bit ECC strengh
> > flash (MT29F32G08CBADA) on a GF13 (ECC size == 512) 20 bit ECC strengh
> > only i.MX23 processor.  
> 
> I am not sure to understand correctly your request. What do you mean
> by "GF13 only i.MX23 processor"? I suppose you refer to the raw NAND
> controller abilities? If yes, then why do you care if you use soft
> BCH?
> 
> And the ECC requirements is just an indication in terms of
> correctability, how is 40 bits per 1024 bytes different than 20 bits
> per 512?


Well, it is different. In 40b/1024B mode you can fix 40 bits no matter
where they are in the the 1k block (even if they all appear to be in
the first 512 bytes). In 20b/512B mode, you can only fix 20 bits on a
512B portion. So 20b/512B is weaker than 40b/1KB.

Re: Suport for gf_len 14 in gpmi-nand for i.MX23 using Software BCH ECC

[Raphael Pereira]

Hi Boris,

Thanks for the enlightenment! It seems I made a very bad choice. I
will probably switch the part as it seems all the effort (that I
understand is quite large) can take me to a dead end (no possible
boot).

Best Regards,
Em dom, 5 de ago de 2018 às 06:13, Boris Brezillon
<boris.brezillon@bootlin.com> escreveu:
>
> Hi Raphael,
>
> On Sat, 4 Aug 2018 08:22:24 -0300
> Raphael Pereira <raphaelpereira@gmail.com> wrote:
>
> > Hi Miquèl,
> >
> > First thanks for the response. Second, I apologize for the ignorance
> > on the matter, I should have studied a little more before asking for
> > help. I am not fully aware on how these works but I will try to
> > express myself better. I might still say incorrect things (:
> >
> > I have a custom board with a i.MX23 processor. My board uses a 4Gb
> > (512Mx8) flash which has an ECC requirement that is supported by the
> > hardware and by the gpmi-nand driver. The gpmi-nand driver reports it
> > as stated below:
> >
> > nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 224
> >
> > In a more recent production we chose a 64Gb (4Gx8) flash and it is reported as:
> >
> > nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 744
> > gpmi-nand 8000c000.gpmi-nand: ecc strength: 52 cannot be supported by
> > the controller (20)
>
> Don't know where the 52bits/1024bytes ECC requirement is extracted
> from, but assuming you're using BCH it would not even fit in the
> provided OOB area (would require 784 bytes + 2 bytes for the the BBM
> marker). So I guess there's something wrong in the ID/ONFI param page
> decoding.
>
> > gpmi-nand 8000c000.gpmi-nand: failed gpmi_check_ecc. ecc bits: 40, ecc
> > size: 1024
> > gpmi-nand 8000c000.gpmi-nand: Error setting BCH geometry : 1
> >
> > And it fails to probe. I looked at the code and found the following:
> >
> > gpmi-nand.c
> >
> > /*
> >  * If we can get the ECC information from the nand chip, we do not
> >  * need to calculate them ourselves.
> >  *
> >  * We may have available oob space in this case.
> >  */
> > static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
> > {
> >         struct bch_geometry *geo = &this->bch_geometry;
> >         struct nand_chip *chip = &this->nand;
> >         struct mtd_info *mtd = nand_to_mtd(chip);
> >         unsigned int block_mark_bit_offset;
> >
> >         if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
> >                 return -EINVAL;
> >
> >         switch (chip->ecc_step_ds) {
> >         case SZ_512:
> >                 geo->gf_len = 13;
> >                 break;
> >         case SZ_1K:
> >                 geo->gf_len = 14;
> >                 break;
> >         default:
> >                 dev_err(this->dev,
> >                         "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
> >                         chip->ecc_strength_ds, chip->ecc_step_ds);
> >                 return -EINVAL;
> >         }
> >         geo->ecc_chunk_size = chip->ecc_step_ds;
> >         geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
> >         if (!gpmi_check_ecc(this))
> >                 return -EINVAL;
> > ...
> >
> > and a little bit before that:
> >
> > static inline bool gpmi_check_ecc(struct gpmi_nand_data *this)
> > {
> >         struct bch_geometry *geo = &this->bch_geometry;
> >
> >         /* Do the sanity check. */
> >         if (GPMI_IS_MX23(this) || GPMI_IS_MX28(this)) {
> >                 /* The mx23/mx28 only support the GF13. */
> >                 if (geo->gf_len == 14)
> >                         return false;
> >         }
> >         return geo->ecc_strength <= this->devdata->bch_max_ecc_strength;
> > }
> >
> > That is where it is falling.
> >
> > My questions are:
> >
> > 1. Is there any possibility to use a lower ECC strength on this flash
> > that is supported by the hardware (at the expense of getting a lower
> > device lifetime as I understand)?
>
> We're talking about MLC NANDs, don't even think about doing that. The
> ECC requirements is the least you should do, and I'd even recommend
> choosing stronger ECC if you have space left in the OOB area.
>
> > 2. If positive, what changes (and literature) do you recommend me to implement?
> > 3. If positive, will I be able to boot using this flash (will ROM boot
> > code be able to load data from this part)?
> > 4. If negative, can I implement support for the software BCH stack in
> > this driver? And will I be able to boot using this approach?
>
> I think you'll regret that. The CPU consumption is already quite high
> for weaker ECC configs (4bit/512bytes), and we're talking about
> 52bits/1024bytes here?!
>
> > 5. In both cases, do I need to change kobs-ng in order to implement
> > the same approach?
>
> kobs-ng is the least of your problems. Before even considering all of
> this you should be aware that MLC NAND is not reliably supported in
> Linux. So, unless you're willing to fix that, I'd recommend
> reconsidering you HW choices and choosing an SLC NAND.
>
> If you don't have a choice, you might want to have a look at this
> ubi-mlc branch [1] and finish the work Richard and I started 3 years
> ago.
>
> Regards,
>
> Boris
>
> [1]https://github.com/bbrezillon/linux/commits/nand/mlc



-- 
Raphael Derosso Pereira