Hi,
I'm trying to enable secure boot on a custom hardware platform based on iMX8 Mini.
By following the available documentation, I was able to create a boot image with correct signatures, I'm sure about that because the hab_status command did not show any hab event and also the image verifier tool did not show any error.
To close the device, I programmed the SRK_HASH fuses and the SEC_CONFIG fuses, but after this step my board does not start anymore and does not show anything on serial console.
I'm quite sure that the SRK_HASH has been programmed properly, but I have doubts on SEC_CONFIG: to enable secure boot I should have used the below command:
fuse prog 1 3 0x02000000
that sets bit 25.
However, before doing the modification, I read the content of SEC_CONFIG and I saw the below value:
fuse read 1 3
0x8000000
So, since I saw bit 27 set to 1, I had the great idea to use the below command:
fuse prog 1 3 0x0A000000
To preserve bit 27 and set bit 25.
Question:
Is it possible that the above command put SEC_CONFIG to an invalid value so that the ROM bootloader does not even start the SPL?
If yes, is there any way to restore the board?
Best Regards
Hi,
many thanks for your answer, this is coherent with the current behaviour.
Only a last question:
Since I did not program any lock bit, do you think that using an hardware debugger would it be possible to restore the board?
Best Regards
If the chip became bricked after the reserved bits were written, then it is impossible to restore the chip, because the fuse operation is a one-time and irreversible process.
Bit 27 is a reserved bit and cannot be programmed by the customer. Rather than whether this command(fuse prog 1 3 0x0A000000) will invalidate sec_config, it is more likely that the behavior of the entire chip will become unpredictable.
Hello,
Unfortunately, no, not by clearing fuses, eFuses are one-time programmable. Once sec_config is blown, you cannot “unblow” it