MCU-Controlled Boot Chain & Functional Safety Strategy for Jetson Orin

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

1. Request Overview

We are submitting a custom feature request to enable an external MCU to control the Jetson Orin’s boot chain selection mechanism. This is to support a functional safety diagnostic strategy that we plan to implement in our product design.

2. Background

Our system requires a functional safety strategy where a dedicated external MCU is responsible for monitoring the Orin’s health and actively controlling the boot flow. The MCU will be able to force a boot partition switch (A/B) independently of the Orin’s software state, providing robust recovery from boot failures or runtime crashes.

3. Hardware Discussion Points

  • Pin Requirements: We need to identify which specific GPIO pins on the Orin module should be reserved in the hardware design to allow the MCU to control the boot chain selection.

  • Boot Partition Encoding: The MCU will use these pins (e.g., as a 2-bit logic input) to signal the desired boot partition (A or B).

  • Early Init: The selected pins must be configurable as inputs at the MB1 (Micro Bootloader) stage to allow the Orin to read the MCU’s signal before UEFI initializes.

4. Software Discussion Points

  • Diagnostic Communication via UART:
    We propose using a dedicated UART interface between the MCU and Orin as the primary channel for diagnostic information exchange. This UART connection will handle the following:

    • Heartbeat Signal: Orin will send periodic heartbeat messages to the MCU via UART to indicate that the system is alive and the OS is running. The MCU will monitor this heartbeat and trigger recovery actions if the heartbeat stops or becomes irregular.

    • Boot Partition Status Report: After Orin boots, it will send its current active partition (A or B) and boot status to the MCU over UART, allowing the MCU to maintain awareness of the system’s state.

    • Error/Exception Reporting: Orin can send explicit error or exception codes to the MCU over UART when it detects critical failures (e.g., application crash, filesystem corruption).

  • MCU Exception Handling & Recovery:
    The MCU should monitor for specific abnormal conditions and take the following actions:

    • Scenario 1: Orin fails to boot (no heartbeat received within a defined timeout, e.g., 10–15 seconds) → MCU will:

      1. Toggle the GPIO pins to select the alternate boot partition.

      2. Assert a hardware reset on the Orin (via PMIC or reset pin).

      3. If the alternate partition also fails, initiate a higher-level recovery procedure.

    • Scenario 2: Orin runtime application crash → The MCU should detect the failure (e.g., via missing heartbeat, irregular heartbeat pattern, or explicit fault report over UART) and trigger a similar recovery flow (partition switch and reset), if necessary.

    • Scenario 3: Orin reports a fatal error over UART → The MCU can immediately decide to switch partitions and reset based on the error code received.

5. Companion OTA Tool Modifications

We also require that the accompanying OTA update script/tool (ota_tools_R39.2.0_aarch64.tbz2) be modified to support communication with the MCU. Specifically, the tool should be able to:

  • Notify the MCU before and after a system update (e.g., to prevent false fault detection during upgrade).

  • Receive confirmation from the MCU when the new partition is ready to be activated.

  • Support coordinated slot switching that respects the MCU’s supervisory role.

Thank you again for your ongoing support.

Best regards,
Haibao YU

5

hello yuhaibao,

may I have more details of MCU to control the boot chain selection?

please aware that Bootloader redundancy is enabled by default.
assume you’ve loaded a corrupted bootloader/firmware binary from slot-A, it’ll retry for 7-times, and then switch to slot-B for booting up as failover.
for instance, MAX_BL_RETRY_COUNT 7

besides.. let’s have a topic for single question/inquiry,
please submit a new discussion thread about OTA tool modification.

6

Hello JerryChang:

We need more than just multiple retry attempts. Our objective is a more robust rollback scheme, achieved by having the MCU control GPIO pins to switch the boot chain, similar to the approach described here:
NVIDIA Orin Boot Chain Configuration Support
Could you please assess whether it is feasible to implement and support a combined software and hardware solution on the Jetson Orin?

Best regards,
Haibao YU

7

hello yuhaibao,

that’s for Drive OS, which doesn’t apply with L4T.