DaVinci RBL 1.0

This is the answer given by Daniel Allred on DaVinci RBL ECC/Bad block handling question:

The RBL does not do any form of bad block checking/management. It will simply rely on using the HW ECCs generated during the page reads to verify that a page read was correct. It will not use the ECC values to do error correction either.

If the RBL sees an ECC mismatch occurs during a page read, it will abort the operation from that block and try the next block. It will do this up to block 5 of the NAND device.

If the RBL can't get a successful read out of the first five blocks, the boot will fail and will default to attempting a UART boot. One recommendation would be to fill the first five blocks with the same header and UBL.

Then if the first one ever goes bad, you'll already have four more copies ready to do the job. But if all five of those blocks go bad (which I think is unlikely over the lifetime of the device) then the device won't boot.

But if a block does go bad, the ECC check should detect it, unless the data and ECC are both corrupted in such a way that they still match (which I think would be extremely improbable). So a corrupted image booting up should never be an issue.

Since the pages/blocks holding the UBL aren't going through read and write cycles on a continuous basis, they will probably last a good while, but I understand that blocks can lose their data after some time, so some kind of periodic rewrite of these blocks might be a good idea, like maybe every 1000th system shutdown, for example.