In the previous article — JetPack, L4T, Ubuntu, Kernel, UEFI: What’s the relationship? — we mapped out the Jetson software stack. Readers asked in our community: now that we have the map, how do these layers actually run when the device boots?

This article answers that question — and not just with architecture diagrams. We walk through a real Jetson Orin UART Boot Log, layer by layer, from the moment you press the power button to the moment Ubuntu appears. The author is a Seeed application engineer and one of the top technical contributors in the Seeed Jetson community. The most common question he sees is “why won’t my Jetson boot?” — this article is his methodology for diagnosing those cases.

After reading this, a thousand-line boot log will no longer feel like random characters. It’ll be a map you can use to quickly locate problems.

If you don’t yet know how to capture the boot log, these two wikis walk you through it:

https://wiki.seeedstudio.com/jetson_debug_guide

https://wiki.seeedstudio.com/get_the_system_log_of_recomputer_j30_and_j40

Jetson From Power-On to Ubuntu: A Real Boot Log Walkthrough

The previous article introduced what JetPack, Jetson Linux / L4T, Ubuntu, Kernel, and UEFI are. But when these components actually run, in what order? After you press Jetson’s power button, why doesn’t it go straight to Ubuntu — why does it pass through BootROM, MB1, MB2, UEFI, Kernel, initrd?

More importantly:

When Jetson won’t boot, how do you use the UART log to tell which step it’s stuck on?

This article doesn’t just show architecture diagrams. We take a real Jetson Orin UART Boot Log and analyze it.

The full boot chain: from power-on to Ubuntu

Before going through the Boot Log step by step, let’s build the overall boot map.

NVIDIA defines this in the Jetson Linux Developer Guide — Boot Architecture. For the Orin series, the main Boot Firmware stages include BootROM, PSCROM, MB1, MB2, and UEFI.

If we extend NVIDIA’s Boot Firmware flow all the way until we reach Ubuntu, we get this more complete chain:

Power On
  -> BootROM / PSCROM
  -> MB1
  -> MB2
  -> BL31 / OP-TEE
  -> UEFI
  -> L4TLauncher
  -> Linux Kernel + DTB + initrd
  -> Find RootFS
  -> NVMe / eMMC / SD
  -> Ubuntu RootFS
  -> systemd
  -> Login / Desktop / Application

We’ll trace this chain through a real Jetson Orin UART boot log.

The goal is more than understanding “how Jetson boots” — it’s a more practical diagnostic skill:

Given a Jetson Boot Log, quickly determine which layer the device reached, and if boot failed, where to focus troubleshooting.

Power-on: Why does the log start with MB1?

The first line of this UART log is:

[0000.066] I> MB1 (version: 1.4.0.4-t234-...)
[0000.071] I> t234-A01-1-Silicon
[0000.075] I> Boot-mode : Coldboot
[0000.082] I> last_boot_error: 0x0

Wait — we said Power On -> BootROM -> MB1. Where’s BootROM? Why does the first line go straight to MB1?

Because BootROM is hard-coded inside the Tegra SoC. By the time power is on, it has already executed BootROM and successfully loaded MB1, and only then does UART start showing MB1’s log.

So:

Once you see MB1, the SoC has at least made it past BootROM to MB1.

That’s the first troubleshooting mindset: don’t just look for Errors — look for “the last stage that successfully completed.”

MB1: Basic hardware initialization

Inside MB1, the system first initializes boot storage:

[0000.296] I> Task: Boot device init
[0000.299] I> Boot_device: QSPI_FLASH instance: 0
[0000.308] I> QSPI Flash: Macronix 64MB
[0000.312] I> QSPI-0l initialized successfully

This shows MB1 can access QSPI Flash. Even when Ubuntu RootFS is on NVMe, Jetson’s early boot firmware still goes through QSPI.

Then MB1 continues with Pinmux, power, and memory init:

[0000.784] I> Task: Pinmux init
[0000.874] I> Task: Pad voltage init
[0000.884] I> Task: Common rail init
[0000.944] I> Task: SDRAM init
[0000.980] I> SDRAM initialized!
[0000.983] I> SDRAM Size in Total 0x100000000

The key line:

[0000.980] I> SDRAM initialized!

Means DRAM is up; MB1’s critical hardware init is essentially done.

If the boot log gets stuck in MB1 and you never see SDRAM initialized!, focus on MB1-BCT, DDR, PMIC, power, and board config — not Ubuntu or Linux Kernel. Because at this point, Linux hasn’t started yet.

MB1 done -> MB2

After basic hardware init, MB1 loads the next stage MB2:

[0001.874] I> Task: Load MB2/Applet/FSKP
[0001.878] I> Loading MB2
[0001.888] I> Binary name: MB2
[0001.912] I> MB2 header integrity check is success
[0001.945] I> MB2 binary integrity check is success
[0001.950] I> Binary MB2 loaded successfully at 0x80000000

Then MB2 takes over:

I> MB2 (version: 0.0.0.0-t234-...)
I> Boot-mode : Coldboot

The chain has moved from MB1 to MB2.

MB2 continues with platform init, and loads SoC firmware like SPE, RCE, DCE, XUSB, PVA, to prepare for UEFI and Linux.

Before Linux Kernel actually starts, Jetson has already completed a huge amount of low-level hardware and firmware initialization.

MB2 done -> UEFI

When MB2 finishes, a clear boundary appears:

I> MB2 finished

Then ARM Trusted Firmware and OP-TEE:

NOTICE: BL31: v2.8
I/TC: OP-TEE version: 4.2
I/TC: Primary CPU switching to normal world boot

Then UEFI starts:

Jetson UEFI firmware
(version 36.4.3-gcid-38968081 ...)

BL31 handles ARM Trusted Firmware; OP-TEE provides the Trusted Execution Environment. You don’t need their internals, but: seeing UEFI logs means MB1, MB2, and the security firmware stages are basically done — the system is about to enter OS boot.

Inside UEFI: Boot problems shift toward “OS handoff”

Continuing:

Jetson System firmware version 36.4.3-gcid-38968081

ESC   to enter Setup.
F11   to enter Boot Manager Menu.
Enter to continue boot.

This means we’ve entered UEFI. BootROM, MB1, MB2 have all succeeded. From here, the troubleshooting focus changes.

If the device can’t get into Linux after UEFI, focus on:

Boot Order
Boot Device
EFI Boot Entry
L4TLauncher
Kernel / DTB / initrd

You can think of this stage as:

Early hardware init
      |
      v
     UEFI
      |
      v
Select and load Linux

Seeing UEFI means most of the low-level boot has succeeded. The next question is “where does Linux boot from, and are the boot files correct?”

L4TLauncher: From UEFI to Linux Kernel

After UEFI, the system starts actually loading Linux:

L4TLauncher: Attempting Direct Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...

L4TLauncher is Jetson UEFI’s default OS Loader. It prepares what Linux needs:

• Kernel — the Linux kernel
• DTB — hardware description
• initrd — temporary early filesystem

The critical lines:

EFI stub: Booting Linux Kernel...
EFI stub: Exiting boot services...

These mean UEFI has finished preparing the Linux boot environment, and is handing control to the Kernel. The boot chain has entered a new phase.

Once you see EFI stub: Booting Linux Kernel..., the Bootloader phase is essentially done. From here on, troubleshooting moves to Kernel, DTB, initrd, and RootFS.

Linux Kernel officially starts

[    0.000000] Booting Linux on physical CPU 0x0000000000
[    0.000000] Linux version 5.15.148-tegra
[    0.000000] Machine model: NVIDIA Jetson Orin NX Engineering Reference Developer Kit Super

Notice the timestamp restarts from 0.000000. That’s because MB1, MB2, UEFI are Bootloader / Firmware stages — we’re now in Linux Kernel’s own runtime.

So when you analyze a UART Boot Log and see:

Linux version ...

You can conclude:

Bootloader phase is done; the system has officially entered Linux Kernel.

From this point on, the log focus shifts to device drivers, DTB, storage, initrd, and RootFS.

Kernel finds RootFS via command line

After Kernel starts, it needs to know where the real Ubuntu RootFS is. You can see this in the kernel command line:

[    0.000000] Kernel command line:
root=PARTUUID=dd2da367-f299-4b4e-b99b-1510fb301f0d
rw rootwait rootfstype=ext4 ...

It tells the Kernel:

The RootFS to mount as / is the partition matching this PARTUUID.

Another important parameter: rootwait. It tells the Kernel to wait for the Root Device if it’s not ready — critical for NVMe and USB SSDs that need controller/driver init first.

If you’ve reached Kernel but can’t find RootFS, focus on storage, drivers, PARTUUID, and filesystem — not UEFI.

initramfs: Temporary environment before the real RootFS

After Kernel starts, it unpacks initramfs:

[    0.165968] Unpacking initramfs...

Then early userspace, running /init:

[    2.540191] Freeing unused kernel memory: 7744K
[    2.540270] Run /init as init process
[    2.567003] Root device found: PARTUUID=dd2da367-f299-4b4e-b99b-1510fb301f0d

The /init here is not Ubuntu’s systemd — it’s the init program running in the initramfs temporary environment. One of its key jobs is to prepare storage and find the real RootFS:

Linux Kernel
    |
    v
initramfs
    |
    v
Run /init
    |
    v
Find Root Device
    |
    v
Switch to Ubuntu RootFS

So if Jetson gets stuck in initramfs / recovery shell, e.g.:

bash-5.2#

It usually means Kernel and early userspace have started; now focus on RootFS, storage, PARTUUID, filesystem. Reaching a shell isn’t always a failure — combine with surrounding log context.

Kernel identifies NVMe and finds RootFS disk

Most Seeed Studio Jetson products put Ubuntu RootFS on NVMe, so the Kernel needs PCIe and NVMe to come up first.

PCIe Link is up:

[    6.639293] tegra194-pcie 14160000.pcie: Link up
[    6.640379] tegra194-pcie 14160000.pcie: Link up

NVMe controller recognized:

[    6.649660] nvme 0004:01:00.0: Adding to iommu group 5
[    6.649851] nvme nvme0: pci function 0004:01:00.0

NVMe disk and partitions enumerated:

[    6.662942] nvme nvme0: 6/0/0 default/read/poll queues
[    6.665906] nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15

This sequence tells you the chain is complete:

PCIe Link Up
    |
    v
NVMe Controller found
    |
    v
Recognized as nvme0
    |
    v
nvme0n1 created
    |
    v
Partitions enumerated

Seeing nvme0n1 means the Kernel has successfully identified this NVMe device. Next, it will mount the real RootFS.

Ubuntu RootFS officially mounted

After NVMe is recognized, the system mounts the real RootFS:

[    7.426780] EXT4-fs (nvme0n1p1): mounted filesystem with ordered data mode.
[    7.433141] Rootfs mounted over PARTUUID=dd2da367-f299-4b4e-b99b-1510fb301f0d
[    7.439898] Switching from initrd to actual rootfs

This shows the system has left initramfs and is now using the real Ubuntu RootFS.

At this point, Kernel, storage, and RootFS mount have all succeeded. The boot chain is about to enter Ubuntu User Space.

This also echoes the previous article’s point: Ubuntu is not the entire Jetson system — it’s the RootFS and user space mounted in the second half of the boot chain.

systemd: Entering Ubuntu User Space

After the RootFS switch, systemd starts:

[    7.550899] systemd[1]: systemd 249.11-0ubuntu3.12 running in system mode
[    7.551400] systemd[1]: Detected architecture arm64.
[    7.559528] systemd[1]: Hostname set to ubuntu.

The system has entered the real Ubuntu User Space.

Then systemd continues starting device management, networking, logging, NVIDIA services, and the GUI:

[    7.774172] systemd[1]: Queued start job for default target Graphical Interface.

The next target is graphical.target — the desktop environment.

By this point, Bootloader, Linux Kernel, NVMe, and RootFS have all succeeded. The system is in Ubuntu User Space. The chain from power-on to Ubuntu is essentially complete.

Any auto-start software you set up will also start here.

Troubleshooting: Find the last stage that succeeded

The most common question in the Seeed Jetson community: “Why won’t my Jetson boot?”

Flashing can fix 90% of issues, but the better habit is to first get the UART Boot Log and analyze based on the last stage that successfully completed — understanding the root cause helps you avoid similar problems later.

The methodology is essentially: progressively narrow down the failing boot stage.

One more thing: Errors or Warnings in the Boot Log don’t always mean boot has failed. An Error doesn’t necessarily mean the device won’t boot. For example, even after entering Ubuntu User Space, you might see:

imx219 ... error during i2c read probe
imx219 ... board setup failed
imx219 ... probe ... failed

What actually failed here is the IMX219 Camera Probe — not the entire Jetson boot flow.

When reading a boot log, don’t chase the first Error. Follow the boot chain to find the last stage that succeeded.

Closing thoughts

Jetson’s boot logs are long, but you don’t need to read every line. Pair this with AI-assisted analysis to drill into suspicious areas. Once you know which layer the system stopped at, the problem scope usually narrows quickly — that’s the most important mindset for Jetson boot troubleshooting. Master it, and a thousand-line Boot Log becomes a Jetson boot map instead of a wall of noise.

Next article: What’s actually stored in Jetson’s QSPI? — Why, when Ubuntu lives on NVMe, can QSPI issues still prevent boot?

About the column

This is Seeed Studio’s Jetson low-level technical column, written by You Jiang, a Seeed application engineer and core technical contributor in the Seeed Jetson community. The column covers Jetson kernel development, boot flow, drivers, and peripheral adaptation — helping you move from “using Jetson” to “understanding Jetson.”

About Author