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

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

 



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 and 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.
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?

Although the gpmi_ooblayout_ecc() is worked, but the source included 
ugly debug codes, I'll send a patch after clean it.


> Regards,
>   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




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux