Orin NX capsule update from L4T 35.2.1 to 35.3.1 is an unsupported release path, not a demonstrated nv_boot_control.conf defect. No current or thermal limit is being exceeded; update progress stops at 5% because UEFI image validation cannot find dce-fw in the package and aborts. Orin NX OTA support starts with L4T 35.3.1, so a system running 35.2.1 cannot serve as the supported OTA source for this test.
Failure signatures and controlling limits
The number that matters is the supported source-release boundary. The target hardware, package contents, and installed release all participate in capsule validation; successfully creating a capsule file does not prove that the running firmware can accept it.
| Observation | Meaning | Where to read it |
|---|---|---|
Unknown target soc: NULL |
The BUP generator did not resolve the supplied board specification. | Output from l4t_generate_soc_bup.sh
|
t23x_3767_bl_spec absent |
L4T 35.3.1 does not contain that named specification in the inspected configuration file. | tools/ota_tools/version_upgrade/ota_board_specs.conf |
dce-fw not found in package: Not Found |
UEFI rejected the submitted package during image checking because a required component was unavailable. | UEFI capsule-update log |
Status = Aborted |
The firmware management driver stopped both image checking and installation. |
FmpDxe(NVIDIA System Firmware) messages |
Update Progress - 5% |
The failure occurred during early validation, before a successful firmware replacement. | UEFI update display |
| OTA support begins at 35.3.1 | L4T 35.2.1 is outside the supported Orin NX OTA starting point. | Release support statement for Orin NX |
Package-validation mechanism
A UEFI capsule is a container presented to the firmware update driver. Before programming firmware, the driver checks whether the capsule targets the installed platform and whether its required payload components are present. Here, CheckTheImage() reaches the package check, reports the missing dce-fw component, and returns Aborted. SetTheImage() then cannot proceed and the capsule handler resets the system.
This is a compatibility and package-composition gate, not a write-duration or power-load symptom. Repeatedly submitting the same capsule will repeat the 5% rejection because neither the running 35.2.1 update environment nor the package relationship changes.
The separate BUP-generation error occurs earlier in the toolchain. The command requests t23x_3767_bl_spec, but that exact entry is absent from ota_board_specs.conf. Passing an unresolved specification leaves the tool without a valid target and produces Unknown target soc: NULL. Substituting a guessed specification could build a payload for the wrong platform, so select only an entry supplied for the board and release being used.
Release and platform decision path
Start with the installed release. If the Orin NX is running L4T 35.2.1, stop the capsule-upgrade test: that release predates supported OTA operation for Orin NX. The supported baseline begins at 35.3.1, while the required Orin NX and Orin Nano board-spec entries were expected in a future L4T release.
Next separate carrier identification from update-path support. This installation identifies p3509-a02+p3767-0000, uses nvme0n1 as boot storage, and lists /dev/mtdblock0 for both OTA devices. Those values deserve comparison with the configuration generated by the exact flash setup, but changing them cannot make an unsupported 35.2.1 source release supported.
The completed l4t-bootloader-config service also rules out one operational omission that can produce capsule trouble on another installation. Service completion does not supply a missing package component or add a missing board specification.
Supported recovery and update procedure
- Record the current L4T release, module identity, carrier selection, boot storage, and the complete UEFI failure log before changing the installation.
- Preserve required application data. Moving from the early 35.2.1 installation to a supported baseline may require a flash workflow rather than an in-place capsule update.
- Establish L4T 35.3.1 or a later documented baseline using the release procedure that explicitly supports the Orin NX platform. Treat 35.3.1 as the first OTA-capable Orin NX source, not as proof that every capsule target is valid.
- For a later OTA test, use the board-spec entry shipped with that release for the exact module and carrier combination. Confirm the entry exists in
ota_board_specs.confbefore running the BUP generator. - Generate the BUP and capsule from one internally consistent release tree. The attempted capsule command used
bootloader/payloads_t23x/bl_only_payloadwith targett234; retain exact tool output so the generated payload can be traced to its inputs. - Apply the capsule only across a release transition documented as supported for Orin NX. Capture the full UEFI update log and the operating-system boot state after the reset.
Post-update verification
A successful test must pass both firmware and operating-system checks. In UEFI, verify that CheckTheImage() and SetTheImage() complete without Aborted, that progress advances beyond 5%, and that no package component is reported missing. A reset message alone is not proof of success because the failed attempt also reset after handling the capsule.
After boot, read the installed L4T release and compare it with the intended target. Recheck /etc/nv_boot_control.conf, confirm that its platform and storage fields match the flash configuration, and inspect the bootloader configuration service result. Preserve the generated payload, command line, tool output, and UEFI log as one test record.
Recurring diagnostic pitfalls
-
Editing boot-control data first: A suspicious
TNSPECcan justify comparison with the flash configuration, but it is downstream of the decisive 35.2.1 support boundary. - Treating capsule creation as compatibility proof: The generator can create a container that the running UEFI later rejects during component and platform checks.
- Guessing a missing board specification: A similar-looking entry may describe a different module, carrier, or release relationship. Use a specification actually shipped for the configuration.
-
Using reset as a success signal: The logged sequence ends with
capsule update complete, resettingeven afterSetImagereturnsAborted. - Repeating an unsupported transition: Re-running the same 35.2.1-to-35.3.1 capsule cannot correct the absent support path or missing package component.
FAQ
What happens if I apply an L4T 35.3.1 capsule from Orin NX running 35.2.1?
UEFI can reject it during early validation. In this case, progress stopped at 5%, dce-fw was reported missing, and both image checking and installation returned Aborted.
What happens if the BUP board specification is missing?
The generator cannot resolve the target and reports Unknown target soc: NULL. Confirm that the exact specification exists in tools/ota_tools/version_upgrade/ota_board_specs.conf; never replace it with a guessed board entry.
When should I stop capsule testing and contact official support?
Stop when a documented Orin NX update path still fails after the source baseline, board specification, package inputs, and generated boot-control configuration all match. Contact official NVIDIA support with the full generator command and output, UEFI log, installed and target L4T releases, module and carrier identities, boot-storage layout, and nv_boot_control.conf; avoid further capsule attempts if platform identity remains uncertain.