I’ve been wrestling with this issue for a long time and just cant crack it.
We’re attempting to get the most secure secure boot chain that we can working and I believe so far we’ve got the process for generating keys and burning them correct. I’ve had a few boards and have burned the fuses with the following fuse config file (obviously removed the keys). jetson-fuses.txt (358 Bytes)
We’re using jetpack-nixos to make our own OS and flashing it to an nvme disk, but we’ve found that the system boots just fine with the “SecurityMode” fuse is left unburned, however once burned we can no longer get the machine to boot NixOS, and only ever get the following error every time. We found this by using 2 boards, and burning more and more fuses, working the way down the list of fuses in the attached config file and testing after every step until the board no longer booted properly. jetson-boot-error.txt (40.4 KB)
What are we doing wrong here? I thought that last fuse setting only locked things down to prevent further modification of fuses. Am I missing something here?
it’s mentioned by developer guide, Secure Boot.
after the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.
we’ve tested and it’s confirmed we can burn fuses and boot up success on Orin-NX-8GB + r35.4.1
you may see-also Topic 263458 for reference.
Do you know if this fuse setting changes or enables any other behaviour except blocking additional fuse write requests?
On our boards, the instant this is enabled, our board stops being able to boot. Burning all the other fuses beforehand and stopping before burning the SecurityMode fuse does not cause any issues. But the moment we burn the SecurityMode fuse it fails to boot.
you cannot change fuse values once a fuse bit is set to 1.
for example, a fuse value of 1 (0x01) can be changed to 3 (0x03) or 5 (0x05), but not to 4 (0x4) because bit 0 is already programmed to 1.
moreover,
the recommended way is to burn all fuses together instead of burning fuses step-by-step.
Yes, burning them all together is what we have been doing. However when we burn all of them together (including the SecurityMode fuse) we are unable to boot. When we take another board, and burn all the same fuses together and just dont burn the SecurityMode fuse, we can still boot the system. If I then burn the SecurityMode fuse on the second board, to bring it in line with the first, the second board is unable to boot. Just like the first.
The act of burning that fuse is somehow changing behaviour somewhere.
An example fuse configuration file was always included in the original post, however I have removed the key values to protect them. I will attach another here with correct, but unused keys to demonstrate that our key generation technique is correct. We have scripted the generation process to generate keys and produce the final fuse.xml file. jetson-fuses-2.txt (2.7 KB)
Our flash process for a non-working system is as follows:
Generate keys and fuse configuration files
Download L4T, ATF and OPTEE source, checking out the relevant versions
Using our keys generated in step 1, generate an EKS image with the correct OEM_K2 fuse value, FV and sym_key values. Eventually producing eks_t234.img
Recompile OPTEE to contain our new FV and disable use of test keys, eventually producing tos-optee_t234.img
Replace files in Linux_for_Tegra/bootloader path with the ones generated in step 3 & 4
Place the board into recovery mode and connect to host computer
Use the provided odmfuse.sh script to burn the fuses in one step ./odmfuse.sh -X <XML_FILE_PATH> -i 0x23 jetson-orin-nano-devkit-nvme
Power cycle the board just to be sure, and enter recovery mode again
Run ./flash.sh -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit-nvme internal to push the updated tos-optee and eks images.
Insert pre-flashed NVMe disk and boot
Result: Board does boot to uefi, but when it attempts to boot our OS we get the same error as in original posts log file every time.
Our flash process for a working system is as follows:
Generate keys and fuse configuration files
Remove line containing<fuse name="SecurityMode" size="4" value="0x1"/>from fuse configuration file.
Download L4T, ATF and OPTEE source, checking out the relevant versions
Using our keys generated in step 1, generate an EKS image with the correct OEM_K2 fuse value, FV and sym_key values. Eventually producing eks_t234.img
Recompile OPTEE to contain our new FV and disable use of test keys, eventually producing tos-optee_t234.img
Replace files in Linux_for_Tegra/bootloader path with the ones generated in step 3 & 4
Place the board into recovery mode and connect to host computer
Use the provided odmfuse.sh script to burn the fuses in one step ./odmfuse.sh -X <XML_FILE_PATH> -i 0x23 jetson-orin-nano-devkit-nvme
Power cycle the board just to be sure, and enter recovery mode again
Run ./flash.sh -c bootloader/t186ref/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit-nvme internal to push the updated tos-optee and eks images.
Insert pre-flashed NVMe disk and boot
Result: Board does boot to uefi, and boots our OS successfully.
it looks like an EL3 exception in ATF.
please give it a try to disabling the PMU nodes and check : "arm,dsu-pmu" , "nvidia,scf-pmu".
you may see-also documentation for more details…
for instance, $public_sources/kernel_src/kernel/kernel-5.10/Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt
here’re steps to disassembler the dtb file into text file. $ dtc -I dtb -O dts -o temp.dts tegra234-xxx.dtb
and… you may convert the revised DTS file into a new DTB binary as following. $ dtc -I dts -O dtb -o new-output.dtb temp.dts
BTW,
do you have kernel logs disabled? you may enable kernel logs for digging into this.
BTW,
here’s ATF binary file update to address this issue, Topic282587_Apr18.7z (37.3 KB)
please based-on r35.4.1 to apply these update to fix an EL3 exception in ATF.