I’m testing the secure boot with the “Jetson Platform Fuse Burning and Secure Boot Documentation and Tools” package with the R21.5 release.
I have created the keys, burn the fuses and now I’m trying to flash the signed bootloader.
The sign procedure seems to be correct because the flashing starts on the board (without the keys it doesn’t start).
When the procedure starts to upload the bootloader, it hangs with this error on the serial port:
[0000.000] [TegraBoot] (version UNDEF_BUILD)
[0000.004] Reset reason: power on reset
[0000.007] Processing in recovery mode
[0000.011] Established communication link with host
[0000.146] Downloaded bct successfully
[0000.149] No Battery Present
[0000.153] Sdram initialization is successful
[0000.164] Downloaded DTB successfully
[0000.190] Unsupported Platform 0xffff
[0000.193] populate platform details failed with error 0x2 in DownloadBootloader func at 887 line
[0000.202] Downloading Bootloader failed with 0x2
[0000.206] Download Bootloader failed with error 0x2 in NvTbootServer func at 1386 line
[0000.214] Error is 2
---> "[0000.190] Unsupported Platform 0xffff"
This is probably unrelated, but would be good to know before starting a more complicated conversation: Is your host a VM, or is it a native Linux install? Have you verified a regular flash works from this host prior to trying to work with the boot loader?
Also, have you verified your procedure for flashing the boot loader when signing is not required (if ordinary boot loader flash doesn’t work, then it is hard to imagine a secure boot loader flash would also work)?
The host is a native Linux install and the regular flash works without problem.
Without signing, the flashing procedure is ok, the error appears only when flashing with signed binaries.
One thing to notify is that the board is a custom one and not the Jetson TK1, but the system images are ok, without signing I can flash and use the system correctly.
you got the failure at nvtboot board detection (boardid) stage since you’re using custom board.
BTW, are you able to make fused image with noflash command?
thanks
yes, with noflash option I can create the signed images with no errors, but then, when I try to flash with “sudo bash flashcmd.txt”, I have the previous “Unsupported Platform 0xfff” message.
I can also create the fuseblob with noburn option for odmsign.sh without problems.
The strange thing is that without signing everything was working fine, with the same system images and on the same board.
the HW manufacturer gived us customized “nvflash” and “fastboot.bin” binaries to use for flashing the custom board.
I tried with the original NVIDIA ones and I obtain the same error also without signing. So I think that NVIDIA and/or our manufacturer patched in some way those binaries to ignore the boardid, but now I assume that this modification works only in some cases and not when flashing with signed binaries.
"I tried with the original NVIDIA ones and I obtain the same error also without signing.
=> so the issue is not related to secure boot of ‘signing’ the image itself.
"but now I assume that this modification works only in some cases and not when flashing with signed binaries.
=> when you are using unsigned version of fastboot from this HW manufacturer, did it flash and boot up fine? If that’s the case, the ‘fix’ or proper adaptation was already there. And then you used the same fastboot to be signed using the keyfile generated and option of --no-flash, correct?
Again, as Jerry put it,
The error of 'Unsupported Platform 0xffff" occurs due to board ID checking fails. Jetson TK1 platform adaptation and porting guide covers a way to avoid board ID checking.
(…/nvtboot/platform/nvtboot_platform_discovery.c)
In general, your fuseblob is generated OK and image signing operation itself is also correct. Are you OK to display your fuse content via sudo ./tegrafuse.sh from your board?
“so the issue is not related to secure boot of ‘signing’ the image itself.”
Right, it seems that the issue is not related to the image signing itself, but in the flashing procedure of signed images.
“when you are using unsigned version of fastboot from this HW manufacturer, did it flash and boot up fine?”
With the unsigned version of fastboot the flashing and booting is ok, so I suppose the problem is not in the “fastboot” but in the “nvflash” binary.
“And then you used the same fastboot to be signed using the keyfile generated and option of --no-flash, correct?”
When I enable signing, I think it is used the same fastboot, but signed (“fastboot_signed.bin” is created). With the option --no-flash the procedure only creates the signed binaries, the error appears when I try to flash the system.
“(…/nvtboot/platform/nvtboot_platform_discovery.c)”
Where I can find the “nvtboot” (nvtboot_platform_discovery.c) sources? It seems that those sources are not included in the R21.5 release.
“Are you OK to display your fuse content via sudo ./tegrafuse.sh from your board?”
Without starting the board I can’t execute the sudo ./tegrafuse.sh command.
i’ve going through your failure message and you got failure at “fastboot_signed.bin”
we should check if you skip boardid checking correctly.
you could also refer to Jetson-Tk1 porting guide from R21.5 development guide->[Downloads]->[Platform Adaptation and Bring-Up Guide].
BTW, we had verified and confirmed that fuse and burning fused is workable on Jetson-TK1.
there are several boardid checking at early-flashing stage,
since you had your customized board, could you also ask your HW vendor to double confirm you had skip boardid checking correctly at fastboot?
thanks
IvanGolob,
We are checking nvflash and see if board ID checking exists somewhere but please have your hardware vendor to check his fastboot and other scripts as Jerry put it.
The problem seems to be resolved, now I can flash the signed binaries.
At the end then solution is simple… I have to use the original nVidia R21.5 “nvflash” binary (and not the HW vendor one) with the uncommented BOARDID in “.conf” file (the HW vendor “nvflash” always returned an error if BOARDID was uncommented).