LS1043A: Secondary Image Flag in CSF

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1043A: Secondary Image Flag in CSF

475 Views
BeatS
Contributor II

Hi
An image (ESBC) booted by the ISBC is prepended with a CSF header. This header contains a "Secondary Image Flag" (Offset 0x25), which, if set to "1", tells the ISBC to try to verify and start a secondary image (pointed to by SCRATCHRW3) if the verification of the primary image fails. What happens if during an update of the primary image an error occurs and as a result the CSF is not written? Maybe the according block was erased, but not written due to a power fail, let's say. This would brick the whole system, despite the fact, that there is a working secondary image. How does the ISBC interpret a CSF? What happens if the Barker code and the "Secondary Image Flag" in the primary image's CSF is both set to 0xFF (sector was erased) and SCRATCHRW3 points to a working "Secondary Image"?

Regards,
BeatS

Labels (1)
0 Kudos
2 Replies

453 Views
ufedor
NXP Employee
NXP Employee

That is a very good question.
There is no save guard for power failure. e.g. if you corrupt the RCW, it will the system will as well. The typical solution is to send it back to the factory to re-program the flash memory/boot media.
If you refer to normal upgrade cycle, you can verify the update image (write after read to confirm the image is not corrupted). Verify the CSF header (and other images) are correctly written before you reboot the system.
The secondary image feature was designed to safeguard your system when the image is successfully written, but fail authentication. Example: you revoked one of the key pairs that sign the software image, and make it not bootable and force it to use the alternate image location.

0 Kudos

446 Views
BeatS
Contributor II

Thank you for your explanations Ufedor
But imagine, if there would be no dependency (Secondary image flag) between the CSF of the primary image and the secondary image, then the concept would even work in case of a power failure, because after a failing verification of the primary image, the ISBC could simply check the SCRATCHRW3 register whether it points to a CSF of a secondary image (Barker code) and then try to cryptographically verify the secondary image. But as the concept is now the ISBC will not even try this, if the "Secondary image flag" is wrong in the primary image's CSF.
Regards,
BeatS

0 Kudos