[U-Boot] [NAND] fsl_elbc_nand and subpage access

[Scott Wood <scottwood@freescale.com>]

On Tue, 2013-11-19 at 17:01 +0100, Valentin Longchamp wrote:
> Hello Scott,
> 
> For the kmp204x boards, UBI is used to take care of the volumes created and
> deleted on our NAND Flash. I am currently using a 3.10 kernel and when UBI
> attaches mtd0, this works fine:
> 
> > UBI: attaching mtd0 to ubi0
> > UBI: scanning is finished
> > UBI: attached mtd0 (name "ubi0", size 128 MiB) to ubi0
> > UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
> > UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
> > UBI: VID header offset: 512 (aligned 512), data offset: 2048
> > UBI: good PEBs: 1024, bad PEBs: 0, corrupted PEBs: 0
> > UBI: user volume: 0, internal volumes: 1, max. volumes count: 128
> > UBI: max/mean erase counter: 2/2, WL threshold: 4096, image sequence number: 598317289
> > UBI: available PEBs: 980, total reserved PEBs: 44, PEBs reserved for bad PEB handling: 40
> 
> It is interesting to notice that with the kernel's MTD subsystem, subpage access
> is supported (we don't use HW ECC but SOFT_BCH) and thus the VID header offset
> is going to be 512 thanks to this subpage support.
> 
> Now, when I try to access the same NAND flash ubi partition in u-boot 2013.10,
> this fails:
> 
> > => ubi part ubi0
> > UBI: attaching mtd1 to ubi0
> > UBI: physical eraseblock size:   131072 bytes (128 KiB)
> > UBI: logical eraseblock size:    126976 bytes
> > UBI: smallest flash I/O unit:    2048
> > UBI: VID header offset:          2048 (aligned 2048)
> > UBI: data offset:                4096
> > UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
> > UBI error: validate_ec_hdr: bad EC header
> > UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
> > UBI error: ubi_init: cannot attach mtd1
> > UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
> > UBI init error 22
> > => 
> 
> Since u-boot does not support subpage access with the fsl_elbc_nand driver, it
> choses a VID offset that is as big as a page and here we have an incompatibility...
> 
> I know that I could give an argument to the kernel (ubi.mtd=0,2048) so that it
> also ignores the subpages, but that feels like a not optimal workaround (that I
> am currently using but I would like to get rid of if), and our other systems
> (kirkwood and 83xx based) support NAND subpage access in u-boot nicely.
> 
> Is there a reason why fsl_elbc_nand does not allow subpage access in the case of
> SOFT_(BCH_)ECC ?

I think you mean "is there a good reason why..." and the answer is "no".

Neither IFC nor eLBC were designed to work with subpage accesses, and on
IFC it doesn't work because of the type of ECC used.  U-Boot was fixed
first, and because neither IFC nor eLBC were designed for this, we set
the "no subpage write" flag on both of them.

Later, when testing the fix for Linux, it was noticed that eLBC was
already working.  At that point I realized that, even though it was a
bit hacky and not truly working as intended, you could get away with it
on eLBC because the ECC of the unwritten subpages would be 0xff and thus
things would still work even though we were really writing the whole
page every time -- and UBI would still gain the intended benefits, which
IIRC were about space saving rather than write performance.

Unfortunately, that means that people could have already been using
either type of UBI (based on existing Linux, or existing U-Boot) so it
wasn't clear what to do to resolve the compatibility issue -- though I
favor changing U-Boot to match Linux.

-Scott