4KB LEB's on QSPI and ubifs

4KB LEB's on QSPI and ubifs

[Alison Chaiken]

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.

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.

2. Something else entirely?

Thanks for your suggestions,
Alison Chaiken
Peloton Technology

Re: 4KB LEB's on QSPI and ubifs

[Richard Weinberger]

Alison,

On Thu, Jul 28, 2016 at 3:12 AM, Alison Chaiken <alison@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

Re: 4KB LEB's on QSPI and ubifs

[Artem Bityutskiy]

On Thu, 2016-07-28 at 09:45 +0200, Richard Weinberger wrote:
> Alison,
> 
> On Thu, Jul 28, 2016 at 3:12 AM, Alison Chaiken <alison@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.

This is because Linux page cache operates with 4KiB pages so 4KiB was a
natural choice.

> But that could also be reduced...

In theory yes, but it'd add lots of complexity I think. I guess
teaching UBI exposing virtual eraseblock sizes consisting of multiple
physical ones would be easier. Of course the physical ones do not have
to be continuous, so that if one of them goes bad, another could be
picked. There could be one EC/VID header per virtual block, I guess -
less overhead.


>