Possible OPTEE and CAAM conflict on JR0 (jobring)

pfarre · January 6, 2026, 1:19pm

Hi,

OPTEE fails reading RPMB and CAAM fails loading key-blob for encryption

(BSP 7.5.0 kernel 6.6.117 , clean build from new repo )

INHERIT += “tdx-optee”     
TDX_ENC_KEY_BACKEND = “caam”

chatGPT suggests that OPTEE and CAAM are both trying to use JR0

dmesg grep optee :

[    0.000000] OF: reserved mem: 0x9e000000..0x9effffff (16384 KiB) nomap non-reusable optee
[    1.180641] optee: probing for conduit method.
[    1.185172] optee: revision 4.4 (ecea75b7)
[    1.185639] optee: dynamic shared memory is enabled
[    1.195354] optee: initialized driver

dmesg grep caam:

[    4.937027] caam 30900000.crypto: device ID = 0x0a16030000000000 (Era 8)
[    4.958920] caam 30900000.crypto: job rings = 3, qi = 0
[    5.015068] caam_jr 30901000.jr: failed to flush job ring 0
[    5.026910] caam_jr: probe of 30901000.jr failed with error -5
[    5.055443] caam algorithms registered in /proc/crypto
[    5.076998] caam 30900000.crypto: caam pkc algorithms registered in /proc/crypto
[    5.088236] caam 30900000.crypto: registering rng-caam
[    5.094006] caam 30900000.crypto: rng crypto API alg registered prng-caam

dmesg grep key

[    0.116150] Initialise system trusted keyrings
[    0.117262] Key type asymmetric registered
[    0.117301] Asymmetric key parser 'x509' registered
[    5.118118] Key type trusted registered
[    5.600948] trusted_key: key_unseal failed (-74)
[   10.926844] trusted_key: key_unseal failed (-74)

and output from > systemctl status tdx-enc-handler.service

x tdx-enc-handler.service - Encryption handler for Toradex modules
     Loaded: loaded (/usr/lib/systemd/system/tdx-enc-handler.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-01-06 10:45:34 UTC; 2h 26min ago
    Process: 506 ExecStart=/usr/sbin/tdx-enc.sh start (code=exited, status=1/FAILURE)
   Main PID: 506 (code=exited, status=1/FAILURE)
        CPU: 378ms

Jan 06 10:45:34 localhost tdx-enc.sh[506]: caam: Preparing and checking system (caam)...
Jan 06 10:45:34 localhost tdx-enc.sh[506]: caam: Setting up encryption key for CAAM backend...
Jan 06 10:45:34 localhost tdx-enc.sh[506]: caam: Configuring key in kernel keyring (type=trusted keyna...nc)...
Jan 06 10:45:34 localhost tdx-enc.sh[564]: 1004556894
Jan 06 10:45:34 localhost tdx-enc.sh[506]: caam: Encrypted key exists. Importing it...
Jan 06 10:45:34 localhost tdx-enc.sh[567]: add_key: Bad message
Jan 06 10:45:34 localhost tdx-enc.sh[506]: caam: ERROR: Error adding key to kernel keyring!
Jan 06 10:45:34 localhost systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, stat...FAILURE
Jan 06 10:45:34 localhost systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.
Jan 06 10:45:34 localhost systemd[1]: Failed to start Encryption handler for Toradex modules.
Hint: Some lines were ellipsized, use -l to show in full.

Best Regards - Paul

ToradexAI · January 6, 2026, 1:19pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I can see you’re experiencing a CAAM/OP-TEE conflict where both components are trying to access the same Job Ring (JR0), resulting in encryption failures on your BSP 7.5.0 system.

Problem Analysis

The logs show two key issues:

CAAM Job Ring Conflict: The error caam_jr 30901000.jr: failed to flush job ring 0 and probe of 30901000.jr failed with error -5 indicates JR0 is unavailable (1)
Key Import Failure: The trusted_key: key_unseal failed (-74) and add_key: Bad message errors show CAAM cannot properly handle the encryption key (1)

This is a known synchronization issue between OP-TEE and CAAM services during startup (1).

Platform Information Needed

To provide the most accurate solution, could you specify:

Which SoM are you using? (You can run tdx-info to get this information: Getting Device Information with Tdx-Info | Toradex Developer Center)
Are you using secure boot/device closure?
What’s your complete local.conf configuration?

Potential Solutions

1. Device Tree Configuration

The issue often stems from both OP-TEE and Linux trying to use the same CAAM Job Ring. You may need to configure the device tree to allocate different Job Rings to each component (1).

2. Service Dependencies

There are known synchronization issues with startup services that mount encrypted partitions and handle encryption (1). The tdx-enc-handler.service may be starting before OP-TEE is fully initialized.

3. Secure Boot Considerations

If you’re testing without secure boot enabled, CAAM uses a fixed test key which can cause conflicts. With secure boot enabled, CAAM uses the OTPMK key for better security (1).

Immediate Troubleshooting Steps

Check OP-TEE Status:
```
systemctl status tee-supplicant
```
Verify Device Tree Configuration:
Check if your device tree properly allocates CAAM Job Rings between OP-TEE and Linux.
Review Service Order:
The encryption handler needs to run after OP-TEE is fully initialized.

This appears to be a known issue that our technical team is working on (1). Once you provide your platform details, I can offer more specific guidance for your configuration.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

pfarre · January 6, 2026, 1:22pm

@ToradexAI

Additional info

 systemctl status tee-supplicant
Unit tee-supplicant.service could not be found.

 tdx-info
cat: /etc/hostname: No such file or directory

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.117-7.5.0-devel #1 SMP PREEMPT Mon Nov 24 09:30:14 UTC 2025
Kernel command line:      ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=dbf591a5-02
Distro name:              NAME="TDX Wayland with XWayland Upstream"
Distro version:           VERSION_ID=7.5.0-devel-20260105082212-build.0
Distro variant:           -
Hostname:                 -
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version:          0039 V1.1B
Serial number:            12827576
Processor arch:           armv7l
------------------------------------------------------------

ToradexAI · January 6, 2026, 1:22pm

Platform Confirmed - Colibri iMX7D 1GB eMMC

Thank you for providing the platform information. You’re using a Colibri iMX7D 1GB (eMMC) module, which helps narrow down the issue (1).

OP-TEE Service Issue

The missing tee-supplicant.service indicates that OP-TEE may not be properly configured for your Colibri iMX7D module. According to the current OP-TEE support status, Colibri iMX7D (1GB eMMC variant only) is supported, but there have been ongoing development efforts (2).

Key Findings from Community Discussion

Based on recent community discussions about OP-TEE support on iMX7D:

Limited Current Support: At present, OP-TEE support for Colibri iMX7D is still being actively worked on (2)
Development Status: OP-TEE support for all modules is on the security roadmap and being actively developed (2)
Configuration Requirements: For Colibri iMX7D, specific configuration parameters are needed (2)

CAAM Configuration for Colibri iMX7D

The Colibri iMX7D has specific hardware characteristics that affect CAAM operation (3)(4):

USB Configuration: The module provides dual USB 2.0 High-Speed ports with specific controller configurations (3)
Power Management: Specific reset and power management signals that may affect CAAM initialization (4)

Recommended Actions

1. Verify OP-TEE Configuration

Since tee-supplicant.service is missing, OP-TEE may not be fully configured for your platform. You may need to:

Ensure your BSP build includes the proper OP-TEE configuration for Colibri iMX7D
Verify that the tdx-optee class is properly inherited and configured

2. Alternative Approach

Given the current development status, you might consider:

Using a different encryption backend temporarily
Waiting for the completed OP-TEE implementation for Colibri iMX7D
Contributing to the development effort if your timeline permits

3. Check Build Configuration

Verify your local.conf includes all necessary configurations for both OP-TEE and CAAM on iMX7D.

The CAAM/OP-TEE conflict you’re experiencing appears to be related to the ongoing development work for full OP-TEE support on Colibri iMX7D platforms (2).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

pfarre · January 6, 2026, 1:27pm

@ToradexAI

 tee-supplicant
ERR [920] TSUP:main:922: failed to find an OP-TEE supplicant device

But /dev/tee0 and /dev/teepriv0 exist

AND

dmesg | grep -i tee
[    0.000000] OF: reserved mem: 0x9e000000..0x9effffff (16384 KiB) nomap non-reusable optee
[    1.180641] optee: probing for conduit method.
[    1.185172] optee: revision 4.4 (ecea75b7)
[    1.185639] optee: dynamic shared memory is enabled
[    1.195354] optee: initialized driver

ToradexAI · January 6, 2026, 1:28pm

OP-TEE Status Analysis

Your logs show that OP-TEE is partially working but has a device discovery issue. The key indicators are:

Positive Signs

OP-TEE kernel driver initialized successfully: optee: initialized driver (1)
OP-TEE revision 4.4 is detected and loaded (1)
Device nodes /dev/tee0 and /dev/teepriv0 exist (1)
Dynamic shared memory is enabled (1)

The Core Issue

The error failed to find an OP-TEE supplicant device suggests a communication problem between the userspace tee-supplicant and the OP-TEE kernel driver, despite the device nodes existing.

Troubleshooting Steps

1. Check OP-TEE Device Permissions

ls -la /dev/tee*

2. Verify OP-TEE Test Functionality

Since OP-TEE appears to be loaded, test if basic functionality works:

optee_example_hello_world

3. Manual tee-supplicant Start

Try starting the supplicant with debug output:

tee-supplicant -d

4. Check CAAM Job Ring Allocation

The original CAAM error suggests Job Ring 0 conflict. Check which job rings are available:

ls -la /dev/caam*

Root Cause Analysis

Based on your logs, this appears to be a device tree configuration issue where:

OP-TEE loads successfully at kernel level (2)
CAAM fails to initialize JR0 due to conflict with OP-TEE (2)
tee-supplicant cannot establish proper communication with the OP-TEE driver (2)

The device tree may need specific configuration to properly allocate CAAM Job Rings between OP-TEE (secure world) and Linux (normal world) (1)(2).

Immediate Solution Attempt

Try manually starting the encryption service after ensuring OP-TEE is responsive:

# Test OP-TEE first
optee_example_hello_world

# If that works, try the encryption service
systemctl start tdx-enc-handler.service
systemctl status tdx-enc-handler.service

This suggests the issue is more about service timing and device tree configuration rather than complete OP-TEE failure. The fact that OP-TEE initializes but tee-supplicant fails indicates a userspace-kernel communication problem that may be resolved with proper device tree Job Ring allocation (1)(2).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

pfarre · January 6, 2026, 1:56pm

@ToradexAI

>ls -la /dev/tee*
crw-rw---- 1 root teeclnt 246,  0 Jan  6 10:45 /dev/tee0
crw-rw---- 1 root root    246, 16 Jan  6 10:45 /dev/teepriv0

>optee_example_hello_world
Invoking TA to increment 42
TA incremented value to 43

 tee-supplicant -d
ERR [930] TSUP:main:908: make_daemon(): -1

>ls -la /dev/caam*
ls: cannot access '/dev/caam*': No such file or directory

 systemctl start tdx-enc-handler.service
[10049.543037] EXT4-fs (mmcblk0p4): VFS: Can't find ext4 filesystem
[10049.549821] EXT4-fs (mmcblk0p4): VFS: Can't find ext4 filesystem
[10049.556828] EXT4-fs (mmcblk0p4): VFS: Can't find ext4 filesystem
[10049.563869] FAT-fs (mmcblk0p4): invalid media value (0xc5)
[10049.569470] FAT-fs (mmcblk0p4): Can't find a valid FAT filesystem
[10049.576078] exFAT-fs (mmcblk0p4): invalid boot record signature
[10049.582120] exFAT-fs (mmcblk0p4): failed to read boot sector
[10049.587833] exFAT-fs (mmcblk0p4): failed to recognize exfat type
[10049.795227] trusted_key: key_unseal failed (-74)
Job for tdx-enc-handler.service failed because the control process exited with error code.
See "systemctl status tdx-enc-handler.service" and "journalctl -xeu tdx-enc-handler.service" for details.

>systemctl status tdx-enc-handler.service -l
x tdx-enc-handler.service - Encryption handler for Toradex modules
     Loaded: loaded (/usr/lib/systemd/system/tdx-enc-handler.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-01-06 13:32:52 UTC; 1min 14s ago
    Process: 935 ExecStart=/usr/sbin/tdx-enc.sh start (code=exited, status=1/FAILURE)
   Main PID: 935 (code=exited, status=1/FAILURE)
        CPU: 371ms

Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[935]: caam: Preparing and checking system (caam)...
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[935]: caam: Setting up encryption key for CAAM backend...
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[935]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[976]: 566095592
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[935]: caam: Encrypted key exists. Importing it...
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[979]: add_key: Bad message
Jan 06 13:32:52 colibri-imx7-emmc-12827576 tdx-enc.sh[935]: caam: ERROR: Error adding key to kernel keyring!
Jan 06 13:32:52 colibri-imx7-emmc-12827576 systemd[1]: tdx-enc-handler.service: Main process exited, code=exited, status=1/FAILURE
Jan 06 13:32:52 colibri-imx7-emmc-12827576 systemd[1]: tdx-enc-handler.service: Failed with result 'exit-code'.
Jan 06 13:32:52 colibri-imx7-emmc-12827576 systemd[1]: Failed to start Encryption handler for Toradex modules.

ToradexAI · January 6, 2026, 1:57pm

Excellent Progress - OP-TEE is Working!

Your troubleshooting shows significant progress:

What’s Working

OP-TEE functionality confirmed: optee_example_hello_world successfully incremented 42 to 43 (1)
Device permissions correct: /dev/tee0 and /dev/teepriv0 have proper ownership and permissions (1)
OP-TEE driver fully operational: The trusted application executed successfully (1)

Identified Issues

CAAM Device Missing: No /dev/caam* devices exist, which explains the encryption key failures (2)
Partition Problems: mmcblk0p4 shows filesystem corruption/invalid format (2)
Key Import Failure: trusted_key: key_unseal failed (-74) and add_key: Bad message (2)

Root Cause Analysis

The core issue is that CAAM hardware is not properly initialized due to the Job Ring conflict we identified earlier. The missing /dev/caam* devices confirm that CAAM driver failed to probe successfully (2).

From your earlier logs:

[    5.015068] caam_jr 30901000.jr: failed to flush job ring 0
[    5.026910] caam_jr: probe of 30901000.jr failed with error -5

This means CAAM cannot create the trusted keys needed for encryption (2).

Solutions to Try

1. Device Tree Configuration Fix

The CAAM Job Ring allocation needs to be properly configured in the device tree to avoid conflicts with OP-TEE (1)(3). You may need to modify your device tree to:

Allocate different Job Rings to OP-TEE vs Linux
Ensure proper CAAM initialization sequence
Configure Job Ring availability correctly (1)(3)

2. Alternative Encryption Backend

Since CAAM is failing, consider temporarily switching to a different encryption backend. Based on the data-at-rest encryption documentation, you can use:

TDX_ENC_KEY_BACKEND = "cleartext"  # For testing only

3. Partition Setup

The mmcblk0p4 partition appears corrupted. You may need to:

Recreate the partition using tdx-tezi-data-partition (2)
Ensure proper partition formatting before encryption attempts (2)

4. Check Build Configuration

Verify your local.conf has the correct Job Ring configuration for Colibri iMX7D with both OP-TEE and CAAM enabled (1)(3).

Next Steps

Fix the device tree to properly allocate CAAM Job Rings (1)(3)
Rebuild and reflash with corrected device tree configuration
Verify CAAM devices appear after proper initialization
Test encryption once CAAM hardware is accessible

The good news is OP-TEE is fully functional, so the issue is specifically with CAAM hardware initialization and Job Ring allocation (1)(3).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

jeremias.tx · January 6, 2026, 6:46pm

Greetings @pfarre,

Just to make sure we understand. You want to use both Optee and the data-at-rest encryption features at the same time?

The current theory is that perhaps there is a conflict with both features trying to access a resource at the same time. Have you tried enabling just Optee or just the encryption functionality, to see if these work individually? Just to confirm whether this theory seems plausible or not.

Best Regards,
Jeremias

pfarre · January 7, 2026, 6:11am

Hi Jeremias,

yes , both are enabled. (important overlay directories are on encrypted partition and keys in optee).

The ‘tee’ directory is on mmcblk0p3 = /data/tee and the encrypted partition is mmcblk0p4 - until recently it was correct mounted on /run/encdata

I will investigate wether its OPTEE in ‘factory’ mode, that led to the new problems or locking the device or other possibilities.

Do you have input for devicetree or local.conf settings to explicitly assign jobrings to OPTEE and CAAM?

This is the chatGPT suggestion:

&caam_jr0 {
    status = "disabled";   // OP-TEE will use JR0
};

&caam_jr1 {
    status = "okay";       // Linux uses JR1
};

&caam_jr2 {
    status = "okay";       // Optional second ring
};

Best Regards - Paul

pfarre · January 7, 2026, 12:53pm

Hi,

so far (soc is not fused yet) but - adding to a .dtbo

    fragment@3 {
        target-path = "/soc/bus@30800000/crypto@30900000/jr@1000";
        __overlay__ {
            status = "disabled";
        };
    };

the jobring error is gone from caam, and the /run/encdata is mounted

[ 4.966700] caam 30900000.crypto: device ID = 0x0a16030000000000 (Era 8)
[ 5.373389] caam 30900000.crypto: job rings = 2, qi = 0
[ 5.431723] caam algorithms registered in /proc/crypto
[ 5.437186] caam 30900000.crypto: caam pkc algorithms registered in /proc/crypto
[ 5.437207] caam 30900000.crypto: registering rng-caam
[ 5.563301] caam 30900000.crypto: rng crypto API alg registered prng-caam

BR - Paul

jeremias.tx · January 7, 2026, 6:02pm

he jobring error is gone from caam, and the /run/encdata is mounted

Interesting so disabling the jr0 jobring seems to make the errors disappear in your setup. Which does support the theory that CAAM and Optee were somehow conflicting over the resource.

I’ll bring this up and discuss this internally with our team to see if this is really the case.

Best Regards,
Jeremias

jeremias.tx · January 7, 2026, 9:34pm

After some discussion with the team there seems to be a discrepancy with your results. We test OS images built from meta-toradex-security frequently on our own CI/CD pipeline. These images have Optee with data-at-rest encryption enabled similar to your image here. We’re not seeing the same errors as you in our pipeline.

However, I recall from your other thread that you’re using Optee with the RPMB support enabled, is that still correct?

We don’t have that enabled in our test images, so maybe this is the key factor. Could you try doing a build with RPMB disabled, as is the default configuration with Optee. That way it matches our own tests. Then see if you get errors in this case. If you still get errors then there must be some other difference in your setup. If you don’t get errors like our test show, then that would mean it’s the addition of RPMB that causes these errors and our team can investigate this.

Best Regards,
Jeremias

pfarre · January 8, 2026, 6:12am

@jeremias.tx

if i understand you right, you dont build images and run TDX_OPTEE_FS_RPMB_MODE through “factory” and “production” setting.

The variable then defaults

TDX_OPTEE_FS_RPMB_MODE ?= "development"

Best Regards - Paul

jeremias.tx · January 8, 2026, 5:54pm

You misunderstand. I mean in our test images we have RPMB disabled completely. As in the value of TDX_OPTEE_FS_RPMB is at it’s default (i.e 0). So no RPMB functionality is being utilized at all.

I’m asking if you could create a test image that has Optee and the data-at-rest encryption functions enabled but disable the RPMB functionality. This way it matches more closely with our test images where we currently observe no errors. That way we can have a baseline comparison. This would hopefully help to indicate whether the issue is specifically the optional RPMB functionality or something else.

Best Regards,
Jeremias

pfarre · January 12, 2026, 6:27am

Hi,

keeping TDX_OPTEE_FS_RPMB at default does not remove the caam job-ring flush error.

supplementary info, config.gz :

CONFIG_TRUSTED_KEYS_CAAM=y
CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON=m
CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC=m
CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API_DESC=m
CONFIG_CRYPTO_DEV_FSL_CAAM=m
# CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG is not set
CONFIG_CRYPTO_DEV_FSL_CAAM_JR=m
CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9
# CONFIG_CRYPTO_DEV_FSL_CAAM_INTC is not set
CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_PRNG_API=y
CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN=y
# CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_TEST is not set

BR - Paul

jeremias.tx · January 12, 2026, 9:58pm

keeping TDX_OPTEE_FS_RPMB at default does not remove the caam job-ring flush error.

Okay so even with RPMB disabled the issue still occurs. Is it just the job-ring issue, or do you also still get the error from the encryption handler service?

Your findings are not consistent with our own tests so far. As said previously our CI/CD testing has images with both the data-at-rest encryption enabled and Optee enabled (no RPMB). We’re not seeing such errors there. The devices used for the test do have their secure boot fuses closed, but this shouldn’t matter for what you are seeing here.

Are you doing any other non-default changes or configurations in your build?

Best Regards,
Jeremias

jeremias.tx · January 13, 2026, 10:01pm

So I did a test build myself to confirm first-hand. This the minimal build configuration I used:

ACCEPT_FSL_EULA = "1"
INHERIT += "tdx-signed tdx-optee tdx-encrypted tdx-tezi-data-partition"
TDX_IMX_HAB_CST_DIR = "/build/coj/BSP/layers/cst"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk0p3"
TDX_OPTEE_INSTALL_TESTS = "1"

The tdx-tezi-data-partition was only added to have a test partition to be used alongside the data-at-rest-encryption. The Colibri i.MX7 EMMC I used was not fused close.

I observed the following from this image:

root@colibri-imx7-emmc-06476398:~# dmesg | grep -i caam
[    6.520908] caam 30900000.crypto: device ID = 0x0a16030000000000 (Era 8)
[    6.520934] caam 30900000.crypto: job rings = 3, qi = 0
[    6.622344] caam_jr 30901000.jr: failed to flush job ring 0
[    6.755392] caam_jr: probe of 30901000.jr failed with error -5
[    6.803036] caam algorithms registered in /proc/crypto
[    6.810567] caam 30900000.crypto: caam pkc algorithms registered in /proc/crypto
[    6.823147] caam 30900000.crypto: registering rng-caam
[    6.828645] caam 30900000.crypto: rng crypto API alg registered prng-caam
[    6.952105] caam_jr 30903000.jr: using insecure test key, enable HAB to use unique device key!
root@colibri-imx7-emmc-06476398:~# dmesg | grep -i optee
[    0.000000] OF: reserved mem: 0x8c000000..0x8cffffff (16384 KiB) nomap non-reusable optee
[    1.308813] optee: probing for conduit method.
[    1.313348] optee: revision 4.4 (ecea75b7)
[    1.313820] optee: dynamic shared memory is enabled
[    1.323470] optee: initialized driver
root@colibri-imx7-emmc-06476398:~# journalctl -n 100 -f -u tdx-enc-handler
May 29 18:48:26 localhost systemd[1]: Starting Encryption handler for Toradex modules...
May 29 18:48:26 localhost tdx-enc.sh[132]: caam: Attempting partition pre-mount
May 29 18:48:26 localhost tdx-enc.sh[132]: caam: Data preservation is not enabled
May 29 18:48:26 localhost tdx-enc.sh[132]: caam: Unmounting partition ready to encrypt...
May 29 18:48:26 localhost tdx-enc.sh[132]: caam: Preparing and checking system (generic)...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Blocks to be encrypted: 3768320...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Reserved blocks: 0...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Preparing and checking system (caam)...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Setting up encryption key for CAAM backend...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Configuring key in kernel keyring (type=trusted keyname=tdxenc)...
May 29 18:48:27 localhost tdx-enc.sh[161]: 169879522
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Key blob not found. Creating it...
May 29 18:48:27 localhost tdx-enc.sh[132]: caam: Setting up partition with dm-crypt...
May 29 18:48:30 localhost tdx-enc.sh[169]: Name:              encdata
May 29 18:48:30 localhost tdx-enc.sh[169]: State:             ACTIVE
May 29 18:48:30 localhost tdx-enc.sh[169]: Read Ahead:        256
May 29 18:48:30 localhost tdx-enc.sh[169]: Tables present:    LIVE
May 29 18:48:30 localhost tdx-enc.sh[169]: Open count:        0
May 29 18:48:30 localhost tdx-enc.sh[169]: Event number:      0
May 29 18:48:30 localhost tdx-enc.sh[169]: Major, minor:      254, 0
May 29 18:48:30 localhost tdx-enc.sh[169]: Number of targets: 1
May 29 18:48:31 localhost tdx-enc.sh[132]: caam: Mounting encrypted partition...
May 29 18:48:31 localhost tdx-enc.sh[132]: caam: Formatting encrypted partition with ext4...
May 29 18:48:34 localhost tdx-enc.sh[132]: caam: Data preservation is not enabled
May 29 18:48:34 localhost tdx-enc.sh[132]: caam: Success!
May 29 18:48:34 localhost systemd[1]: Finished Encryption handler for Toradex modules.

Running the xtest utility to validate Optee resulted in no failed tests. So from my side both Optee and the data-at-rest-encryption features are working as expected simultaneously.

From your last test without RPMB, do your observations differ?

Best Regards,
Jeremias

pfarre · January 14, 2026, 6:19am

Hi Jeremias,

can confirm the results look identical.

I did primarily focus on the caam job ring error in dmesg and also did not try it with a locked device.

Best Regards - Paul

jeremias.tx · January 14, 2026, 7:47pm

I did primarily focus on the caam job ring error in dmesg and also did not try it with a locked device.

Wait is the following log message all you are worried about?:

[    6.755392] caam_jr: probe of 30901000.jr failed with error -5
[    6.803036] caam algorithms registered in /proc/crypto

Does this actually cause any issues on your side? At least from my setup you can see both Optee and the encryption handler are working as expected.

If everything is working then I don’t seen what the issue would be. If you’re just worried about the appearance of this log message. I suppose you could just disable the job ring via overlay like you were doing before. But unless this actually effects something I can only assume this log message is non-critical in nature.

Best Regards,
Jeremias