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