Flashing Xavier NX after SBKPKC fusing fails during GPT writing

Hi Jerry,

Sure, can do. Here is the dmesg -wT output. I powered on the device just before running the ./flash.sh command.

[Tue Feb  8 18:01:39 2022] usb 1-4: new high-speed USB device number 27 using xhci_hcd
[Tue Feb  8 18:01:40 2022] usb 1-4: New USB device found, idVendor=0955, idProduct=7e19, bcdDevice= 1.02
[Tue Feb  8 18:01:40 2022] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Tue Feb  8 18:01:40 2022] usb 1-4: Product: APX
[Tue Feb  8 18:01:40 2022] usb 1-4: Manufacturer: NVIDIA Corp.
[Tue Feb  8 18:01:51 2022] usb 1-4: USB disconnect, device number 27
[Tue Feb  8 18:01:52 2022] usb 1-4: new high-speed USB device number 28 using xhci_hcd
[Tue Feb  8 18:01:52 2022] usb 1-4: New USB device found, idVendor=0955, idProduct=7e19, bcdDevice= 1.02
[Tue Feb  8 18:01:52 2022] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Tue Feb  8 18:01:52 2022] usb 1-4: Product: APX
[Tue Feb  8 18:01:52 2022] usb 1-4: Manufacturer: NVIDIA Corp.
[Tue Feb  8 18:02:34 2022] usb 1-4: USB disconnect, device number 28
[Tue Feb  8 18:02:34 2022] usb 1-4: new high-speed USB device number 29 using xhci_hcd
[Tue Feb  8 18:02:34 2022] usb 1-4: New USB device found, idVendor=0955, idProduct=7e19, bcdDevice= 1.02
[Tue Feb  8 18:02:34 2022] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Tue Feb  8 18:02:34 2022] usb 1-4: Product: APX
[Tue Feb  8 18:02:34 2022] usb 1-4: Manufacturer: NVIDIA Corp.

hello jmattsson,

that’s logs from host machine,
is it possible to gather the complete logs from target for reference?
thanks

Hello Jerry,

Below are timestamped logs for:

  • dmesg
  • flash.sh
  • Xavier debug uart

Timestamps in dmesg are the kernel’s timestamps.
Timestamps in flash.sh output correspond to the last character on the line, with nanosecond precision.
Timestamps from the Xavier correspond to the first character on the line, with microsecond precision.

All timestamps are taken on the same host, so it should all line up for you.

I had to put the logs on dropbox since they were too large to paste in here.

Btw, the offer is still there for us to send you one of the boards (including keys) if you wish to be able to debug directly on them.

hello jmattsson,

there’re more details in xavier.log, and it looks like this device is detecting SDMMC as boot device. this is incorrect. since QSPI is the default boot device for Xavier NX board.

is it possible to flash the target without passing key?
furthermore, please revert the ODMDATA back to 0xB8190000 for making tegra wdt to be enabled.

Hi Jerry,

No, it is not possible to flash without passing key. It fails much earlier, as it isn’t able to boot unsigned rcm.
I’ve now reverted ODMDATA.

In case you wanted/needed it, here is a set of logs from an attempted flash after reverting ODMDATA.

hello jmattsson,

since QSPI is the default boot device for Xavier NX board.
could you please modify below Cboot sources to ignore the tegrabl_soc_get_bootdev() and making boot device as QSPI for confirmation,
for example,

tegrabl_error_t config_storage(struct tegrabl_device_config_params *device_config,
                                                           struct tegrabl_device *devices)
{
..
        static tegrabl_storage_type_t mb1_bct_to_blockdev_type[TEGRABL_BOOT_DEV_MAX] = {
                 ...
                [TEGRABL_BOOT_DEV_QSPI] = TEGRABL_STORAGE_QSPI_FLASH,
        ...
        err = init_storage_device(device_config, boot_device, (uint8_t)boot_dev_instance);

the sources is available via Cboot Sources T194.

Hi Jerry,

I built a customised CBoot where I hard-coded QSPI as the boot device, and replaced the original cboot_t194.bin with it. This had no impact whatsoever - same error as before when attempting to flash. As far as I understand however, the error happens while running nvtboot_recovery_cpu_t194.bin, not cboot_t194.bin.

I also tried replacing nvtboot_recovery_cpu_t194.bin, but then the flashing failed as the device did not do the recovery things and didn’t expose the expected USB device.

I had a look to see whether the CBoot source has a different build mode to generate the recovery version, but didn’t find anything like that. To actually test your recommendation I would need either the nvtboot_recovery_cpu_t194 sources, or a pre-built binary of the modified version from you. Let me know what I should try next, thanks.

hello jmattsson,

when FUSE_RESERVED_SW[3] has burned, it will ignore boot device selection through straps, and uses fuse (0x0=eMMC) to identify the boot device.
however, this is wrong for Xavier-NX platforms since QSPI is the default boot device for all NX boards.
you may access Jetson AGX Xavier Series Fuse Programming Application Note, please check [Table 1. Fuse Names and Descriptions] and also [Boot Device Selection] session for details,

since fuse burning is non-reversible,
please contact the NVIDIA Customer Care team and submit the RMA process.
thanks

Thanks Jerry,

I followed the Jetson Xavier NX Fuse Specification (DA-09876-001_v1.0) in that regard, which states

Boot Device Selection

Jetson Xavier NX uses eMMC for boot. These fuses should remain at their default (0x0 = eMMC).

To follow up further - I have now fused my remaining board, without the -r option and I can confirm I can still flash the board, and the encryption is working. It does indeed look like it was the boot device selection that broke things.

Thanks for your assistance, Jerry.

hello jmattsson,

let’s have another try to burn the fuse again with the value 0x29 (i.e. due to previous burned to 0x28); this will program the fuse bit from 0x0 (eMMC) as 0x01 (SPI).
it should make the target boot from QSPI instead of eMMC.

please do have a try, looking forward your test results.
thanks

Hi Jerry,

The ODM Production Mode fuse has already been blown, I don’t think further fuse burning is possible?

hello jmattsson,

did you enable odm_lock?
when you begin production and burn the ODM production fuse, secure boot is enabled, JTAG debug is disabled, and all the fuses become inaccessible except Reserved_ODM.
however, Reserved_ODM fuse are programmable until it disabled by the ODM_lock fuse.

Hello Jerry,

Boot device selection is in FUSE_RESERVED_SW though, not ODM_RESERVED. It did try re-burning the boot selection, but it says

Production mode is set, you can't burn any manufacturing fuses now.
Error: check fuse values failed.

which is what I expected would happen. I would have been more concerned if the boot selection wasn’t protected by the production mode fuse :)

hello jmattsson,

okay, thanks for your confirmation.

please note that the boot device selection may broke things, i.e. -r options to flash boot device selection.
we’re reviewing the fuse burning documentation, it should adding some information for Xavier NX platforms.
besides, please contact the NVIDIA Customer Care team and submit the RMA process for your damaged device.
thanks

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.