Unable to burn fuses (dev kit) / no more output (serial/hdmi) / bricked?

Do you have -p in the odmfuse command? SecurityMode should be present with -p.

ah, ok, I added the -p flag this time and xml file looks good.

Proceeded to burn fuse but Boot Rom communication failed error: fuse-burn.log (2.2 KB)
(no serial output)

We will check why the error happens.
For information, is the new one also Xavier 16GB?

Thanks, current and new device are both 32GB models.

It looks like the board has been fused already.

[ 0.0358 ] BR_CID: 0xd80219116459e587100000000fff0240

This is result from retrieving CID. The first nibble of d tells us this board is PKC + SBK fused board.

For a clean board, the first nibble is expected to be 8.

Hi Dane,

Yes, if you recall we burned the fuses a while back, the start of when we had issues.
I’m guessing editing the file to remove the keys might of been the issue.

Before I burn again, I just want to clarify the exact steps, (cos these boards ain’t cheap and getting them is difficult / timely during this lockdown). To confirm the current device is broken / no longer useable? If so I just want to make sure the steps are exact, explicit and working before attempting on a new device.

Are the previous steps I mentioned correct?, do I still need to hand edit the xml file? apply the patch(s)?

Also I want to test the watchdog feature, the docs says the bit for sw_reserved is 5, if I include -r 0x05 does that look correct? or should it be -r 0x5.

I just want to make sure cos I assume once I use the -p flag I can’t make any more changes.

Many Thanks

So fuse-burn.log is from the Xavier that has been fused, and can be flashed, but cannot cold boot. Is my understanding correct?

For fusing enable_watchdog in sw_reserved, it should be -r 0x20. The Xavier has been fused with

-j -i 0x19 -c PKC -k pkc.pem -S sbk.txt --KEK2 kek2.txt

But you would like it to be fused like:

-j -i 0x19 -c PKC -p -k pkc.pem -S sbk.txt --KEK2 kek2.txt -r 0x20

Please check if this is correct. We would like to check if this can be done on the already-fused Xavier, before you run it on a clean Xavier.

So fuse-burn.log is from the Xavier that has been fused, and can be flashed, but cannot cold boot. Is my understanding correct?


To confirm, the official documentation is wrong?
docs - it shows as ‘5’, would like to test the watchdog functionality, it may already be enabled but just want to check with you before we enable -p, cos I assume this will prevent future changes?

@DaneLLL if it helps, on the new device, the watchdog is enabled by default, I’m guessing we don’t need to amend fuses for enable_watchdog.

What does -r 0x20 represent?

The description in README_secureboot.txt:

  -r 0xXX       Sets sw_reserved=0xXX. The name of this fuse field is confusing,
                but the meaning is as follows:

                bit[7-6] reserved
                bit[5  ] enable_watchdog
                bit[4  ] enable_charger_detect
                bit[3  ] ignore_dev_sel_straps - Ignore "boot strap"
                bit[2-0] sec_boot_dev_sel - 0:eMMC 2:SPI

Let me confirm if -r 0x20 is required for enabling watchdog. Will update.

Hi @DaneLLL

We can ignore watchdog for now, I didn’t think it would take this long. Let’s just carry on with getting this flash process to work.


Two watchdog timers listed in document are enabled by default. We are checking what the watchdog is in sw_reserved fuse.

For fusing odm_production_mode on PKC-and-SBK-fused device, we are still working on a solution. Will update once there is a solution.

We have verified the fuse process on r32.4.2. Host PC is Ubuntu 16.04. Target device is Xavier 32 GB.

  1. Set Xavier to recovery mode
  2. On host, execute fuse programming
$ sudo BOARDID=2888 FAB=400 BOARDSKU=0004 BOARDREV=K.0 ./odmfuse.sh --noburn -j -i 0x19 -c PKC -p -k rsa_priv.pem -S ./sbk.key --KEK2 ./kek2.key jetson-xavier
$ sudo tar xpf fuseblob.tbz2
$ cd bootloader
$ cat odmfuse_pkc.xml // check if required fuses are included
$ sudo ./fusecmd.sh
$ cd ../
  1. Set Xavier to recovery mode
  2. On host, execute flashing image
$ sudo BOARDID=2888 FAB=400 BOARDSKU=0004 BOARDREV=K.0 ./flash.sh --no-flash -u rsa_priv.pem -v ./sbk.key jetson-xavier mmcblk0p1
$ cd bootloader
$ sudo bash ./flashcmd.txt

Hi @DaneLLL

failed at the fusecmd.sh step:

fuse2.log (1.8 KB)

Hi @yusufftran
Do you execute on new Xavier 32GB? The steps are for Xavier 32GB which is not fused yet.

steps were on the old xavier, was hoping to get that working as we didn’t want to risk bricking again. We are using the new jetson for builds / compiling, if that bricks we’re in big trouble.


We think it should work by programming production mode fuse(-p option). Still working on a solution for it.

I’ve tested the process on the new devkit and no errors so far.
fuse-real.log (26.3 KB) fuse-test.log (25.3 KB)
(test was with the keys removed from odmfuse file, real was without modification and keys in place)

I’ll test flashing…


Some good news, I was able to flash successfully (on the new devkit) and boot successfully.

serial.log (37.6 KB) flash-secure.log (433.9 KB)

I’ll reply to the email thread about the bricked jetson, thanks for your help.