subpage reads/writes with fsl_elbc_nand driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux