imx-bbu-nand-fcb: Make robust against power cuts
This patch makes the update to Nand robust against power failures. With this we make sure that during every step of the update at least one of the two images on Nand is readable and valid. Also this patch makes it possible to refresh/repair the boot images on Nand. This may become necessary when a previous update has been interrupted due to a power cut, or when the number of bitflips is near to the number we can correct. This is also done in a way that allow power cuts at every step. We assume the following layout in the Nand flash: fwmaxsize = (n_blocks - 4) / 2 block 0 ---------------------- | FCB/DBBT 0 | 1 ---------------------- | FCB/DBBT 1 | 2 ---------------------- | FCB/DBBT 2 | 3 ---------------------- | FCB/DBBT 3 | 4 ---------------------- | Firmware slot 0 | 4 + fwmaxsize ---------------------- | Firmware slot 1 | ---------------------- When the layout found on the device differs from the above the update won't be robust, but nevertheless works. Since the layout is changed to the above during the update, the next update will be robust. Here's the strategy we use to implement a robust update: The FCBs contain pointers to the firmware slots in the Firmware1_startingPage and Firmware2_startingPage fields. Note that Firmware1_startingPage doesn't necessarily point to slot 0. We exchange the pointers during update to atomically switch between the old and the new firmware. - We read the first valid FCB and the firmware slots. - We check which firmware slot is currently used by the ROM: - if no FCB is found or its layout differs from the above layout, continue without robust update - if only one firmware slot is readable, the ROM uses it - if both slots are readable, the ROM will use slot 0 - Step 1: erase/update the slot currently unused by the ROM - Step 2: Update FCBs/DBBTs, thereby letting Firmware1_startingPage point to the slot we just updated. From this moment on the new firmware will be used and running a refresh/repair after a power failure after this step will complete the update. - Step 3: erase/update the other firmwre slot - Step 4: Eventually write FCBs/DBBTs again. This may become necessary when step 3 revealed new bad blocks. Refreshing the firmware which is needed when when blocks become unreadable due to read disturbance works the same way, only that the new firmware is the same as the old firmware and that it will only be written when reading from the device returns -EUCLEAN indicating that a block needs to be rewritten. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
WIP_next-LS
master
next
stable/v2017.05
stable/v2017.06
stable/v2017.07
stable/v2017.11
stable/v2018.07
stable/v2018.09
stable/v2018.12
v2020.07.0
v2020.06.0
v2020.05.0
v2020.04.0
v2020.03.0
v2020.02.0
v2020.01.0
v2019.12.0
v2019.11.0
v2019.10.0
v2019.09.0
v2019.08.1
v2019.08.0
v2019.07.0
v2019.06.1
v2019.06.0
v2019.05.0
v2019.04.0
v2019.03.0
v2019.02.0
v2019.01.0
v2018.12.0
v2018.11.0
v2018.10.0
v2018.09.1
v2018.09.0
v2018.08.1
v2018.08.0
v2018.07.2
v2018.07.1
v2018.07.0
v2018.06.0
v2018.05.0
v2018.04.0
v2018.03.0
v2018.02.0
v2018.01.0
v2017.12.0
v2017.11.0
v2017.10.0
v2017.09.0
v2017.08.0
v2017.07.1
v2017.07.0
v2017.06.2
v2017.06.1
v2017.06.0
v2017.05.4
v2017.05.3
v2017.05.2
v2017.05.1
v2017.05.0
v2017.04.0
v2017.03.0
v2017.02.0
v2017.01.0
v2016.11.0
v2016.10.0
v2016.09.0
v2016.08.0
v2016.07.0
v2016.06.0
v2016.05.0
|
---|
|
common/imx-bbu-nand-fcb.c |
---|