Upgrading your Jetson Xavier NX from JetPack 4 to JetPack 5 is not difficult. However, there are a few things to understand. As always, make backups and don’t put your datas at risk! Looky here:
Background – Bootloader
Let’s take a look at the boot flow sequence on the Xavier NX under JetPack 5 (from Jetson Xavier NX Jetson AGX Xavier Boot Flow) :
Boot Sequence Overview
The Tegra Xavier System on a Chip (SoC) contains a set of embedded processors to help with system tasks. One of these processors is the Boot and Power Management Processor. This is BPMP in the above diagram. The BPMP is a dedicated Dual ARM Cortex-R5F core subsystem. The BPMP handles preliminary booting of the system.
Let’s go over a cold boot of the system. When powering on, system level hardware executes the power-up sequence. Then control passes to the BootROM. The BootROM begins executing and configures the on-chip I/O controllers. The controllers can then access the secondary boot device.
From the secondary boot device, the BootROM fetches the Boot Configuration Table (BCT) and loads Microboot (MB1 in the diagram).
If all goes well, execution passes to MB1. MB1 then loads TegraBoot (Tboot). There are security checks and such, we’ll quietly ignore that bit. Let’s also ignore redundancy too. Tis not simple, and requires a deep understanding of the system architecture. Let’s continue …
In turn, Tboot loads the Unified Extensible Firmware Interface (UEFI) on to the CPU. Tboot also loads system firmware to support on chip processors. Once UEFI loads, Tboot tells the CPU to start executing. UEFI then starts loading the Linux kernel.
The bootloader is sort of a mini system in and of itself. There are several bare minimum device drivers and configuration files that contain information on how to load the system. Plus, the bootloader is bringing in different programs to load more data.
This explains why all of the Linux kernel device drivers are not available during boot time. Early on, the bootloader has not begun loading the kernel drivers. Instead the bootloader tries to keep the number of device drivers to a minimum. Just enough to get to the next loading stage.
This also explains why the bootloader and the kernel may have different device drivers for the same device.
The above description is for a cold boot. The BPMP handles flashing using Tboot, which we won’t be discussing here.
Where is the Bootloader Stored?
When the Jetson first starts up, it jumps into the BootROM. The BootROM starts loading MB1, MB1 loads Tboot, Tboot loads UEFI and so on. But where are these things loading from? They aren’t loading from ROM memory onboard the processor. Above we reference “the secondary boot device”.
As you suspect, the “the secondary boot device” is flash memory. The location and type of flash memory depends on the Jetson model. For the Jetson Xavier NX Developer Kit, the flash memory is a small chip on the Jetson module. We refer to this as QSPI-NOR. QSPI is Quad Serial Peripheral Interface, an interface for communicating with flash memory. NOR is the the type of flash memory. You may also hear it referred to as QSPI.
Another type of flash memory you may have heard of on Jetson is eMMC. When there is eMMC on the Jetson module (as in the Xavier NX production module), the bootloader information is there. The bootloader occupies several partitions on the eMMC module.
Why QSPI-NOR?
The Xavier NX Developer Kit has a SD card, a type of flash memory itself. Why does it need QSPI-NOR memory? Early on in the boot process, the machine must “know” exactly where everything is. There are no drivers to access a peripheral like a SD card drive very early on. You don’t even have access to external memory chips until you configure the chip I/O lines.
That’s where the QSPI memory comes in. The BootROM configures the I/O lines so that the BPMP can access external memory. Part of that external memory is QSPI, which contains several different partitions. The different partitions hold a wide variety of data and programs for use during the boot process.
This is also why you have to flash the eMMC on a production module even if you are “booting” from a NVMe SSD or USB drive. Almost all systems boot in a similar sequence (After all, the UEFI design replaces the BIOS on a PC). However, this is usually hidden from end users. Or at least enough so that people believe that they are “booting” from a drive.
In summary, the boot content, including drivers and boot loader, exist in QSPI memory for Jetson SD card module models, and in separate partitions of eMMC for Jetson eMMC models.
New Bootloader?
What’s with all the questions? Yes, the reason that we have to flash the QSPI is that the bootloader changes between versions. From CBoot in Jetson Pack 4.X to UEFI in JetPack 5.X.
This also means that you can’t take a running JetPack 4.X card and run it in a JetPack 5.X system that has the update to the QSPI. Or vice versa.
To run a JetPack 4.X system, you need a JetPack 4.X bootloader. A JetPack 5.X system needs a 5.X bootloader.
There have been several different bootloaders over the years. It is most likely to happen on changes to Ubuntu releases. In this case, Ubuntu 18.04 to Ubuntu 20.04. Jetson Linux is an Ubuntu variant.
The post Upgrade Jetson Xavier NX to JetPack 5 appeared first on JetsonHacks.