News

NVIDIA Jetson Orin Nano: adapting the software to product requirements

Abinsula's work on Linux, updates, data protection and manufacturing

The NVIDIA Jetson Orin Nano Developer Kit provides a hardware and software configuration that works out of the box. Using it in a product may require changes: connecting different peripherals, using a custom board, choosing which software to install, or planning specific updates and protections.

At Abinsula, we start from the hardware chosen by the customer and the system requirements. We identify the customizations needed and turn them into software that can be installed and verified. Our work also covers the procedures for preparing further devices with the same configuration and maintaining subsequent versions.

Getting Linux running on the customer's board

The Jetson module plugs into a carrier board, the board that hosts connectors and peripherals. If it differs from the Developer Kit, the software needs to know about the new connections. This is the purpose of BSP customization: the BSP is the package of drivers and configurations that allows Linux to use the hardware.

We examine the board's schematics and specifications to identify the interfaces in use and the components connected. We translate this information into software configurations: we specify which peripherals are present, how they are connected and which signals are needed to initialize them. We also configure or adapt the drivers, the software components that make those peripherals usable.

The NVIDIA boot process goes through several stages. In short, the BootROM, the initial code embedded in the chip, loads the first components; MB1 initializes memory and hardware settings, such as pin functions; MB2 prepares the handover to the next stages; UEFI selects and loads the operating system. Linux then starts drivers, services and the application. We adjust the configuration at the relevant stage: for example, pin settings in MB1 and boot disk selection in UEFI. We then verify on the board that the peripherals work.

The fixes go into the project's sources and configurations. This makes them reproducible in the next software image, the complete package to be installed on the device, without having to apply them manually to every unit.

L4T or Yocto: two approaches to building Linux

We implement both solutions based on NVIDIA Jetson Linux and OpenEmbedded/Yocto distributions. L4T stands for Linux for Tegra: it is the historical name of NVIDIA's Linux software for Tegra processors, the family Orin belongs to. The name is still used to identify the Jetson software base. The choice depends on the components required and on how the customer intends to maintain the system.

With L4T, we keep the Ubuntu base and the NVIDIA components, integrating the product customizations. For example, we can add a driver for a peripheral and configure the application to start automatically, while keeping the NVIDIA libraries and Ubuntu package management. We then prepare an image that includes these changes, ready to be installed on other compatible units.

With Yocto, instead, we define which components to build and include in the distribution. For a headless device, for example, we can create an image with the required drivers, network services and the application, without a desktop. Recipes describe how to build and install each component, pinning its version. Jetson support comes from OE4T/meta-tegra, a project separate from NVIDIA. The result is a dedicated distribution that can be rebuilt from the same definitions.

In both approaches, we keep sources, configurations and build instructions. This way the customer knows what a release contains, can rebuild it and compare it with the next one.

A/B updates with NVIDIA Image-Based OTA and SWUpdate

An update must install the new version while keeping a way to recover. That is why we define the disk layout and the update behavior together. On systems with an NVMe SSD, a solid-state drive connected through a high-speed interface, we also configure Linux to boot from that drive.

With the A/B scheme, we reserve two areas for copies of the operating system. The device runs on the first while the second receives the update. On reboot it tries the new version; if it fails to start, the system can fall back to the working copy. The benefit is fewer on-site interventions after a failed update.

We have implemented two solutions: NVIDIA Image-Based OTA in the L4T path and SWUpdate in Yocto integrations. OTA stands for Over-the-Air and refers to delivering updates over the network. Image-Based OTA is NVIDIA's solution for preparing and applying system images, integrated with the BSP tools. SWUpdate is an installer that lets you define which components to update and how to write them; it can receive packages distributed over the network or provided locally. With both, we prepare the package and the update logic, coordinating them with the A/B slots. The choice depends on the level of control required over installation and on integration with the existing system.

Testing covers updates in both directions, from A to B and from B to A. We also deliberately caused a boot failure to check the automatic fallback to the working copy. After each step, we check which system is actually running and the state of both copies.

However, Linux booting does not prove that the application works. Together with the customer, we need to define which services must respond and which checks authorize confirming the new version. These criteria complete update management according to the product's needs.

Full Disk Encryption: protecting software and data on disk

Full Disk Encryption, or FDE, protects the system's persistent content by encrypting the volumes that hold it. Applications, configurations and data cannot be read without the key, even if the SSD is removed and connected to another computer. We use LUKS and dm-crypt, the Linux components that manage protected volumes and handle encryption during reads and writes. In the Jetson layout, the partitions required for boot remain separate: FDE does not mean every byte on the disk is encrypted.

We define which volumes to encrypt and integrate their unlocking into the boot sequence. We use NVIDIA's OP-TEE-based flow, an environment isolated from Linux that derives the credential needed to open them. The device can therefore boot unattended, while access to the data stays consistent with the key configuration.

We have integrated this mechanism with the two A/B copies and the data area. Updates also go through the encryption layer: after installation, we check that the new system remains encrypted and boots correctly. The areas required for boot are handled separately.

We also verified the switch from a generic installation credential to a device-specific one, checking that the previous one was no longer accepted. Encryption protects data at rest; once the system has opened it, access control and software security are still required.

Secure Boot: protecting the integrity of the boot chain

Encryption protects the content of the disk. Secure Boot addresses a different problem: preventing a replaced or tampered boot component from running as if it were authorized. The device verifies a digital signature before loading the protected software.

At Abinsula, we integrate signing into image preparation and configure the boot firmware to check it. We define which components must be verified and keep the signing keys consistent with those the device recognizes. We apply the same checks to the images contained in updates, so that later versions can continue to boot.

Testing covers both valid and modified images. We verified that UEFI, the firmware that manages the later boot stages, accepts the former and rejects the tampered ones, also checking the fallback to the working copy of the system.

These tests were performed on development hardware. Full protection from the chip's very first instructions also requires a permanent hardware configuration, separate from UEFI verification. This separation allows the software to be tested before the irreversible production steps. Authorized code must still be maintained and updated: a valid signature does not rule out vulnerabilities.

FSKP: managing secure provisioning in production

Provisioning is the initial preparation of the units: installing the software and applying the intended configurations, including security settings. Some of these settings are stored in fuses, elements inside the chip that can be programmed permanently. A mistake at this stage cannot simply be fixed by reinstalling Linux.

Factory Secure Key Provisioning, or FSKP, is NVIDIA's mechanism for transferring the data intended for fuse programming to the device in protected form. An encrypted and authenticated package is prepared in the environment that holds the keys. The factory station receives this package and sends it to the unit through NVIDIA's service mode.

Production stations can therefore carry out programming without receiving in plaintext the cryptographic keys used to protect the package. Abinsula integrates NVIDIA's tools with the product's security configuration, linking package preparation to its application on compatible devices. The advantage is limiting access to cryptographic material and making an already-defined configuration usable on the production line.

The process can be tested before the settings are made permanent: we used FSKP simulation mode to verify that it works on the device without modifying its fuses. This makes it possible to prepare the move to production; final programming then requires the production keys, the required NVIDIA material and validation of the procedure on the relevant hardware profile.

Boot optimization

When the product requires shorter boot times, we optimize the boot sequence to reduce the wait until the application is available. We verify the result on the device, keeping the intended security, update and recovery functions in place.

The release: software and tools for installation and maintenance

The release brings together the software ready to install and the tools needed to update and restore it. It can include sources, configurations and documentation, so that the customer can use the delivered version in production and have what they need to maintain it over time.

Technical references

news