Okay, I’ll check but my question is, how is the regular flash working on the same carrier board?
hello Techgeek,
we’ve tested it locally with developer kit.
you may see-also the steps as mentioned by comment #16.
Hi JerryChang,
I manage NX dev kit and did everything from scratch but now facing missing file error.
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash -u /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/rsa_priv.pem -v /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/sbk.key --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
/home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --no-flash -u /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/rsa_priv.pem -v /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/sbk.key --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p -c bootloader/generic/cfg/flash_t234_qspi.xml --showlogs --network usb0 jetson-orin-nano-devkit internal
************************************
* *
* Step 1: Generate flash packages *
* *
************************************
Create folder to store images to flash
Generate image for internal storage devices
Generate images to be flashed
ADDITIONAL_DTB_OVERLAY="" /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/Linux_for_Tegra/flash.sh --no-flash --sign -u "/home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/rsa_priv.pem" -v "/home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/sbk.key" -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal
###############################################################################
# L4T BSP Information:
# R35 , REVISION: 6.1
# User release: 0.0
###############################################################################
ECID is
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: missing cfgfile ().
Usage: sudo ./flash.sh [options] t186ref internal
options:
-c <cfgfile> ---------- Flash partition table config file.
-d <dtbfile> ---------- device tree file.
-f <flashapp> --------- Path to flash application (tegraflash.py)
-h -------------------- print this message.
-i <enc rfs key file>-- key for disk encryption support.
-k <partition id> ----- partition name or number specified in flash.cfg.
-m <mts preboot> ------ MTS preboot such as mts_preboot_si.
-n <nfs args> --------- Static nfs network assignments
<Client IP>:<Server IP>:<Gateway IP>:<Netmask>
-o <odmdata> ---------- ODM data.
-r -------------------- skip building and reuse existing system.img.
-t <tegraboot> -------- tegraboot binary such as nvtboot.bin
-u <PKC key file>------ PKC key used for odm fused board.
-v <SBK key file>------ Secure Boot Key (SBK) key used for ODM fused board.
-w <wb0boot> ---------- warm boot binary such as nvtbootwb0.bin
-x <tegraid> ---------- Tegra CHIPID.
-B <boardid> ---------- BoardId.
-C <cmdline> ---------- Kernel commandline arguments.
WARNING:
Each option in this kernel commandline gets
higher preference over the values set by
flash.sh. In case of NFS booting, this script
adds NFS booting related arguments, if -i option
is omitted.
-F <flasher> ---------- Flash server such as cboot.bin.
-G <file name> -------- Read partition and save image to file.
-I <initrd> ----------- initrd file. Null initrd is default.
-K <kernel> ----------- Kernel image file such as zImage or Image.
-L <bootloader> ------- Bootloader such as cboot.bin or u-boot-dtb.bin.
-M <mts boot> --------- MTS boot file such as mts_si.
-N <nfsroot> ---------- i.e. <my IP addr>:/my/exported/nfs/rootfs.
-R <rootfs dir> ------- Sample rootfs directory.
-S <size> ------------- Rootfs size in bytes. Valid only for internal
rootdev. KiB, MiB, GiB short hands are allowed,
for example, 1GiB means 1024 * 1024 * 1024 bytes.
-T <ext num sectors> ---The number of the sectors of the external storage device.
The default value is 122159104 if this option is not set.
-Z -------------------- Print configurations and then exit.
--no-flash ------------ perform all steps except physically flashing the board.
This will create a system.img.
--external-device------ Generate flash images for external devices
--sparseupdate--------- only flash partitions that have changed. Currently only support SPI flash memory
--no-systemimg -------- Do not create or re-create system.img.
--bup ----------------- Generate bootloader update payload(BUP).
--single-image-bup <part name> Generate specified single image BUP, this must work with --bup.
--bup-type <type> ----- Generate specific type bootloader update payload(BUP), such as bl or kernel.
--multi-spec----------- Enable support for building multi-spec BUP.
--clean-up------------- Clean up BUP buffer when multi-spec is enabled.
--usb-instance <id> --- Specify the USB instance to connect to;
<id> = USB port path (e.g. 3-14).
--no-root-check ------- Typical usage of this script require root permissions.
Pass this option to allow running the script as a
regular user, in which case only specific combinations
of command-line options will be functional.
--uefi-keys <keys_conf> Specify UEFI keys configuration file.
--rcm-boot ------------ Do RCM boot instead of physically flashing the board.
--sign ---------------- Sign images and store them under "bootloader/signed"
directory. The board will not be physically flashed.
--image --------------- Specify the image to be written into board.
--boot-chain-flash <c> Flash only a specific boot chain (ex. "A, "B", "all").
Defaults to "all", inputs are case insensitive.
Not suitable for production.
--boot-chain-select <c> Specify booting chain (ex. "A" or "B") after the board is flashed.
Defaults to "A", inputs are case insensitive.
--pv-crt -------------- The certificate for the key that is used to sign cpu_bootloader
--with-systemimg ------ Generate system images also when using -k option
--pv-enc <enc_key>----- The encryption key that is used to encrypt cpu_bootloader.
--uefi-enc <uefi_enc_key> Key file (0x19: 16-byte; 0x23: 32-byte) to encrypt UEFI payloads
--uda-dir-------------- Directory to store user data that will be encrypted in UDA partition.
--separate-rcmboot-binary ------ Enable use of different binaries for rcmboot and coldboot.
--generic-passphrase -- Use generic passphrase for disk encryption.
--disable-random-iv --- Disable generation of random IV, SALT1, SALT2 and DERSTR.
--read-info ----------- Read and display board related info, fuse info (based on fuse_t234.xml),
and EEPROM content.
--reuse-uuid --------- Reuse uuid which is already generated first time.
--debug -------------- Enable debug mode.
For now, the debug mode will enable saving of unencrypted and unsigned files
for UEFI encryption/signing debugging.
Error: /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/Linux_for_Tegra/bootloader/enc_signed/flash.idx is not found
Error: failed to relocate images to /home/hq-2/nvidia/nvidia_sdk/JP_5.1.5_orin-nx-secure-boot_dev-kit/Linux_for_Tegra/tools/kernel_flash/images
Cleaning up...
hello Techgeek,
let me double check.. is it Jetson Orin Nano SOM + Jetson Xavier NX carrier board?
did you execute sudo ./apply_binaries.sh to setup your rootfs?
you may refer to To Flash the Jetson Developer Kit Operating Software for the steps.
We are using Orin Nano developer kit carrier board with Orin NX SOM and not XAVIER NX carrier board.
Also executed sudo ./apply_binaries.sh before flashing.
hello Techgeek,
the path is different since you’re using JP-5 release version.
it should be.. bootloader/t186ref/cfg/flash_t234_qspi.xml for your QSPI xml file.
please try again.
Hi JerryChang,
We have upgraded to JP 6.2, we encountered some issues while burning fuses related to communication via the USB cable. Please find the attached logs for reference.
nx-secure-boot-failed.log (17.5 KB)
hello Techgeek,
that should not related to Jetpack release version, both JP-5/6 support image flashing onto fused modules.
why don’t you just update the flash command-line (point-to correct xml file path) to test on JP-5 directly?
besides.. is this module ever fused before?
or, you’re still testing with this module (comment #10)? it seems looks a faulty module.
hello Techgeek,
let me re-cap your fuse commands..
$ sudo ./odmfuse.sh --test -X fuse_rsa3k.xml -i 0x23 jetson-orin-nano-devkit-super
could you please share the fuse xml file for checking, you may omit the SBK/PKC keys for sharing.
besides.. there’re online/offline approach to create fuse blob.
you’re able to create fuse blob without connections via offline approach,
in the meanwhile, this --auth option is only needed in offline mode, it’s indicating the current fuse status of the board. there’re three options need to enabled all together for the offline approach, (a) board info, (b) --noburn, (c) --auth.
for instance,
$ sudo FAB=500 BOARDID=3701 BOARDSKU=0000 BOARDREV=H.0 CHIPREV=1 CHIP_SKU=00 FUSELEVEL=fuselevel_production ./odmfuse.sh --noburn --auth NS -i 0x23 -k rsa_priv-3k.pem -S sbk-256.key jetson-agx-orin-devkit
BTW,
as you’re moving to JP-6, please try below two steps approach to have image creation, and then image flashing onto your SBKPKC device.
(1) $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash -u PKC.key -v SBK.key --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
(2) $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only -u PKC.pem -v SBK.key jetson-orin-nano-devkit internal
Hi JerryChan
Ive successfully set up a new Orin NX for secure boot. Attached is the updated fuse.xml file, modified based on your recommendations, along with the log output from running ./odmfuse.sh using the --test flag.
Please verify and let me know the next steps.
new-fused-test-log-jp6.2-orin-nx.txt (97.6 KB)
hello Techgeek,
please beware that, all additional fuse write requests will be blocked after the SecurityMode fuse is burned with a value of 0x1.
you must update the EKS image since you’re using customize OEM_K1, otherwise UEFI will block the booting due to key mismatch.
please refer to developer guide, Tool for EKB Generation for steps.
please re-create eks_t234.img with JP-6.2/r36.4.3 public release sources.
see-also.. $public_sources/r36.4.3/Linux_for_Tegra/source/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh
besides.. you may see-also Topic 341811 regrading to OEM_K1/K2.
Hi JerryChang,
Is it okay if I remove OEM_K1, since I don’t need a custom OEM key right now. If I remove OEM_K1 from the XML, can I then skip the EKB generation step and go ahead?
hello Techgeek,
may I know what’s the actual use-case?
you’ll also update boot_security_info as you’re removing OEM_K1.
please note that..
it does not check/verify the signature if OemKeyValid and SecurityMode are not burned.
Hi JerryChang,
My ultimate goal is to enable UEFI Secure Boot on the Orin NX for production. Since I’m having difficulties implementing a minimal Secure Boot setup, I asked whether it’s acceptable to exclude OEM keys.
hello Techgeek,
please see-also Topic 341916 for the sample steps to enable only UEFI secure boot on Orin Nano DevKit.
you can enable UEFI secure boot without bootloader secure boot (SBKPKC).
even though, we strongly recommended that users enable bootloader secure boot so that the root-of-trust can start from the BootROM. then the attacker can’t change the UEFI image, including the signature.
in short,
it’s okay to exclude OEM key for your use-case.
Hi JerryChang,
Great! I’ve removed the OEM key and updated the XML as shown below.
I then ran odmfuse.sh with the test flag. Could you please review it once before I proceed with the actual fuse burning?
fuse_test_logs_without_OEMKEY_JP62.txt (97.5 KB)
hello Techgeek,
why it’s 2BE9 for your BootSecurityInfo? it should be 1E9 for your PKC (3072-bit RSA) + SBK enabled.
please refer to Jetson Orin Fuse Specification to double check the FUSE_BOOT_SECURITY_INFO_0 for details.
and.. please omit SecurityMode fuse if you will have additional fuses burn.
Hi JerryChang,
I’ll be configuring authentication to SBKPKC, and I believe the correct value should be 0x3E9, not 0x1E9 as mentioned in the documentation.
Breakdown of 0x1E9:
- Binary:
0000 0001 1110 1001 - Bits
[2:0]=001>> RSA-3072 scheme - Bit
[3]=0>> SBK is disabled - Bits
[8:4]=11101(0x1D) >> Incorrect reserved value (expected0x1E) - Bit
[9]=0→ ODM key is not valid
And for 0x3E9:
- Binary:
0000 0011 1110 1001 - Bits
[2:0]=001>> RSA-3072 scheme - Bit
[3]=1>> SBK is enabled - Bits
[8:4]=11110>> Reserved value for0x1E - Bit
[9]=1>> ODM key is valid
Can you please confirm.
hello Techgeek,
umm… you may double check, 0x1E9 did had SBK enabled.
why you need to toggle bit-9 ODM key Valid if you’re going to exclude OEM key?
Hi JeeryChang,
Thanks for your support, we have figure out the resolution.