TEEC_ERROR_ITEM_NOT_FOUND (0xffff0008) When Using OP-TEE on Jetson Orin Nano

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

Overview

I am trying to use OP-TEE on my Jetson Orin Nano, following the official NVIDIA documentation (Op-TEE Setup). However, when I attempt to run nvhwkey-app, I receive TEEC_ERROR_ITEM_NOT_FOUND (0xffff0008, origin 0x4), and the Trusted Application (TA) does not seem to load.

I would really appreciate any guidance on debugging this issue!

System Setup and Steps Taken

1. Flashed Jetson Linux and Verified TPM

  • I flashed Jetson Linux onto the Orin Nano, and the system is fully functional.
  • I confirmed TPM is working by running:
    ls /dev | grep tpm
    Output:
    tpm0
tpmrm0
  • Also successfully used:
    tpm2_pcrread sha256:0

2. Built OP-TEE and Verified tee-supplicant

  • I built optee_os and optee_client following the guide.
  • Verified that OP-TEE is detected:
    dmesg | grep -i tee
    Output:
    [    3.676613] optee: probing for conduit method.
[    3.676666] optee: revision 4.2 (f4442694)
[    3.736118] optee: dynamic shared memory is enabled
[    3.736372] optee: initialized driver
  • Checked if tee-supplicant is running:
    ps aux | grep tee
    Output:
    root         324  0.0  0.0   9812  3404 ?        Ss   Feb12   0:00 /bin/bash /etc/systemd/nv-tee-supplicant.sh
root         326  0.0  0.0  76564  1428 ?        Sl   Feb12   0:00 /usr/sbin/tee-supplicant
root         327  0.0  0.0      0     0 ?        I<   Feb12   0:00 [optee_bus_scan]

3. Verified and Copied the TA File

  • Ensured the TA file is in the correct OP-TEE directory:
    ls -lh /lib/optee_armtz/
    Output:
    -rw-rw-r-- 1 jetson jetson 111K Feb 13 11:47 82154947-c1bc-4bdf-b89d-04f93c0ea97c.ta

4. Copied and Configured the Client Application (CA)

  • Copied nvhwkey-app to /usr/sbin/ and made it executable:
    sudo chmod +x /usr/sbin/nvhwkey-app
ls -lh /usr/sbin/nvhwkey-app
    Output:
    -rwxrwxr-x 1 jetson jetson 71K Feb 13 11:48 /usr/sbin/nvhwkey-app
  • Running the app shows usage instructions:
    sudo /usr/sbin/nvhwkey-app
    Output:
    Usage: nvhwkey-app [OPTION...]
          -e [-d] -i <file> -o <out-file> or -r <random size>
Try `nvhwkey-app --help' or `nvhwkey-app --usage' for more information.

5. Attempted to Encrypt a File (Fails with TEEC_ERROR_ITEM_NOT_FOUND)

  • Tried running nvhwkey-app to encrypt a test file:
    sudo nvhwkey-app -e -i /home/jetson/test -o /home/jetson/test_encrypted.bin
    Error:
    TEEC_InvokeCommand failed 0xffff0008 origin 0x4

Additional Information

OP-TEE Source Directory Structure

Inside my Jetson OP-TEE sources, there is a build directory containing:

  • ca/ (for Client Applications)
  • ta/ (for Trusted Applications)

📸 Here are images showing the contents of these directories:\

optee folder
optee folder1597×496 52.3 KB

… I can only show one picture because I am a new user, but inside these ca and ta folder there are several examples and one of them is hwkey-agent.

I did not run the make command from Step 6 of the guide because I assumed these directories already contained pre-built applications, so I skipped the make command. Instead, I copied the pre-built hwkey-agent files:

  • .ta file from ta/ → /lib/optee_armtz/
  • nvhwkey-app from ca/ → /usr/sbin/

However, I am not sure if this is correct, or if I need to manually build the TA using the command from Step 6:

make -C <source directory> \
     CROSS_COMPILE="<jetson-toolchain>/bin/aarch64-buildroot-linux-gnu-" \
     TA_DEV_KIT_DIR="<jetson-optee-srcs>/optee/build/t234/export-ta_arm64/" \
     OPTEE_CLIENT_EXPORT="<jetson-optee-srcs>/optee/install/t234/usr" \
     TEEC_EXPORT="<jetson-optee-srcs>/optee/install/t234/usr" \
     -j"$(nproc)"

Questions and Issues

  1. Trusted Application Not Found (0xffff0008)

    • I get TEEC_ERROR_ITEM_NOT_FOUND (0xffff0008, origin 0x4) when running nvhwkey-app.
    • Could this be caused by a missing or incorrectly built Trusted Application (TA)?

  2. Do I Need to Manually Build the CA and TA?

    • I assumed the ca/ and ta/ directories in build/t234 contained pre-built applications.
    • Do I need to build them manually instead?

  3. Troubleshooting Steps

    • tee-supplicant is running, and /dev/tee0 and /dev/teepriv0 are present.
    • I copied my .ta file to /lib/optee_armtz/ and my CA binary to /usr/sbin/.
    • Are there additional debugging steps I should take?

Thank you in advance for your help! 🚀

3

hello nik01flink,

please see-also Topic 288196 regrading to this error… TEEC_InvokeCommand failed 0xffff0001 origin 0x4

The OPTEE CA must be run at root privilege. e.g. "sudo nvftpm-helper-app -g”
And the fTPM CA can only work on a fTPM provisioned device.
On a non fTPM provisioned device, all the internal functionalities would be disabled.
here’s fTPM Doc. Firmware TPM — NVIDIA Jetson Linux Developer Guide 1 documentation

you may dig into developer guide, HWKEY AGENT CA and TA.

4

Hey JerryChang,

thanks for the feedback. I took a look at the other topic. That one is about a different example program … he wants to run “nvluks-srv-app” which works with a passphrase. But I followed your link to “HWKEY AGENT CA and TA”: Hwkey-agent works with user-defined keys stored in the EKB, but I haven’t set up anything with EKB or keys yet, I just followed the instructions as above and no keys need to be set up there. However, according to point 9 of the instructions, you should still be able to start the CA. Maybe it’s because of the example I used? To be honest, I’m not sure which example I should use instead. The only example where there were files with the same name in both the build/ta and build/ca directories was the hwkey-agent example. Thats why I took that one and did not use the make-command in point 6 of the instructions to compile my own files 😅
And you mentioned that all this only works on fTPM provisioned devices. I used a jetson orin nano, according to the instructions this is not a problem.

5

hello nik01flink,

there’re some default keys, it still fetch the random keys via SE keyslot.
you may dig into below for details.
$public_sources/r36.4.3/Linux_for_Tegra/source/atf_and_optee/optee/optee_os/core/pta/tegra/jetson_user_key_pta.c

6

Hey JerryChang,

I know it’s been a few days, but I’ve tried some of the things you suggested.

I started by taking a closer look at the examples in the developer guide again. Using the information there, I at least managed to figure out how to properly build and copy the CA and TA of the sample hwkey-agent onto the Jetson. I’ve done that, and I can now call nvhwkey-agent, but only the random number generator works. Data encryption and decryption still do not work. I get the same error: “TEEC_InvokeCommand failed 0xffff0008 origin 0x4” (which corresponds to TEEC_ERROR_ITEM_NOT_FOUND).

So now I’m sure that OP-TEE itself is installed on the Jetson, but apparently there’s an issue with the encryption or the keys.

I went through the developer guide again to figure out what the next steps might be. It frequently refers to images and the EKB. I also noticed there’s a Makefile in the host folder of the hwkey-agent samples to create an image. I created this image using an oem_k1.key, put it in the bootloader folder of my host system (replacing the old image), and then started a fresh flash to install Ubuntu, JetPack, and OP-TEE on the Jetson again. However, that turned out to be the wrong approach because the newly flashed Jetson no longer had any of the personal folders (like /home/jetson/downloads, /home/jetson/documents, etc.); only /home/jetson/desktop remained. Moreover, the random number generator from the hwkey-agent sample no longer worked either. So, I reverted to the old (default) image, where at least the random number generator works.

As another test, I tried using the sample nvluks-srv-app (as mentioned in topic 288196). But as with the other user in that topic, I got the error “TEEC_InvokeCommand failed 0xffff0001 origin 0x4” (meaning TEEC_ERROR_ACCESS_DENIED). You suggested to that user to check whether their disk encryption was working (as also recommended in the developer guide). However, if I follow the “Disk Encryption” chapter there, I end up again at the “Tool for EKB Generation,” which leads me back to creating an image—something I already attempted but couldn’t get working.

(I have to note that at the time, I generated that image in the host folder of the sample and used my own self-generated example keys, and I’m not sure if that was the correct procedure.)

In your last response on February 17, you suggested looking at the file in
$public_sources/r36.4.3/Linux_for_Tegra/source/atf_and_optee/optee/optee_os/core/pta/tegra/jetson_user_key_pta.c.
I did check it, but the error messages in that file are all TEE_ERROR messages. Since I’m getting a TEEC_ERROR, I didn’t continue investigating that file.

You can probably tell from my description and approach that I’m a total beginner in this area, just trying to piece things together on my own. One additional detail I forgot to mention before is that I’m not using fTPM—I have an actual TPM module attached to my Jetson, which I realized when re-reading your first response.

… Perhaps to get to the heart of the matter. I know that it’s probably a bit difficult to understand my problem and find a solution. I just want to make it clear what steps I’ve taken and where I’m stuck. It would be helpful if you could tell me where to start in the Developer Guide. I originally thought that after the 9 points in “How to Cross Compile a Trusted Application and Run it on Jetson Devices” the matter would be settled … 😅

7

hello nik01flink,

the disk encryption key is inside EKS image, disk encryption key can be extract at TEE side. as long as you’re using the same keys (align with the EKS image) to re-flash a target, it will boot-up correctly.
you may refer to Topic 264454, we tested disk encryption to confirm it’s working on Orin NX.

8

Hey JerryChang,
I took a look at Topic 264454 as you suggested and also followed the Quick Guide in the Developer Guide for Disk Encryption. Both refer to a pretty similar approach which I tried. These are the steps I took to enable the Disk Encryption and try to make the hwkey-agent sample work:

# 1️⃣ Install required packages
sudo apt-get install python3-cryptography python3-cffi-backend libxml2-utils
sudo apt-get install cryptsetup python3-pycryptodome python3-crypto

# 2️⃣ Create the QSPI Flash Image for Bootloader
cd Linux_for_Tegra
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
    --showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
    --no-flash jetson-orin-nano-devkit internal

# 3️⃣ Create the encryption key
echo "f0e0d0c0b0a001020304050607080900" > disk_enc.key

# 4️⃣ Generate the encrypted Rootfs Image (for external storage)
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
    --showlogs --no-flash --external-device nvme0n1p1 -S 16GiB \
    -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
    --external-only --append -i ./disk_enc.key jetson-orin-nano-devkit external

# 5️⃣ Flash the system
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs --flash-only

The “Flash the system”-process successfully completes Step 1 (Build the flashing environment) and Step 2 (Boot the device with the flash initrd image). However, it fails at Step 3 (Start the flashing process) with the following error:

Error: Could not stat device /dev/nvme0n1 - No such file or directory.
Flash failure
Either the device cannot mount the NFS server on the host or a flash command has failed.
Check your network setting (VPN, firewall,...) to make sure the device can mount NFS server.

🔹 Root Cause:
I believe this happens because the flashing process is looking for an NVMe SSD (/dev/nvme0n1), but I am not using an NVMe drive. Instead, my Jetson Orin Nano is booting from a microSD card.

🔹 So …

  • How can I modify the flashing process so that it correctly targets my microSD card instead of looking for an NVMe SSD?
  • Do I need to modify the partition config file? Should I use a different XML file instead of flash_l4t_t234_nvme_rootfs_enc.xml?
10

And maybe this also helps … this is the Makefile that helped me flash my image / custom kernel onto the jetson before I tried the disk encryption part:


JP ?= <invalid path>
TA ?= <invalid path>
MODEL ?= 234
KERNEL_VERSION ?= 5.15
KERNEL_BUILD ?= $(KERNEL_VERSION).148-tegra

DEV ?= /dev/sda
F_IMG ?= <select img>

NPROCS := 1
JETPACK_PTH := $(PWD)/$(JP)
TOOLCHAIN := $(JETPACK_PTH)/toolchain
KERNEL_TARGET := $(JETPACK_PTH)/target/Linux_for_Tegra
PUBLIC_SRC := $(KERNEL_TARGET)/source
OPTEE_SRC := $(PUBLIC_SRC)/jetson-optee-srcs/nvidia-jetson-optee-source
KERNEL_SRC := $(PUBLIC_SRC)/kernel
KERNEL_HEADERS := $(PUBLIC_SRC)/kernel/kernel-jammy-src

CROSS_COMPILE := $(TOOLCHAIN)/bin/aarch64-buildroot-linux-gnu-
TA_DEVKIT_DIR := $(OPTEE_SRC)/optee/build/t$(MODEL)/export-ta_arm64/
OPTEE_CLIENT_EXPORT := $(OPTEE_SRC)/optee/install/t$(MODEL)/usr
TEEC_EXPORT := $(OPTEE_SRC)/optee/install/t$(MODEL)/usr

CARGS := CROSS_COMPILE=$(CROSS_COMPILE) \
	 KERNEL_HEADERS=$(KERNEL_HEADERS) \
	 INSTALL_MOD_PATH=$(KERNEL_TARGET)/rootfs 

ta-app:
	make -C "$(TA)" \
		$(CARGS) \
		TA_DEVKIT_DIR="$(TA_DEVKIT_DIR)" \
		OPTEE_CLIENT_EXPORT="$(OPTEE_CLIENT_EXPORT)" \
		TEEC_EXPORT="$(TEEC_EXPORT)" \
		-j"$(NPROCS)"

kernel:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make -C kernel && \
		$(CARGS) sudo -E make install -C kernel

config:
	./scripts/set-config.sh -i $(JP)/configs/defconfig -k $(KERNEL_HEADERS)


modules:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make modules && \
		$(CARGS) sudo -E make modules_install && \
	cd $(KERNEL_TARGET) && \
		sudo ./tools/l4t_update_initrd.sh

dtbs:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make dtbs && \
		cp kernel-devicetree/generic-dts/dtbs/* $(KERNEL_TARGET)/kernel/dtb

flash:
	cd $(KERNEL_TARGET) && \
		sudo ROOTFS_AB=1 ./nvsdkmanager_flash.sh

all: config kernel modules dtbs flash
	say done
11

hello nik01flink,

please revise your flash command-line,
you may see-also To Flash the Jetson Developer Kit Operating Software, by checking [Jetson Orin Nano Developer Kit (SD card)] for sample flash commands.

12

Hey,

I think I’ve got everything set up, but after flashing, the Jetson won’t boot up anymore. This is the screen where it gets stuck. It says the disk cannot be unlocked—did I miss a step?

image
image539×812 81.6 KB

13

hello nik01flink,

it’s a bad practice for sharing logs as a picture,
please gather those logs, you may attached it as single text file, or, using code block (i.e. <code>LOGs</code>) to paste the logs.

14

I am sorry, I do not have access to the logs since I can not use the jetson at the current state.
I wrote it down by hand:

9.156888 pci_bus 0004:00: root bus resource [mem 0x2140000000-0x2427fffffff pref]

9.156950 pci 0004:00:00.0: [10de:229c] type 01 class 0x060400
9.157139 pci 0004:00:00.0: PME# supported from D0 D3hot
9.169131 pci 0004:00:00.0: PCI bridge to [bus 01-ff]
9.169358 pcieport 0004:00:00.0: Adding to iommu group 6
9.169970 pcieport 0004:00:00.0: PME: Signaling with IRQ 193
9.170159 pcieport 0004:00:00.0: AER: enabled with IRQ 193
9.170619 pci_bus 0004:01: busn_res: [bus 01-ff] is released
9.170748 pci 0004:00:00.0: Removing from iommu group 6
9.170766 pci_bus 0004:00: busn_res: [bus 00-ff] is released
9.172552 tegra194-pcie 141e0000.pcie: Adding to iommu group 7
9.173955 tegra194-pcie 141e0000.pcie: host bridge /bus0@pcie141e0000 ranges:
9.173987 tegra194-pcie 141e0000.pcie: MEM 0x30000000…0x3227ffff → 0x30000000
9.173987 tegra194-pcie 141e0000.pcie: MEM 0x3228000000…0x3227ffffff → 0x04000000
9.173987 tegra194-pcie 141e0000.pcie: IO 0x003e100000…0x003e1fffff → 0x003e10000
9.174339 tegra194-pcie 141e0000.pcie: iATU unroll: enabled
9.174311 tegra194-pcie 141e0000.pcie: Detected iATU regions: 8 outbound, 2 inbound
No key available with this passphrase.
10.280638 tegra194-pcie 141e0000.pcie: Phy link never came up
10.280637 tegra194-pcie 141e0000.pcie: Phy link never came up
11.280722 tegra194-pcie 141e0000.pcie: PCI host bridge to bus 0007:00
11.280778 pci_bus 0007:00: root bus resource [io 0x200000-0x2fffff] (bus address [0x3e100000-0x3e1fffff])
11.280782 pci_bus 0007:00: root bus resource [mem 0x3228000000-0x3227ffffff] (bus address [0x40000000-0x47ffffff])
11.280787 pci_bus 0007:00: root bus resource [bus 00-ff]
11.280789 pci_bus 0007:00: root bus resource [mem 0x30000000-0x3227ffffff pref]
11.280844 pci 0007:00:00.0: [10de:229a] type 01 class 0x060400
11.281010 pci 0007:00:00.0: PME# supported from D0 D3hot
11.297146 pci 0007:00:00.0: PCI bridge to [bus 01-ff]
11.297347 pcieport 0007:00:00.0: Adding to iommu group 7
11.297469 pcieport 0007:00:00.0: PME: Signaling with IRQ 195
11.301481 pcieport 0007:00:00.0: AER: enabled with IRQ 195
11.303140 pci_bus 0007:01: busn_res: [bus 01-ff] is released
11.303271 pci 0007:00:00.0: Removing from iommu group 7
11.303317 pci_bus 0007:00: busn_res: [bus 00-ff] is released
11.308317 tegra194-pcie 140a0000.pcie: Adding to iommu group 8
11.421683 tegra194-pcie 140a0000.pcie: host bridge /bus@0/pcie@140a0000 ranges:
11.421931 tegra194-pcie 140a0000.pcie: MEM 0x3240000000…0x3527fffffff → 0x3240000000
11.421962 tegra194-pcie 140a0000.pcie: MEM 0x3528000000…0x3527ffffff → 0x04000000
11.421906 tegra194-pcie 140a0000.pcie: IO 0x002a100000…0x002a1fffff → 0x002a10000
11.422073 tegra194-pcie 140a0000.pcie: iATU unroll: enabled
11.422074 tegra194-pcie 140a0000.pcie: Detected iATU regions: 8 outbound, 2 inbound
11.528741 tegra194-pcie 140a0000.pcie: Link up
11.530241 tegra194-pcie 140a0000.pcie: Link up
11.530396 tegra194-pcie 140a0000.pcie: PCI host bridge to bus 0008:00
11.530401 pci_bus 0008:00: root bus resource [io 0x300000-0x3ffff] (bus address [0x2a10000-0x2a1ffff])
11.530405 pci_bus 0008:00: root bus resource [mem 0x3528000000-0x3527ffffff] (bus address [0x40000000-0x47ffffff])
11.530410 pci_bus 0008:00: root bus resource [bus 00-ff]
11.530412 pci_bus 0008:00: root bus resource [mem 0x3240000000-0x3527fffffff pref]
11.530456 pci 0008:00:00.0: [10de:229c] type 01 class 0x060400
11.530627 pci 0008:00:00.0: PME# supported from D0 D3hot
11.535847 pci 0008:01:00.0: [10ec:8168] type 00 class 0x020000
11.536212 pci 0008:01:00.0: reg 0x10: [io 0x0000-0x00ff]
11.536323 pci 0008:01:00.0: reg 0x18: [mem 0x00000000-0x00003fff 64bit]
11.536332 pci 0008:01:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit]
11.537224 pci 0008:01:00.0: supports D1 D2
11.537246 pci 0008:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
11.556219 pci 0008:01:00.0: BAR 14: assigned [mem 0x3528000000-0x35280fffff]
11.556231 pci 0008:01:00.0: BAR 13: assigned [io 0x300000-0x300fff]
11.556239 pci 0008:01:00.0: BAR 4: assigned [mem 0x3528000000-0x3528003fff 64bit]
11.556323 pci 0008:01:00.0: BAR 2: assigned [mem 0x3528004000-0x3528004fff 64bit]
11.556428 pci 0008:01:00.0: BAR 0: assigned [io 0x300000-0x300fff]
11.556457 pci 0008:00:00.0: PCI bridge to [bus 01-ff]
11.556460 pci 0008:00:00.0: bridge window [io 0x300000-0x300fff]
11.556461 pci 0008:00:00.0: bridge window [mem 0x3528000000-0x35280fffff]
11.556751 pcieport 0008:00:00.0: Adding to iommu group 8
11.556992 pcieport 0008:00:00.0: PME: Signaling with IRQ 189
11.557215 pcieport 0008:00:00.0: AER: enabled with IRQ 189
No key available with this passphrase.
/bin/bash: line 1: crypt_UDA: command not found
11.930421 ERROR: fail to unlock the encrypted dev /dev/mmcblk0p2.
11.916471 Kernel panic - not syncing:
11.916473 Attempted to kill init! exitcode=0x00007f00
11.916473 CPU: 0 PID: 1 Comm: bash Tainted: G E 5.15.148-tegra #1
11.916477 Hardware name: NVIDIA NVIDIA Jetson Orin Nano Developer Kit/Jetson, BIOS 36.4.3-gcid-38968081 01/08/2025
11.916491 Call trace:
11.916498 dump_backtrace+0x0/0x1d0
11.916493 show_stack+0x34/0x50
11.916498 dump_stack_lvl+0x68/0x8c
11.916501 dump_stack+0x18/0x3c
11.916505 panic+0xc4/0x398
11.916511 do_exit+0xa04/0xa30
11.916515 do_group_exit+0x44/0xb0
11.916518 __arm64_sys_exit_group+0x2c/0x30
11.916521 invoke_syscall+0x5c/0x150
11.916525 el0_svc_common.constprop.0+0x64/0x120
11.916529 do_el0_svc+0x74/0xb0
11.916532 el0_svc+0x28/0x90
11.916533 el0t_64_sync_handler+0xac/0x130
11.916533 el0t_64_sync+0x1a4/0x1a8

15

hello nik01flink,

let me double check…

you’re working with Orin Nano developer kit, and it’s Jetpack-6.2/r36.4.3 public release version?

according to the failure…

it’s usually due to an incorrect EKS image, did you execute gen_ekb.py to re-generate an EKS image?
besides, why there’s /dev/mmcblk0p2 partition? may I know what’s your flash commands in details.

16

Hey JerryChang,

you’re working with Orin Nano developer kit, and it’s Jetpack-6.2/r36.4.3 public release version?

Yes, that is correct.

it’s usually due to an incorrect EKS image, did you execute gen_ekb.py to re-generate an EKS image?

No, I did not execute gen_ekb.py to generate the EKS image. I guess you mean this command?

$ python3 gen_ekb.py -chip t234
                     -oem_k1_key <oem_k1.key> \
                     -in_auth_key <auth_t234.key> \
                     -out <eks_t234.img>

I tried this once before, but after I flashed with this image, I only had the desktop (no downloads, no personal folders, …). That made me a bit insecure, but the crucial point was that not even the random number generator of the hwkey-agent sample worked anymore. That’s why I went back to the old image. That was before using the l4t_initrd_flash.sh though, I used nvautoflash.sh before.

why there’s /dev/mmcblk0p2 partition

Hm, it seems it is a partition of the 512GB microSD-Card i am using? This is the output on the jetson after executing “lsblk”:

NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0      179:0    0 476,7G  0 disk 
├─mmcblk0p1  179:1    0 475,3G  0 part /
├─mmcblk0p2  179:2    0   128M  0 part 
├─mmcblk0p3  179:3    0   768K  0 part 
├─mmcblk0p4  179:4    0  31,6M  0 part 
├─mmcblk0p5  179:5    0   128M  0 part 
├─mmcblk0p6  179:6    0   768K  0 part 
├─mmcblk0p7  179:7    0  31,6M  0 part 
├─mmcblk0p8  179:8    0    80M  0 part 
├─mmcblk0p9  179:9    0   512K  0 part 
├─mmcblk0p10 179:10   0    64M  0 part /boot/efi
├─mmcblk0p11 179:11   0    80M  0 part 
├─mmcblk0p12 179:12   0   512K  0 part 
├─mmcblk0p13 179:13   0    64M  0 part 
├─mmcblk0p14 179:14   0   400M  0 part 
└─mmcblk0p15 179:15   0 479,5M  0 part 
zram0        252:0    0   635M  0 disk [SWAP]
zram1        252:1    0   635M  0 disk [SWAP]
zram2        252:2    0   635M  0 disk [SWAP]
zram3        252:3    0   635M  0 disk [SWAP]
zram4        252:4    0   635M  0 disk [SWAP]
zram5        252:5    0   635M  0 disk [SWAP]

And last but not least this is the Makefile I am using to flash my jetson orin nano. You can find the flashing-commands in the last paragraph:

JP ?= <invalid path>
TA ?= <invalid path>
MODEL ?= 234

DEV ?= /dev/sda
F_IMG ?= <select img>

NPROCS := 1
JETPACK_PTH := $(PWD)/$(JP)
TOOLCHAIN := $(JETPACK_PTH)/toolchain
KERNEL_TARGET := $(JETPACK_PTH)/target/Linux_for_Tegra
PUBLIC_SRC := $(KERNEL_TARGET)/source
OPTEE_SRC := $(PUBLIC_SRC)/jetson-optee-srcs/nvidia-jetson-optee-source
KERNEL_SRC := $(PUBLIC_SRC)/kernel
KERNEL_HEADERS := $(PUBLIC_SRC)/kernel/kernel-jammy-src

CROSS_COMPILE := $(TOOLCHAIN)/bin/aarch64-buildroot-linux-gnu-
TA_DEVKIT_DIR := $(OPTEE_SRC)/optee/build/t$(MODEL)/export-ta_arm64/
OPTEE_CLIENT_EXPORT := $(OPTEE_SRC)/optee/install/t$(MODEL)/usr
TEEC_EXPORT := $(OPTEE_SRC)/optee/install/t$(MODEL)/usr

CARGS := CROSS_COMPILE=$(CROSS_COMPILE) \
	 KERNEL_HEADERS=$(KERNEL_HEADERS) \
	 INSTALL_MOD_PATH=$(KERNEL_TARGET)/rootfs 

kernel:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make -C kernel && \
		$(CARGS) sudo -E make install -C kernel

config:
	./scripts/set-config.sh -i $(JP)/configs/defconfig -k $(KERNEL_HEADERS)


modules:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make modules && \
		$(CARGS) sudo -E make modules_install && \
	cd $(KERNEL_TARGET) && \
		sudo ./tools/l4t_update_initrd.sh

dtbs:
	cd $(PUBLIC_SRC) && \
		$(CARGS) make dtbs && \
		cp kernel-devicetree/generic-dts/dtbs/* $(KERNEL_TARGET)/kernel/dtb

flash:
	cd $(KERNEL_TARGET) && \
	sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
		--showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
		--no-flash jetson-orin-nano-devkit internal && \
	echo "f0e0d0c0b0a001020304050607080900" > disk_encr.key && \
	sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
		--showlogs --no-flash --external-device mmcblk0p1 -S 16GiB \
		-c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
		--external-only --append -i ./disk_encr.key jetson-orin-nano-devkit external && \
	sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs --flash-only

			
all: config kernel modules dtbs flash
	say done

For your information: To use this makefile, I am going into /home/jetpack/ and execute the following:

extern JP=jp62
make all
17

hello nik01flink,

let’s resolve this failure first,
please re-generate EKS image by including your user keys for confirmation.

18

Hey JerryChang,

I got it working … 😅 It was simply because I did not copy the sym2_t234.key into the Linux_for_Tegra directory after creating the image. Hwkey-agent works perfectly now.

Thanks your help!

20

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