Re: No oob scheme defined for oobsize 224 on imx6ull board

[Sascha Hauer <sha@pengutronix.de>]

On Mon, Feb 22, 2021 at 10:55:55PM +0800, jameszxj wrote:
>    Hi Sascha,
>    >
>    > Subject: Re: No oob scheme defined for oobsize 224 on imx6ull board
>    >
>    > Hi,
>    >
>    > On Fri, Dec 18, 2020 at 05:11:11PM +0800, 郑小军 wrote:
>    > > Hi, all
>    > >     I am trying to run barebox on my i.mx6ull board.  I inherit from
>    > > nxp-imx6ull-evk. When I added nand flash support, system crashed. I
>    > > found that the pointer "chip->legacy.set_features" and
>    > > "chip->legacy.get_features" in nand_mxs.c was NULL.
>    > > I replaced it with nand_set_features() and nand_get_features().
>    >
>    > This looks like the correct solution for this. Care to send a patch?
>    >
>    > > Barebox didn't crash again, but I get the errors:
>    > >         nand_base: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
>    > >         nand_base: Micron MT29F4G08ABAEAWP
>    > >         nand_base: 512 MiB, SLC, erase size: 256 KiB, page size: 4096,
>    > > OOB size: 224
>    > >         WARNING: at
>    drivers/mtd/nand/nand_base.c:5591/nand_scan_tail()!
>    > >         WARNING: No oob scheme defined for oobsize 224
>    > >         mxs_nand 1806000.nand-controller@1806000.of: probe failed:
>    > > Invalid argument
>    >
>    > You are falling into:
>    >
>    > /*
>    > * If no default placement scheme is given, select an appropriate one.
>    > */
>    > if (!mtd->ooblayout &&
>    >     !(ecc->mode == NAND_ECC_SOFT && ecc->algo == NAND_ECC_BCH)) {
>    > ...
>    > }
>    >
>    > Normally mtd->ooblayout should be set at this point. the nand_mxs driver
>    > currently misses to set it. I think you have to adopt
>    > gpmi_ooblayout_ecc() and gpmi_ooblayout_free() from the Linux driver for
>    > barebox.
>    >
>    > This bug seems to trigger for NANDs with bigger page sizes. I only
>    > tested the last NAND layer update with smaller page sizes. So it's not
>    > you who misses something, it's me who missed something ;)
>    >
>    I'm trying to port gpmi_ooblayout_ecc() and gpmi_ooblayout_free() from
>    Linux, barebox can run and
>    load linux, but I encountered another error, barebox can not write itself
>    or kernel(linux) to nand device through
>    barebox_update command. I traced the source and found that the
>    bbu_std_file_handler() need unprotect device, but nand driver do not
>    supply the unlock function, so nand_unlock() return -ENOTSUPP, and
>    bbu_std_file_handler() failed.

bbu_std_file_handler() checks for -ENOSYS, likely this error code
changed to -ENOTSUPP over time which should be fixed.
Anyway, bbu_std_file_handler() is the wrong function to write barebox to
NAND, this won't work. You'll need imx6_bbu_nand_register_handler() to
create a barebox update handler for NAND.

>    Linux driver just assign mtd->_unlock to NULL, but barebox assign it to
>    nand_unlock(), I found nand_macronix.c supply ops.unlock_area
>    function, so mtd->_unlock is needed. So I make the nand_unlock() return
>    -ENOSYS, it it the right way?

People use -ENOTSUP nowadays, I think using -ENOSYS for saying "I don't
need that operation" is deprecated. So we should rather extend the test
in bbu_std_file_handler() to also check for -ENOTSUP.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox