Persistent State in a NAND-based environment

On some boards it is necessary to use NAND flash to store persistent state and configuration. This is normally provided by the config store.

For simplicity, a bridge driver has been developed which allows the config store to be used by RedBoot as if it were NOR flash. (The reason for this is that the RedBoot fconfig system has a much lower overhead than the NAND storage system, in order to operate in environments with very limited resources. NAND-based boards have much more flash and RAM available, so the overhead of the extra layers is not an issue.)

To RedBoot, the config store behaves identically to regular (NOR) flash storage. However its use has a number of implications:

  • If the NAND is repartitioned or erased, all persistent configuration is likely to be lost.

  • The configuration is susceptible to the same wearout and read disturb effects that affect all NAND parts over time. (This is mitigated by allowing multiple NAND blocks for the config store partition, which are used in rotation.)

Even though the bridge driver may be in use, it is still possible to use the config store directly for other options.

Note: Some platform HALs use this mechanism to set the size of the config store partition in such a way that does not depend on RedBoot. Refer to the documentation for those HAL ports for details.

Manipulating persistent state stored on NAND

To modify configuration items managed by RedBoot, use the fconfig command in the usual way. See the Section called Persistent State Flash-based Configuration and Control.

To modify items in the config store which are not managed by RedBoot, use the nconfig command. See the Section called NAND configuration commands. You may also wish to manipulate the NAND array with the nand command family; see the Section called NAND manipulation commands.

2017-02-09
Documentation license for this page: Open Publication License