Concerns about fuse burning on TX2

I added the -p flag so the odm_production_mode should be set? correct? You can check the output of the fuse burning steps above. Here is the odmfuse_pkc.xml file again

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="SecureBootKey" size="16" value="0x<32 valid hex numbers which match the input>" />
<fuse name="Kek2" size="16" value="<32 valid hex numbers which match my input>" />
<fuse name="PublicKeyHash" size="32" value="0x<valid hash>" />
<fuse name="BootSecurityInfo" size="4" value="0x6" />
<fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse> shows suprising output:

Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.

The command I use is

/ -i 0x18 --auth NS -k ../.rsa_priv/rsa_pub.key -S ../.rsa_priv/sbk.key jetson-tx2-4GB

hello nvidiadude,

you’ll need to include board info, such as BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 while using these commands to generate a fuse blob.
in the other words, these three, (1) board info, (2) --auth options, and (3) --noburn options should use together to create a fuseblob locally.

that xml file, odmfuse_pkc.xml looks correct, are you able to boot into the ubuntu desktop?

Hello, no I cannot boot into the desktop,

Yes, I exported those variables when I ran the command, check at my comment : Concerns about fuse burning on TX2 - #6 by nvidiadude

I reread and realized the fuse burning output above and realized there were issues burning fuses. Feel a bit dumb now… the line says this:

[   2.4339 ] tegrarcm_v2 --oem burnfuses blow_fuse_data.bin
[   2.4372 ] Applet version 01.00.0000
[   2.5369 ] 0000000000000001: Oem commands are not supported
[   2.5380 ] Fuse burning failed

My output was attached in this comment:

Now I cannot burn fuses (so something happened but not what we wanted, If I run the script, the get_fuse_level function is getting “e” for $flval (so my board is in PKC)

However, if I try to flash with just PKC set I cannot…
Initial command

sudo BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 ./ --no-flash -u ../.rsa_priv/rsa_priv.pem jetson-tx2-4GB mmcblk0p1


3.8.10 (default, Jun  2 2021, 10:49:15) 
[GCC 9.4.0]
Version info.
sys.version_info(major=3, minor=8, micro=10, releaselevel='final', serial=0)
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   0.0069 ] Parsing partition layout
[   0.0080 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0091 ] 
[   0.0092 ] Boot Rom communication
[   0.0098 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_1_signed.rcm
[   0.0105 ] BR_CID: 0xe1801001645966470000000013040080
[   0.2351 ] Bootrom returned error 10
[   0.3769 ] Boot Rom communication failed
[   0.3769 ] 
Error: Return value 10
Command tegrarcm_v2 --chip 0x18 0 --rcm rcm_1_signed.rcm

This seems to be a big issue, has this fuse burning and flashing been thoroughly tested on Jetson tx2 4GB?
Seems prone to alot of errors.

hello nvidiadude,

may I know what’s your very first commands to fuse burn the Jetson TX2?

This thread contains all the commands I have been using for this process.
my original fuse burning command is :

udo BOARDID=3489 BOARDSKU=0888 FAB=300 BOARDREV=N.0 ./ --noburn -i 0x18 --auth NS -p -k ../.rsa_priv/rsa_priv.pem -S ../.rsa_priv/sbk.key --KEK2 ../.rsa_priv/kek2.txt jetson-tx2-4GB

As it is shown here and in the next several comments : Concerns about fuse burning on TX2 - #6 by nvidiadude

Can I get an answer on my previous question as well?

This seems to be a big issue, has this fuse burning and flashing been thoroughly tested on Jetson tx2 4GB? Seems prone to alot of errors.

hello nvidiadude,

yes, it has validated. it was fused PKC, SBK on Jetson-TX2-4GB board.

Ok, I can try this process on one more SOM, but I want it to work correctly.
I will be testing with the l4t 32.6.1 release a similar command.
I am not sure how I can recover the current SOM.

hello nvidiadude,

could you please try nvmassflashgen script before you fused another TX2-4GB,
you should execute in the offline method. here’s sample commands for your reference,
for example,
BOARDID=3489 BOARDSKU=0888 FAB=300 FUSELEVEL=fuselevel_production ./ -u rsa_priv.pem -v sbk.key jetson-tx2-devkit-4gb mmcblk0p1

this will generate a mass-flash image tarball, once complete. i.e. mfi_jetson-tx2-devkit-4gb_encrypt_signed.tbz2
you should extract this tbz2 file, and execute to flash the target.

hello nvidiadude,

if you’re going to fused a device with PKC+SBK. please also program odm_production_mode (-p) all together.

So, I use a command like this and can flash and boot!
But, I run the same command with ROOTFS_ENC=1 set, It fails.

Making system_boot.img... 
	populating bootfs from /home/mharr418/Documents/enc_rootfs_inv/unpack20/Linux_for_Tegra/rootfs/boot ... done.
	populating /extlinux/extlinux.conf ... done.
	Sync'ing system_boot.img ... done.
	Converting RAW image to Sparse image... done.
system_boot.img built successfully. 
Making system_root_encrypted.img... 
ERROR: build_enc_root_fsimg: ECID is null .

Is this due to the failed fuse burning? Why then is setting the SBK key when not using ROOTFS_ENC working?

Here is the command with ROOTFS_ENC=1. (when I remove setting this global in my command, then the script works)

sudo ROOTFS_ENC=1 BOARDID=3489 BOARDSKU=0888 FAB=300 FUSELEVEL=fuselevel_production ./ -u ../.rsa_priv/rsa_priv.pem -v ../.rsa_priv/sbk.key -i ../.rsa_priv/sym2.key jetson-tx2-4GB mmcblk0p1

NOTE: I tried this with the 32.5.1 and 32.6.1, same result with both.

EDIT: I also tried setting BOARDREV=N.0 as well… no change in results

hello nvidiadude,

had you already complete the layout of an Encrypted Disk implementation? i.e. APP_ENC

I am not sure support with ROOTFS_ENC options.
as developer guide Disk Encryption mentioned, that’s sample commands use

for your reference,
please also check these two similar topics for disk encryption.
Secure Boot on Jetson Xavier AGX - #29 by JerryChang
Black Screen after enable SecureBOOT and disk encryption - #9 by JerryChang

Hello, I have checked these pages and tried checking my APP and APP_ENC sizes.
I do not think they are an issue

for APP

rwxr-xr-x 1 root root 47084364 Aug 25 16:14 bootloader/system_boot.img
<partition name="APP" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 104857600 </size>


5309511112 Aug 25 16:15 bootloader/system_root_encrypted.img
<partition name="APP_ENC" type="data" encrypted="true">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 14927527936 </size>

I am about ready to move onto the new SOM to test, cannot see any issues here and I think it is something in the fuse burning that is causing all these errors

hello nvidiadude,

let’s have summarization here and please check I understand all your tests correctly.

  1. when doing offline approach, you’ll need to have to specify (a) board info, (b) --noburn options, (c) --auth fused-types to the command-line.
  2. there’s odmfuse_pkc.xml to review all fuse programming values.
  3. you knew you should burn PKC, SBK, odm_production_mode…etc at the first time.
  4. there’s to create eks.img, you should update eks partition to update that binary.

according to above, you’ve confirm your device has SBKPKC enabled, and now you’re able to boot-up.

  1. True, I am doing this to test and check the xml first
  2. odmfuse_pkc.xml is checked and looks good, can see in my previous comments
  3. I set these :
-p -k ../.rsa_priv/rsa_priv.pem -S ../.rsa_priv/sbk.key
  1. I generate eks.img and put it in the bootloader folder: command :
./ -kek2_key .rsa_priv/kek2.txt -fv fv_ekb \
-in_sym_key .rsa_priv/sym.key  \
-in_sym_key2 .rsa_priv/sym2.key \
-out eks.img

fv_ekb is : bad66eb4484983684b992fe54a648bb8

Here is one thing that worries me,
if I set --user_key on, I get

[0003.206] I> Validate kernel ...
[0003.209] I> T18x: Authenticate kernel (bin_type 24), max size 0x4000000
[0003.216] I> cboot: Info: Handle RSA_SBK as RSA.[0003.222] I> Checking boot.img header magic ... [0003.226] E> Invalid header magic
[0003.229] E> Storage boot failed, err: 724238360
[0003.233] E> A/B loader failure

But when I do not set user_key in the flash command (zero user key is used), there is no issue.
This is after I set it in gen_ekb and also use the correct format (0x1234567… 0x…) in the flashing command,

Remember, the final goal is also to have the rootfs encrypted, ROOTFS_ENC=1
Booting with PKCSBK and odm_production mode is good, but if I add ROOTFS_ENC=1 to my command,
I get this on my screen :

Here we go, using L4t 32.6.1 I have everything working here.

My changes to 32.6.1 to get a working flash:

  1. Compile a new kernel image, with the new cipher settings added to the config:
    Concerns about fuse burning on TX2 - #14 by nvidiadude
    replace the one in kernel folder with my new kernel Image file

  2. I will now always set FUSELEVEL=fuselevel_production since we had issue reading this before, but I still want to read ECID from the board so I will go to and comment these lines out:

#fuselevel is read wrong currently, will test on future boards
#if [ "${fuselevel}" = "" ]; then
get_fuse_level fuselevel hwchipid bootauth;
	# fuselevel_unknown or empty will be handled as fuselevel_production
if [ "${fuselevel}" = "fuselevel_unknown" ] || [ "${fuselevel}" = "" ]; then
echo $fuselevel
echo "${ECID}"
	# can not "--skipuid" when function get_fuse_level is skipped.

Other than this, the intended process on 32.6.1 works well. I will be using it on my TX2.

Thank you for the help

hello nvidiadude,

you’ll need to create eks.img to enable disk encryption on a fused TX2 platform.
there’s script file, it’ll use all zeros run for generating eks.img.
for example,

if necessary, you’ll need to replace those keys and creating eks.img. after that, please overwrite the generate file with Linux_for_Tegra/bootloader/eks.img.
because partition update is disabled by fused device. you need to update the eks partition by full flash the target.
for example,
$ sudo ROOTFS_ENC=1 ./ -u pkc.key -v sbk.key jetson-tx2 mmcblk0p1

once system boot-up, please enter mount command to check your file system.
there’ll be crypt keywords if the process is complete.
for example,

$ mount
/dev/mapper/crypt_root on / type ext4 (rw,relatime,data=ordered)

Correct @JerryChang, my comment above are only parts that I changed, I followed the expected way of burning fuses, eks.img generation… etc.

I hope someone can be able to read through this thread and understand my whole process.
Go back here to see eks.img generation:

hello nvidiadude,

we had verified disk encryption with device fused SBKPKC and adding KEK2.
so, how about running the, and replace KEK2 as yours to create eks.img.