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

[Boris Brezillon <boris.brezillon@bootlin.com>]

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