In my attempts to enable secureboot and flash an encrypted rootfs onto the AGX Xavier; fuse burning, ekb img, and flashing were all completed successfully.
However, after rebooting the AGX Xavier, the system does not boot up. Flashing has no failure message and a micro-usb connection outputs nothing to serial.
Is there something wrong with my bring up process? How can I find out why the system is failing to boot?
odmfuseread_output.txt (95.3 KB)
flash_log.txt (1.3 MB)
commands_list.txt (583 Bytes)
hello ivan.liang,
do you have UART logs? we may dig into bootloader messages for details.
please see-also NVIDIA Jetson Xavier - Using the serial console.
I’ve been trying to serial in with dev USB 0 through 3 and using baudrate 115200, I used both screen and minicom. Neither of these serial connections give output or take input.
What is the method to collect the UART logs?
hello ivan.liang,
it usually output UART logs via /dev/ttyUSB3.
if you’re not seeing any logs, it might be the issue you did not fuse a target correctly, which stuck before mb1.
please share the fuse configuration file (i.e. fuses.xml) for double check.
you may obscure those PKC/SBK keys for security concerns.
odmfuseread_output.txt has the fuse reads of the device
fuses.xml.txt (406 Bytes)
hello ivan.liang,
please double check Jetson AGX Xavier Series Fuse Programming Application Note, especially the FUSE_BOOT_SECURITY_INFO.
it’s recommends burning all the fuses you need in a single operation, please programming ODM Production Mode (i.e. fuse with -p option) as well.
for instance, here’s reference discussion thread, Topic 117585, we’ve fused AGX Xavier to burn all fuses in a single operation.
FUSE_BOOT_SECURITY_INFO is burned with 0x6 or [0110], this correlates to RSA 3072bit & SBK enable (is this possibly missing something?)
all fuses have been burnt in one step with the fuses.xml file. (production can be enabled/burnt without fuses specfied?)
hello ivan.liang,
please check you’ve add fuse variables before burning production_mode fuse.
and, let’s narrow down the issue, please try re-flashing Jetpack release image without ROOTFS_ENC at the moment.
reflashed without ROOTFS_ENC
sudo ./flash.sh -u /tmp/rsa_priv.pem -v /tmp/sbk.key -i “/tmp/sym2_t194.key” jetson-agx-xavier-devkit mmcblk0p1
still not booting, and still no serial output
flash_log_unencrypted.txt (1.3 MB)
sudo ./flash.sh -u /tmp/rsa_priv.pem -v /tmp/sbk.key jetson-agx-xavier-devkit mmcblk0p1
also tested, also no serial output
hello ivan.liang,
let’s try enable ODM Production Mode (i.e. fuse with -p option) for verification.
fuse_info.txt (761 Bytes)
fuse read after enabling production mode
after flashing, same symptoms as before
hello ivan.liang,
may I know which Jetpack release version you’re using?
for instance,
there’re default keys within gen_ekb example if you’re using JP-5.1.3 release version.
BTW, please see-also Topic 276872 to enable disk encryption on Xavier with non-zero keys.
noting: the only zero key we are using is for the ‘in_sym_key’
Using the gen_ekb script, we pass a zero in_sym_key, the default fv key, and kek2 & sym2 keys are the same with the output image placed in bootloader/eks_t194.img
Also we have previously successfully encrypted the rootfs before (image and flash all functioning), our current problems come from adding secureboot.
hello ivan.liang,
may I know which Jetpack release version you’re using?
besides, please give a try by using native Jetpack image to flash your target again for verification.
here’s sample pipeline for reference.
$ sudo ./flash.sh -u ~/Xavier-32GB_key/rsa_priv.pem -v ~/Xavier-32GB_key/sbk.key jetson-agx-xavier-devkit mmcblk0p1
Using Jetpack version: R35.4.1
is there a separate ‘native jetpack image’ located elsewhere?
hello ivan.liang,
as mentioned, there’re default keys within gen_ekb example if you’re using Jetpack release version before JP-5.1.3.
would you please moving to the latest release, JetPack 5.1.4/L4T 35.6.0 for verification?
flashing with Jetson_Linux_R35.6.0_aarch64.tbz2
tried flashing with gen_ekb examples & gen_ekb with the fused keys.
Both attempts came with same symptoms as before (non-booting).
hello ivan.liang,
can you obtain the bootloader logs?
to clarify,
if there’s no logs before mb1 stage, it likely you’ve fuse incorrect keys combination to this target.
if you’re seeing bootloader logs, (mb1, mb2, UEFI…etc) it’s likely you’ve incorrect user-key, and system boot stuck due to decryption has failed.