Changes

With respect to the NOR flash memories, NAND devices are known to be quite challenging with regard to the reliability. This is especially true when the NAND flash is used as the boot device. Several techniques such as wear leveling and bad block management have to be implemented to achieve an acceptable reliability.

This document describes some details provides information about the NAND devicemanagement, in order to handle it properly when it is used as the boot device on NXP i.MX6-based products.

Even though the examples example shown here refers to an i.MX6SoloX board, the approach is substantially the same across all the i.MX6 family.

The test bed used in this example consists of an i.MX6SoloX-board equipped with a 512MB 8-bit asynchronous 1-bit ECC SLC NAND memory which is connected to the EIM bus of the SoC. The boot firmware image is the U-Boot bootloaderbinary file (<code>mx6sx_board_nand_u-boot.imx</code>). Its size is about 400 kB. From the point of view of MTD partitions, the boot partition is <code>mtd0</code> which is 8MB.

[[File:Kobs-ng-boot-partition.png|thumb|center|600px|Organization of the boot partition]]  The bootrom plays a major role in the boot process of any i.MX6 SoC. In case the NAND memory is the boot devices, this implies that the boot partition must be organized in order fulfill the bootrom requirements. Specifically, it must containcontains:

**Three addresses which indicate whereare located  il partizionamento della ***The Discovered Bad Block Table (DBBT) which is the data structure used to manage the bad blocks of the NAND utilizzato fino ad ora definisce una schema tipico, riservando una partizione a U-Boot, due partizioni alle copie ridondate del suo environment, una partizione al kernel di Linux ecc. Quando questo schema è stato scelto, chiaramente non erano ancora state definite delle specifiche precise relativamente alle dimensioni da utilizzare.flashLa prima partizione va comunque dimensionata tenendo conto di vari fattori, tra i quali:***The first copy of the firmware to load- il fatto che 1MB viene usato per memorizzare le strutture dati utilizzate dal bootrom per gestire il boot da NAND***The second (redundant) copy of the firmware to load- la dimensione dell'immagine di u-boot può aumentare nel caso di rilasci di nuove versioni*The DBBT- vengono salvate due immagini ridondate di u-boot, come richiesto dalle specifiche di funzionamento del bootrom*The first copy of the firmware- è opportuno sovradimensionare la partizione per gestire la possibilità che ci siano dei bad block*The second copy of the firmware.

Nel caso specifico di VRAGFor more details about the bootrom e the NAND boot process, in prima battuta si è adottato uno schema di partizionamento già in uso su altri prodotti basati su please refer to the ''System Boot'' chapter of the Reference Manual of the specific i.MX6, in cui l'applicazione di questi criteri aveva portato a stabilire in 8MB la dimensione della partizione destinata a U-Boot. Non essendoci stati particolari vincoli nella fase iniziale di sviluppo di VRAG, è stata mantenuta questa dimensione. Ora che ci si sta avviando alla chiusura delle funzionalità e, di conseguenza, a determinare i footprint di memoria definitivi dei vari componenti software del sistema, si può andare a ridefinire la dimensione della partizione /dev/mtd0, riducendola se necessario per ottimizzare l'uso della flashApplication Processor.

The burning of the boot partition is typically performed by the [https://github.com/NXPmicro/imx-kobs <code>kobs-ng</code> tool]. It deals with several things