Jump to content

NVIDIA Yocto flashing workflows - initrd-flash and doflash.sh

From RidgeRun Developer Wiki

Follow us on: YouTube Twitter LinkedIn Email Share this page

Share This Page

Preferred Partner Logo 3 Partner Program Banner



initrd vs doflash

NVIDIA Yocto flashing workflows may expose multiple flashing mechanisms depending on the platform and BSP configuration.

The two most common approaches are initrd-flash and doflash.sh.

Understanding the differences between them helps clarify how deployment is performed and which method should be preferred for development and validation workflows.

initrd-flash

The initrd-flash workflow is the recommended flashing mechanism used throughout this guide and is commonly used with modern Jetson platforms and storage configurations.

It works by:

  1. Booting a temporary Linux kernel and initrd on the target device
  2. Using that temporary runtime environment to program storage devices directly

This approach improves deployment flexibility because the flashing operations are executed from the target side after the temporary environment has booted.

This workflow provides:

  • Better flexibility across storage configurations
  • Improved support for NVMe and external storage devices
  • Cleaner partition and deployment handling
  • Better alignment with modern Jetson BSP workflows

The generated flash bundle typically includes the scripts, partition configuration, bootloader assets, and runtime components required by the initrd-flash workflow.

doflash.sh

The doflash.sh workflow is a more traditional flashing mechanism historically used in older Jetson BSP environments.

It typically performs flashing directly from the host system using TegraFlash utilities without booting a temporary runtime environment on the device.

In this model, the host system performs the partition programming and image deployment operations directly over the USB recovery interface.

This workflow may still appear in:

  • BSP debugging workflows
  • Legacy platform support
  • Compatibility oriented deployment flows
  • Internal validation or low-level bring-up procedures

However, it is generally less flexible for modern deployments and advanced storage configurations.

Workflow Comparison

Feature initrd-flash doflash.sh
Recommended for modern platforms Yes Limited
Uses temporary initrd environment Yes No
Better NVMe and external storage support Yes Limited
Flexible partition handling Yes Partial
Modern Jetson workflow alignment Yes Legacy-oriented

Recommended Workflow

For most development and validation scenarios:

  • Use initrd-flash
  • Use the generated Yocto flash bundle directly
  • Keep flashing aligned with the selected MACHINE

This ensures:

  • Reproducible deployment
  • Better compatibility with modern Jetson platforms
  • Cleaner BSP integration
  • Easier debugging and validation workflows

The exact flashing utilities and scripts available may vary slightly depending on the Jetson platform generation, BSP release, and storage configuration used during deployment.

Cookies help us deliver our services. By using our services, you agree to our use of cookies.