4KB LEB's on QSPI and ubifs

[Richard Weinberger]

Alison,

On Thu, Jul 28, 2016 at 3:12 AM, Alison Chaiken <alison at peloton-tech.com> wrote:
> I'm helping to bring up a board that contains a Micron n25q512ax3 Quad
> SPI-NOR.    As discussed previously at linux-mtd,
>
>                http://lists.infradead.org/pipermail/linux-mtd/2013-July/047665.html
>
> ubifs won't work with the 4 kB erase sectors like those used by this
> chip, as it fails with
>
>               UBIFS error (ubi0:0 pid 3289): init_constants_early: too
> small LEBs (3968 bytes), min. is 15360 bytes
>
> We are using a 4.1 PREEMPT_RT_FULL kernel, but as far as I can tell,
> the relevant code in spi-nor.c and ubifs/super.c is unchanged in
> recent 4.7.    Therefore, with SECT_4K  as a configuration for this
> device, ubifs still will not work.
>
> What is the best alternative?
>
> 0. Create a UBI volume, but mount a different kind of flash filesystem
> on it.   Perhaps a different filesystem is a better choice for QSPI?
> ubiattach and ubimkvol work fine with the device.  Our use case
> involves a set of files that will likely only ever be written at
> system installation time.

If your rootfs can be read-only you can give ubiblock+squashfs a try.

> 1. Remove SECT_4K from the entry in spi_nor_ids[] for the device and
> use ubifs.   As I understand 548cd3a "mtd: spi-nor: Add quad I/O
> support for Micron SPI NOR" that added SECT_4K, this removal will make
> the device slower, but not otherwise cause problems.    The device's
> datasheet reads,
>
>                 – Subsector erase 4KB uniform granularity blocks
>                 – Sector erase 64KB uniform granularity blocks
>
> which suggests that removing SECT_4K from spi_nor_ids[] will result in
> 64KB sector erase blocks rather than 4KB subsector ones that ubiattach
> detects now.

Yes, AFAIK SECT_4K is just an optimization to make erases faster since you
erase less bytes.

> 2. Something else entirely?

Depending on how much research want to do you can try massaging UBIFS
for very small LEBs.
When you change UBIFS_MIN_LEB_SZ to less than 4k the first thing that
will explode
is that an UBIFS data node won't fit in a LEB since UBIFS data chunks are 4k.
But that could also be reduced...

-- 
Thanks,
//richard