Jetson Xavier NX and TX2 (initrd) NVMe flashing Jetpack 4.6

Hi everyone,

in the past, when I booted from the SSD by just modifying extlinux (and on older Jetpack initrd for necessary drivers) or I booted internally and bind-mnt some of our larger dirs to the SSD: Since Jetapck now supports flashing and/or booting from an SSD, potentially with initrd support, we’d like to use that approach.

Here are my questions:

1.) Flashing with the initrd at some parts in the docs claim it is available for TX2 onwards at other location it claims it is just for Xavier based devices. Which one is true?

2.) Flashing with initrd states you need the secure boot package. Is it possible to use the non-fused keys used for standard internal booting? So we do not force/burn a key? This is because we are in Dev-Mode and not production mode.

3.) The other option is to just keep all bootloader/dtb stuff on the internal/SD memory and just boot the rootfs/APP partition on the SSD (manual SSD booting). As far as I can tell TX2 and Xavier both support this approach by changing the boot order in the bootloader. Am I correct?

4.) The OTA updates also flash the device-tree or bootloader from a live system. Do they have access to these keys? Since we use other boards, we have to use our own device-trees and would like to flash them in an OTA way if possible.

Thanks in advance,

Markus

1.) Flashing with the initrd at some parts in the docs claim it is available for TX2 onwards at other location it claims it is just for Xavier based devices. Which one is true?

(edit: please see next comment)

2.) Flashing with initrd states you need the secure boot package. Is it possible to use the non-fused keys used for standard internal booting? So we do not force/burn a key? This is because we are in Dev-Mode and not production mode.

We just use the tool from security boot package. Even a non-fused board is able to run it.

3.) The other option is to just keep all bootloader/dtb stuff on the internal/SD memory and just boot the rootfs/APP partition on the SSD (manual SSD booting). As far as I can tell TX2 and Xavier both support this approach by changing the boot order in the bootloader. Am I correct?

Yes, both TX2 and Xavier support this. But tx2 is doing this in uboot while Xavier is cboot.

4.) The OTA updates also flash the device-tree or bootloader from a live system. Do they have access to these keys? Since we use other boards, we have to use our own device-trees and would like to flash them in an OTA way if possible.

Sorry, I am not sure the “keys” here. What key is that?

Correct my comment here. It should support both the TX2 and Xavier series. The developer guide is wrong.

Thanks. That cleared up a lot.

@4 As we do not want to fuse or use keys at all I think you can disregard the comment about keys, but as far as I know the OTA updates did not contain signed images (until now)?

The more important questions if I do an OTA update (custom package or official), will the correct partitions on NVMe be flashed/updated? I guess so. But just to confirm.

An addon if we also want to deploy our own dtb package, I could just clone NVIDIAs package, add my changes and change the package name and conflict/replace the official one, but is there an official guide for flashing those from live/OTA or should I just look in the pre/post and triggers as a guide?

The topic is a little out of rail because the original one is “initrd flash”, but now you are asking me the OTA update. They are not directly related.

if I do an OTA update (custom package or official), will the correct partitions on NVMe be flashed/updated?

It is hard to answer because you said “custom package” here. Which means it is you to implement it, in which I can not know the detail.

If you are asking me about the official one, then the answer is no. You can just think of the official update as another “jetpack”. A jetpack does not know you install something to the NVMe. Even worse, it may fallback your change to the default one. Which means it may boot from the emmc again. Also, default package does not know you have NVMe there, and it won’t change anything on your NVMe.

This may happen to any customization, no limited to “nvme boot”. A most common case is the custom board, which has custom dtb, installing the official package will install the devkit dtb again, and your board will not work fine again.

If you want to customize the debian package, you can refer to

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/getting_started.html#wwpID0E0FF0HA

Thanks for the reply. It is not completely off-topic as the DEB/APT-OTA mechanism is still enabled when using initrd flash, or not? Maybe I missed that part in the doc. It would mean, even for official boards that I would have to hold the boot related packages there too if I choose the new official NVMe initrd boot/flash flow as otherwise I could screw a remote running system when upgrading packages. OTA works at least with internal eMMC and SDMMC I thought this might have been implemented, but I did not expect it to be.

It is definitely possible to implement such a feature, which I at least lack time for, as just some of those tools needs that partition layout info, which can be stored in rootfs or in the initrd or somewhere else or parse the config from some already flashed environment. Since it is possible my assumption could have been wrong and thus I asked whether or not such a feature already exists.

So thanks for clearing it up. :)

When using the old/normal internal storage boot flow and APT/OTA mechanism I already could just overwrite official packages (conflict, replace and provide the respective official packages), but since the OTA packages do not work even for the official boards with the NVMe initrd boot, I do not need to bother and try.

Solved for me. I will mark your initial answer as solution. Unless you have something to add.