Jetson Orin 32G / Devkit board / TOS / Unhandled Exception from EL1

I can’t turn on Secure boot and Disk Encryption in Jet Pack 6.2 (R36.3.4)

If I specify the burning process with the Secure Boot and eMMC encrytion, I’ve got the following error during TOS boot:

NOTICE:  BL31: Built : 15:33:57, Jan 21 2025
I/TC: 
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 4.2 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Wed Jan 22 08:55:02 UTC 2025 aarch64
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
Unhandled Exception from EL1
x0             = 0x7ef847a1233c6921
x1             = 0xf6a5260ecec405ad
x2             = 0x00000000000f4240
x3             = 0x0000000081000000
x4             = 0x0000000000000001
x5             = 0x000000083c1f3d68
x6             = 0xffffffffffffffff
x7             = 0x000000083c26aef0
x8             = 0x0000000000000020
x9             = 0x000000083c26aef0
x10            = 0x00000000000010c0
x11            = 0x0000000000000000
x12            = 0x00000000ffffffd8
x13            = 0x000000083c10e679
x14            = 0x000000083c26b014
x15            = 0x0000000842240020
x16            = 0x000000083c0ae714
x17            = 0x0000000000000000
x18            = 0x000000083c26afc4
x19            = 0x0000000000000000
x20            = 0x0000000000000000
x21            = 0x000000083c040020
x22            = 0x0000000000000000
x23            = 0x000000083c281b10
x24            = 0x000000083c1f4550
x25            = 0x0000000000000000
x26            = 0x0000000000000000
x27            = 0x0000000000000000
x28            = 0x0000000000000000
x29            = 0x0000000000000000
x30            = 0x000000083c080180
scr_el3        = 0x0000000000000e34
sctlr_el3      = 0x0000000030cd183f
cptr_el3       = 0x0000000000000000
tcr_el3        = 0x0000000080823518
daif           = 0x00000000000002c0
mair_el3       = 0x00000000004404ff
spsr_el3       = 0x00000000600003c4
elr_el3        = 0x000000083c08018c
ttbr0_el3      = 0x0000000050023e01
esr_el3        = 0x0000000062320802
far_el3        = 0x0000000000000000
spsr_el1       = 0x0000000000000000
elr_el1        = 0x0000000000000000
spsr_abt       = 0x0000000000000000
spsr_und       = 0x0000000000000000
spsr_irq       = 0x0000000000000000
spsr_fiq       = 0x0000000000000000
sctlr_el1      = 0x0000000030d8180d
actlr_el1      = 0x0000000000000000
cpacr_el1      = 0x0000000000000000
csselr_el1     = 0x0000000000000000
sp_el1         = 0x000000083c1f4550
esr_el1        = 0x0000000000000000
ttbr0_el1      = 0x000000083c254000
ttbr1_el1      = 0x0000000000000000
mair_el1       = 0x00000000ff00ff04
amair_el1      = 0x0000000000000000
tcr_el1        = 0x0000000280803f1a
tpidr_el1      = 0x0000000000000000
tpidr_el0      = 0x0000000000000000
tpidrro_el0    = 0x0000000000000000
par_el1        = 0xff0000083c237980
mpidr_el1      = 0x0000000081000000
afsr0_el1      = 0x0000000000000000
afsr1_el1      = 0x0000000000000000
contextidr_el1 = 0x0000000000000000
vbar_el1       = 0x000000083c083000
cntp_ctl_el0   = 0x0000000000000000
cntp_cval_el0  = 0x0000000000000000
cntv_ctl_el0   = 0x0000000000000000
cntv_cval_el0  = 0x0000000000000000
cntkctl_el1    = 0x0000000000000000
sp_el0         = 0x0000000050016bf0
isr_el1        = 0x0000000000000000
cpuectlr_el1   = 0xa000000b40543000

Found some similar fixes/issues here:

Then I’ve downloaded the latest nv-optee sources from here:

Modifications (according to the topics listed above):

  • CFG_TEGRA_SE_USE_TEST_KEYS = n
  • CFG_INSECURE = n

Compilation:
export CROSS_COMPILE_AARCH64_PATH=l4t-gcc-11.3
export CROSS_COMPILE_AARCH64=l4t-gcc-11.3/bin/aarch64-buildroot-linux-gnu-
CROSS_COMPILE=l4t-gcc-11.3/bin/aarch64-buildroot-linux-gnu-
UEFI_STMM_PATH=36.4.3/Linux_for_Tegra/bootloader/standalonemm_optee_t234.bin
./optee_src_build.sh -p t234

Please, help.

Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!

Sure, uart log:
jetson.orin.32g.devtoot.secureboot.emmc-encrypted.log (35.3 KB)

hello dmitriy.philimonov,

may I have confirmation,
had you verify Secure boot and Disk Encryption in JP-6.1/r36.4 before?

Good day, Jerry.

Our team has the experience only with JP-5. We’re thinking of upgrading to the JP6.0/6.1/6.2 depending on our hardware supplier capabilities. For now I’m running tests on the NVIDIA devkit board.

hello dmitriy.philimonov,

let’s also narrow down the issue. for instance, is it able to boot-up correctly without disk encryption?
upon disk encryption, please also check you’ve create EKS image correctly, you may see-also Topic 310592 to examine EKS image.

Without disk encryption - everything works correctly.
With disk encryption and with CFG_TEGRA_SE_USE_TEST_KEYS=y - still works correctly, but it’s unsecure.

Thanks, I’ll try to dive deep in the topic with EKS image.

hello dmitriy.philimonov,

thanks for sharing, root cause should be due to the OP-TEE modification,
for instance,

I doubt it’s dependency issues,
please visit NVIDIA Jetson Linux 36.4.3 to download [Driver Package (BSP) Sources] for the public release sources.
you should extract atf_src.tbz2 and nvidia-jetson-optee-source.tbz2 to the same folder, such as atf_and_optee/
you may follow the readme file for the steps to build the OP-TEE source package,
for instance, $public_sources/Linux_for_Tegra/source/atf_and_optee/optee/atf_and_optee_README.txt

BTW,
you may install the same Jetpack public release image via SDK Manager to your host machine.
please double check you’ve point the location of the image correctly. i.e. UEFI_STMM_PATH=<StMM image path>
since an UEFI StMM image is required to build OP-TEE.

Good day, JerryChang

You are right, I’ve found the divergence in our ATF build script, where the make was directly invoked:

make BUILD_BASE=build CROSS_COMPILE="$CROSS_COMPILE_AARCH64" \
-        DEBUG=0 LOG_LEVEL=20 PLAT=tegra SPD=opteed TARGET_SOC="$NV_TARGET_BOARD" V=0

However, in JP6.2 the additional parameters were added (according to the nvbuild.sh):

                if [ "${target_soc}" == "t234" ]; then
                        # Enable PAC(Pointer Authentication Codes)
                        atf_build_params=("BRANCH_PROTECTION=3" "ARM_ARCH_MINOR=3") # <-- HERE
                fi

                # shellcheck disable=SC2068
                "${MAKE_BIN}" -C "${source_dir}" \
                        BUILD_BASE="./${NV_TARGET_BOARD}-${target_soc}" \
                        CROSS_COMPILE="${CROSS_COMPILE_AARCH64}"  \
                        TARGET_SOC="${target_soc}" \
                        DEBUG=0 LOG_LEVEL=20 PLAT=tegra SPD=opteed V=0 \
                        -j"${NPROC}" --output-sync=target \
                        ${atf_build_params[@]}

Rebuilding with the default nvbuild.sh according to the atf_and_optee_README.txt solved the issue.

Thank you for your time, Jerry
Problem is solved.

P.S. I’ll try to check with JP6.1 (our production board supplier maximum JetPack supported).

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.