porting marvell-nand driver for u-boot

Zak Hays zak.hays at lexmark.com
Mon Mar 9 15:27:15 CET 2020

Hi Miquèl,

Thanks for the quick response!

>Hi Zak,
>Zak Hays <zak.hays at lexmark.com> wrote on Thu, 5 Mar 2020 19:09:54 +0000:
>> Hello all!
>> I've recently run into an issue where I have enabled on-die ECC in Linux which required the block sizing I had been using to change from 2048 to 512. This is now causing UBI to throw the following error:
>You know that you cannot do that and keep the content of your NAND
>device right? You are basically enabling subpage access and UBI does
>not support subpage changes.

Yes, I am aware of this and have other plans to save away the contents
of the NAND device and rewrite with the new block sizing.

>Otherwise, I think subpage access are supported by the pxa driver.

Can you clarify this a little more? It looks like the u-boot pxa
driver sets the NAND_NO_SUBPAGE_WRITE option by default in
alloc_nand_resource(). That decides the value of mtd->subpage_sft in
nand_base which ultimately leads to the UBI error I get below. Does
the NO_SUBPAGE_WRITE automatically imply that SUBPAGE_READ is not
allowed as well? Is there some other way to bypass this flag?

>> ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
>> ubi0 error: validate_ec_hdr: bad VID header offset 512, expected 2048
>> ubi0 error: validate_ec_hdr: bad EC header
>> As far as I can tell, the 2048 value is hard-coded in the current pxa nand driver I had been using in u-boot. It seems like the preferred path to proceed would be to port the current marvell-nand driver from Linux into u-boot but
>> that seems a little more involved as it will require changes to the core nand driver as well. Are there any current plans to adapt these changes from v4.16+ of Linux? If so, is there a patch set somewhere that I could pull in to start
>> testing?
>> Thanks!
>> Zak Hays

More information about the U-Boot mailing list