subpage reads/writes with fsl_elbc_nand driver

subpage reads/writes with fsl_elbc_nand driver

[Rasmus Villemoes]

I'm in the process of upgrading a board from an old 3.14-based kernel
with quite a few out-of-tree patches to one based on 4.19, hopefully
with much fewer such patches.

In order to even get the new kernel to mount the existing root
filesystem, I've had to apply the hacks below:

--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -6657,6 +6657,11 @@ static int nand_scan_tail(struct mtd_info *mtd)
                pr_warn("WARNING: %s: the ECC used on your system is too
weak compared to the one required by the NAND chip\n",
                        mtd->name);

+       if (IS_ENABLED(CONFIG_ML300PCM31)) {
+               pr_warn("setting NAND_NO_SUBPAGE_WRITE bit\n");
+               chip->ecc.write_subpage = NULL;
+               chip->options |= NAND_NO_SUBPAGE_WRITE;
+       }
        /* Allow subpage writes up to ecc.steps. Not possible for MLC
flash */
        if (!(chip->options & NAND_NO_SUBPAGE_WRITE) && nand_is_slc(chip)) {
                switch (ecc->steps) {
@@ -6681,8 +6686,12 @@ static int nand_scan_tail(struct mtd_info *mtd)
        /* Large page NAND with SOFT_ECC should support subpage reads */
        switch (ecc->mode) {
        case NAND_ECC_SOFT:
-               if (chip->page_shift > 9)
-                       chip->options |= NAND_SUBPAGE_READ;
+               if (chip->page_shift > 9) {
+                       if (IS_ENABLED(CONFIG_ML300PCM31))
+                               pr_warn("setting of NAND_SUBPAGE_READ
bit has been patched out\n");
+                       else
+                               chip->options |= NAND_SUBPAGE_READ;
+               }
                break;

Without the latter, I get

    [    0.833134] fsl,elbc-fcm-nand fff00000.nand: fsl_elbc_cmdfunc:
error, unsupported command 0x5.
    [    0.841822] fsl,elbc-fcm-nand fff00000.nand: read_buf beyond end
of buffer (14 requested, 0 available)

and then an endless loop of errors. With that hunk, I get a little
longer, but without the former the boot stops at

    [    0.918927] ubi0 error: validate_ec_hdr: bad VID header offset
2048, expected 512
    [    0.926549] ubi0 error: validate_ec_hdr: bad EC header
    [    0.931745] Erase counter header dump:
    [    0.935547]        magic          0x55424923
    [    0.939344]        version        1
    [    0.942359]        ec             9
    [    0.945373]        vid_hdr_offset 2048
    [    0.948610]        data_offset    4096
    [    0.951879]        image_seq      1882958541
    [    0.955678]        hdr_crc        0x1a47f3d3
    ...
    [    1.059976] ubi0 error: ubi_io_read_ec_hdr: validation failed for
PEB 0
    [    1.066669] ubi0 error: ubi_attach_mtd_dev: failed to attach
mtd0, error -22
    [    1.073824] UBI error: cannot attach mtd0
    [    1.083983] VFS: Cannot open root device "ubi0:rootfs" or
unknown-block(0,0): error -19

I have

       nand-ecc-mode = "soft";
       nand-ecc-algo = "bch";
       nand-ecc-strength = <4>;
       nand-ecc-step-size = <512>;

in .dts. Is there some device-tree setting/quirk I can use to avoid the
above hacks? Alternatively, can someone provide some hints on how a
mainlinable patch achieving the above would look?

Thanks,
Rasmus
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: subpage reads/writes with fsl_elbc_nand driver

[Boris Brezillon]

On Thu, 31 Jan 2019 14:24:15 +0000
Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:

> I'm in the process of upgrading a board from an old 3.14-based kernel
> with quite a few out-of-tree patches to one based on 4.19, hopefully
> with much fewer such patches.
> 
> In order to even get the new kernel to mount the existing root
> filesystem, I've had to apply the hacks below:
> 
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6657,6 +6657,11 @@ static int nand_scan_tail(struct mtd_info *mtd)
>                 pr_warn("WARNING: %s: the ECC used on your system is too
> weak compared to the one required by the NAND chip\n",
>                         mtd->name);
> 
> +       if (IS_ENABLED(CONFIG_ML300PCM31)) {
> +               pr_warn("setting NAND_NO_SUBPAGE_WRITE bit\n");
> +               chip->ecc.write_subpage = NULL;
> +               chip->options |= NAND_NO_SUBPAGE_WRITE;
> +       }
>         /* Allow subpage writes up to ecc.steps. Not possible for MLC
> flash */
>         if (!(chip->options & NAND_NO_SUBPAGE_WRITE) && nand_is_slc(chip)) {
>                 switch (ecc->steps) {
> @@ -6681,8 +6686,12 @@ static int nand_scan_tail(struct mtd_info *mtd)
>         /* Large page NAND with SOFT_ECC should support subpage reads */
>         switch (ecc->mode) {
>         case NAND_ECC_SOFT:
> -               if (chip->page_shift > 9)
> -                       chip->options |= NAND_SUBPAGE_READ;
> +               if (chip->page_shift > 9) {
> +                       if (IS_ENABLED(CONFIG_ML300PCM31))
> +                               pr_warn("setting of NAND_SUBPAGE_READ
> bit has been patched out\n");
> +                       else
> +                               chip->options |= NAND_SUBPAGE_READ;
> +               }
>                 break;
> 
> Without the latter, I get
> 
>     [    0.833134] fsl,elbc-fcm-nand fff00000.nand: fsl_elbc_cmdfunc:
> error, unsupported command 0x5.
>     [    0.841822] fsl,elbc-fcm-nand fff00000.nand: read_buf beyond end
> of buffer (14 requested, 0 available)
> 
> and then an endless loop of errors. With that hunk, I get a little
> longer, but without the former the boot stops at
> 
>     [    0.918927] ubi0 error: validate_ec_hdr: bad VID header offset
> 2048, expected 512
>     [    0.926549] ubi0 error: validate_ec_hdr: bad EC header
>     [    0.931745] Erase counter header dump:
>     [    0.935547]        magic          0x55424923
>     [    0.939344]        version        1
>     [    0.942359]        ec             9
>     [    0.945373]        vid_hdr_offset 2048
>     [    0.948610]        data_offset    4096
>     [    0.951879]        image_seq      1882958541
>     [    0.955678]        hdr_crc        0x1a47f3d3
>     ...
>     [    1.059976] ubi0 error: ubi_io_read_ec_hdr: validation failed for
> PEB 0
>     [    1.066669] ubi0 error: ubi_attach_mtd_dev: failed to attach
> mtd0, error -22
>     [    1.073824] UBI error: cannot attach mtd0
>     [    1.083983] VFS: Cannot open root device "ubi0:rootfs" or
> unknown-block(0,0): error -19
> 
> I have
> 
>        nand-ecc-mode = "soft";
>        nand-ecc-algo = "bch";
>        nand-ecc-strength = <4>;
>        nand-ecc-step-size = <512>;
> 
> in .dts. Is there some device-tree setting/quirk I can use to avoid the
> above hacks? Alternatively, can someone provide some hints on how a
> mainlinable patch achieving the above would look?

Just pass ubi.mtd=<part-name>,<page-size> on the command line. This way
the VID header will be read/written from/to the second page instead of
the 2nd subpage of the first page.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: subpage reads/writes with fsl_elbc_nand driver

[Boris Brezillon]

On Thu, 31 Jan 2019 14:24:15 +0000
Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:

> I'm in the process of upgrading a board from an old 3.14-based kernel
> with quite a few out-of-tree patches to one based on 4.19, hopefully
> with much fewer such patches.
> 
> In order to even get the new kernel to mount the existing root
> filesystem, I've had to apply the hacks below:
> 
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6657,6 +6657,11 @@ static int nand_scan_tail(struct mtd_info *mtd)
>                 pr_warn("WARNING: %s: the ECC used on your system is too
> weak compared to the one required by the NAND chip\n",
>                         mtd->name);
> 
> +       if (IS_ENABLED(CONFIG_ML300PCM31)) {
> +               pr_warn("setting NAND_NO_SUBPAGE_WRITE bit\n");
> +               chip->ecc.write_subpage = NULL;
> +               chip->options |= NAND_NO_SUBPAGE_WRITE;
> +       }
>         /* Allow subpage writes up to ecc.steps. Not possible for MLC
> flash */
>         if (!(chip->options & NAND_NO_SUBPAGE_WRITE) && nand_is_slc(chip)) {
>                 switch (ecc->steps) {
> @@ -6681,8 +6686,12 @@ static int nand_scan_tail(struct mtd_info *mtd)
>         /* Large page NAND with SOFT_ECC should support subpage reads */
>         switch (ecc->mode) {
>         case NAND_ECC_SOFT:
> -               if (chip->page_shift > 9)
> -                       chip->options |= NAND_SUBPAGE_READ;
> +               if (chip->page_shift > 9) {
> +                       if (IS_ENABLED(CONFIG_ML300PCM31))
> +                               pr_warn("setting of NAND_SUBPAGE_READ
> bit has been patched out\n");
> +                       else
> +                               chip->options |= NAND_SUBPAGE_READ;
> +               }
>                 break;
> 
> Without the latter, I get
> 
>     [    0.833134] fsl,elbc-fcm-nand fff00000.nand: fsl_elbc_cmdfunc:
> error, unsupported command 0x5.
>     [    0.841822] fsl,elbc-fcm-nand fff00000.nand: read_buf beyond end
> of buffer (14 requested, 0 available)

For that part of the problem, you should consider converting the driver
to ->exec_op().

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: subpage reads/writes with fsl_elbc_nand driver

[Rasmus Villemoes]

On 31/01/2019 17.11, Boris Brezillon wrote:
> On Thu, 31 Jan 2019 14:24:15 +0000
> Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> 
>> --- a/drivers/mtd/nand/raw/nand_base.c
>> +++ b/drivers/mtd/nand/raw/nand_base.c
>> @@ -6657,6 +6657,11 @@ static int nand_scan_tail(struct mtd_info *mtd)
>>                 pr_warn("WARNING: %s: the ECC used on your system is too
>> weak compared to the one required by the NAND chip\n",
>>                         mtd->name);
>>
>> +       if (IS_ENABLED(CONFIG_ML300PCM31)) {
>> +               pr_warn("setting NAND_NO_SUBPAGE_WRITE bit\n");
>> +               chip->ecc.write_subpage = NULL;
>> +               chip->options |= NAND_NO_SUBPAGE_WRITE;
>> +       }
>>         /* Allow subpage writes up to ecc.steps. Not possible for MLC
>> flash */
>> longer, but without the former the boot stops at
>>
>>     [    0.918927] ubi0 error: validate_ec_hdr: bad VID header offset
>> 2048, expected 512
>>     [    0.926549] ubi0 error: validate_ec_hdr: bad EC header
>>     [    0.931745] Erase counter header dump:
>>     [    0.935547]        magic          0x55424923
>>     [    0.939344]        version        1
>>     [    0.942359]        ec             9
>>     [    0.945373]        vid_hdr_offset 2048
>>     [    0.948610]        data_offset    4096
>>     [    0.951879]        image_seq      1882958541
>>     [    0.955678]        hdr_crc        0x1a47f3d3
>>     ...
>>     [    1.059976] ubi0 error: ubi_io_read_ec_hdr: validation failed for
>> PEB 0
>>     [    1.066669] ubi0 error: ubi_attach_mtd_dev: failed to attach
>> mtd0, error -22
>>     [    1.073824] UBI error: cannot attach mtd0
>>     [    1.083983] VFS: Cannot open root device "ubi0:rootfs" or
>> unknown-block(0,0): error -19
>>
> Just pass ubi.mtd=<part-name>,<page-size> on the command line. This way
> the VID header will be read/written from/to the second page instead of
> the 2nd subpage of the first page.
> 

Thanks for the quick response. I tried this, and the board does seem to
boot without the hunk above applied. Unfortunately, it seems to get
bricked after I write anything to the rootfs and reboot. I'll
investigate more thoroughly later, and also look into the conversion to
->exec_op, but for now I need to look into getting other parts of the
board working with a new kernel.

Thanks,
Rasmus
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/