spi-nand: how to store environment with badblock handling in qspi nand

Kegl Rohit keglrohit at gmail.com
Sat Jun 25 10:10:08 CEST 2022


Hello!

Is it possible to store the environment inside a mtd partition when
using a single qspi nand chip as storage?
CONFIG_MTD_SPI_NAND=y

The idea is to separate the NAND into two system A/B.

1.Solution:
mtdparts_nand0=2m(uboot),16m(system)

system will be an ubifs containing env+env_redundant +
kernel_a+dtb_a+rootfs_a + kernel_b+dtb_b+rootfs_b.
Uboot will read the env and load and start the selected a or b system.

With this solution ubifs will do all badblock handling. But system a
and b are not really isolated. All will be lost if the one ubifs gets
bad.

2.Solution:
mtdparts_nand0=2m(uboot),512k(env),512k(env_redundant),8m(system_a),8m(system_b)

system_a/b will be ubifs containing kernel+dtb+rootfs.
An environment outside the ubifs is needed to switch between system_a/b.

But I could not find a suitable option to store the environment
outside the ubi mtd partitions when using MTD_SPI_NAND.

Here are my findings:
CONFIG_ENV_IS_IN_NAND is used for the parallel NAND interface and wont
work with MTD_SPI_NAND.
CONFIG_ENV_IS_IN_SPI_FLASH is used for spi NOR flash and does not
handle badblocks => also wont work.
CONFIG_ENV_IS_IN_FLASH another flash subsystem??

Bad block handling seems to be only implemented for
CONFIG_ENV_IS_IN_NAND using CONFIG_ENV_RANGE.
Setting CONFIG_ENV_RANGE > CONFIG_ENV_SIZE will create tailing space
for skipping bad blocks.

CONFIG_ENV_IS_IN_UBI will do badblock handling, but it would be a huge
overhead to create an extra ubifs mtd partition only for the
environment.


Has anyone already created the A/B system approach with the mtd spi
nand interface and can give me some input?
Am I missing something and there is a much simpler solution?
Or would it be fine to use one big ubifs because ubi is reliable enough?


More information about the U-Boot mailing list