I have a custom industrial Orin (r36.3) board. After attempting a Capsule Update, the device failed to boot properly and Cannot enter UEFI menu either. The UEFI version timestamp shows that the update was successful, but during boot I encountered the following error:
FATAL ERROR [FILE=platform/drivers/thermal/bjt/soctherm-cal.c, ERR_UID=2053]:
BPMP-DTB property ‘/soctherm/thermtrip_hot’ above maximum permitted (118000 > 105000)
▒▒ERROR: camera-ip/isp5/isp5.c:2031 [isp5_pm_init] "ERROR: Failed to turn isp1 power on"
BUG: core/init/init.c:86 [init_all] "*** FIRMWARE INIT FAILED AT LEVEL 95 ***"
The full boot log is attached below. Could you please help analyze what might be causing this issue?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it appears that you are experiencing a boot issue with your custom industrial Orin r363 board after attempting a Capsule Update. The UEFI version timestamp indicates that the update was successful, but the device failed to boot properly, resulting in an error.
To analyze this issue, let’s break down the key points:
Capsule Update: The update process involves updating the KEK, db, and dbx keys, which are used for UEFI Secure Boot. The update process seems to have completed successfully, as indicated by the UEFI version timestamp.
Boot failure: Despite the successful update, the device failed to boot properly, resulting in an error. This suggests that there might be an issue with the boot process or the updated keys.
Error log: The attached log file (log.txt) contains the full boot log, which might provide more information about the error.
To help you analyze the issue, I’ll provide some general guidance and potential causes:
UEFI Secure Boot: Ensure that UEFI Secure Boot is enabled and set to UEFI mode. Also, verify that the updated KEK, db, and dbx keys are correctly configured.
Boot partition: Check if the boot partition is correctly configured and if the updated keys are properly applied to the boot partition.
Kernel or driver issues: It’s possible that there’s an issue with the kernel or drivers that’s preventing the device from booting properly.
Hardware compatibility: Verify that the custom industrial Orin r363 board is compatible with the updated UEFI and boot process.
To further assist you, I recommend:
Checking the boot log: Analyze the attached log file (log.txt) to identify any specific error messages or clues that might indicate the cause of the issue.
Verifying UEFI settings: Double-check the UEFI settings to ensure that Secure Boot is enabled and set to UEFI mode.
Updating the boot partition: Try updating the boot partition again to ensure that the updated keys are properly applied.
Seeking additional support: If none of the above steps resolve the issue, consider seeking additional support from NVIDIA experts or the developer community.
In comparison to other topics in the provided context, this issue seems to be related to the “Boot failed” topic, which also involves a boot issue with a Jetson Xavier NX device. However, the specific error message and context are different, so it’s essential to analyze this issue separately.
Please provide more information about the error log and any additional details you can share about your setup and configuration. This will help me provide a more accurate and comprehensive analysis of the issue.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
I just tried using l4t_generate_soc_bup.sh, and it can flash successfully. However, But how do I specify the correct BPMP-FW config file when using build_l4t_bup.sh?
[2025-10-09 11:28:27] root@tegra-ubuntu:~# nvbootctrl dump-slots-info
[2025-10-09 11:28:37] Current version: 36.3.0
[2025-10-09 11:28:37] Capsule update status: 1
[2025-10-09 11:28:37] Current bootloader slot: B
[2025-10-09 11:28:37] Active bootloader slot: B
[2025-10-09 11:28:37] num_slots: 2
[2025-10-09 11:28:37] slot: 0, status: normal
[2025-10-09 11:28:37] slot: 1, status: normal
Also, I have another question:
I noticed that when I manually switched the current slot, both slots showed Capsule update status = 1. I only flashed the bootloader for one slot.It seems that once it succeeds, it will remain 1 until a failure occurs. It remains 0 as long as no update has ever been performed.
Can I do a Bootloader A/B Capsule Update without enabling ROOTFS_AB=1?I tried it, and it seems possible.
Okay, both l4t_generate_soc_bup.sh and build_l4t_bup.sh should be available to generate the BUP but you have to run l4t_generate_soc_capsule.sh to transform it from BUP to capsule payload.(.Cap)
l4t_generate_soc_bup.sh is used for multi-spec BUP while build_l4t_bup.sh is used for single-spec BUP.
It is the expected result since it will check the version.
Sure, capsule update will only do update for bootloader rather than rootfs. It did nothing for rootfs.
But according to the steps I wrote above, after using build_l4t_bup.sh, I then called l4t_generate_soc_capsule.sh to generate the capsule payload file. It can be recognized and updated normally in UEFI, but after the update, it fails to boot properly. As mentioned earlier, it’s due to the incorrect .conf file. I would like to ask how to specify the correct .conf file. I noticed that the Single-Spec BUP is about 15MB, while the Multi-Spec BUP is about 20MB.
You just need to run either of them. build_l4t_bup.sh to generate single spec BUP. l4t_generate_soc_capsule.sh to generate multi-spec BUP.
The boot issue is caused from that bpmp-fw error reported in your original post.
It is caused from the wrong customization in jetson_board_spec.cfg.
Do you use the custom board config in your case?
It is specified in jetson_board_spec.cfg.
e.g. the following part is configured for jetson-agx-orin-devkit-industrial.conf
I haven’t modified the jetson-agx-orin-devkit-industrial.conf configuration file. I found that the reason it wasn’t replaced with TE992M-A1 is that ${chip_SKU} is not 00. I tried printing it out, and when I still used my previous command to generate the single-spec BUP:
I found that it prints out as D0.Could you explain why this is?So does my device really need to use bpmp_t234-TE992M-A1_prod.bin rather than bpmp_t234-TE990M-A1_prod.bin for BPMP-FW?
# process_chip_sku_version:
#
process_chip_sku_version()
{
local chip_sku="${1}";
local chip_minor_revision_id="${2}";
local bootrom_revision_id="${3}";
local ramcode="${4}";
local fuselevel="${5}";
local board_FAB="${6}";
declare -A bpmp_fw_binary;
bpmp_fw_binary['90']="TE992M-A1";
bpmp_fw_binary['97']="TA990SA-A1";
bpmp_fw_binary['9E']="TA990SA-A1";
bpmp_fw_binary['D0']="TE990M-A1";
bpmp_fw_binary['D2']="TE990M-A1";
chip_sku="${chip_sku:-${DEFAULT_CHIP_SKU}}"
if [[ "${chip_sku}" =~ ":" ]]; then
chip_SKU=`echo "${chip_sku}" | awk -F ":" '{print $4}'`;
fi;
# do not override BPFFILE for INT SKU "00"
if [ "${chip_SKU}" != "00" ]; then
BPFFILE=`echo "${BPFFILE}" | sed "s|T.*-A1|${bpmp_fw_binary[${chip_SKU}]}|"`;
fi;
echo "Chip SKU(${chip_sku}) ramcode(${ramcode}) fuselevel(${fuselevel}) board_FAB(${board_FAB})"
}
Is it true that chip_SKU can only get the correct value when the device enters recovery mode and is connected to the host, or during a flash.sh flashing process? However, I clearly saw in the documentation for R36.3 that it can be generated without being connected to the host.
Okay, your understanding is correct and I might have typo there.
Do you mean that you are using the default board config for AGX Orin Industrial? (i.e. jetson-agx-orin-devkit-industrial.conf)
Yes, you need to use bpmp_t234-TE992M-A1_prod.bin for AGX Orin Industrial.
I’m not clear about what’s the exact module you are using.
Could you connect your board in forced-recovery state and run the following command to generate single-spec BUP?
It seems the expected result that it uses the bpmp_t234-TE992M-A1_prod.bin as bpmp-fw for AGX Orin Industrial.
The chipsku for AGX Orin Industrial(p3701-0008) is 90 as it is specified in jetson_board_spec.cfg.
Actually, you can remove the unused entries in jetson_board_spec.cfg before you generate the capsule payload.
Please try using the following command to verify. (w/o the board connected)
Specifying the CHIP_SKU is valid, but why does it still use bpmp_t234-TE990M-A1_prod.bin even after I deleted the unused entries in jetson_board_spec.cfg?
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# jetson_board_spec.cfg: board specs for Jetson boards:
# 1. t23x series
#
# Exported name of each spec entry is:
# <CHIP_NAME>_spec
t23x_agx_ind_bl_spec=(
# jetson-agx-orin-devkit-industrial:
'boardid=3701;fab=300;boardsku=0008;boardrev=;chiprev=;chipsku=00:00:00:90;board=jetson-agx-orin-devkit-industrial;rootdev=mmcblk0p1;bup_type=bl'
)
t23x_3701_bl_spec=(
${t23x_agx_ind_bl_spec[@]}
)
Yes, it seems specifying CHIP_SKU is necessary for AGX Orin Industrial if you generate capsule payload offline. (i.e. generate capsule payload w/o the board connected)
p3701.conf.common is included in jetson-agx-orin-devkit-industrial.conf.
Please refer to the following line in p3701.conf.common:
