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@xxxxxxxxxx: 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
