RAS Error, IERR = SCF to L2 Decode Error Read (trusty, optee)

Hi everyone,
We are running into the RAS Error during flash and then Recursive CPU error after we boot our device with JP 5.1.2. We have noticed that these errors go away if we bypass the trusty/Optee steps described below. Note that we are not using disk encryption but just generating eks.img (by using gen_tos_part_img.py) and putting it in the bootloader directory as described in the following steps as described below (from Optee/trusty documentation). This is a custom production board. These steps used to work in the JP 4.x previously. We have not changed any keys. Our flash command looks like following. The bootloader fails in the beginning without getting to kernel. I have attached flash uart logs and then the boot that happens right after it. Any tips or hints to what we may be doing wrong is greatly appreciated.
Thank you.
flash_and_boot_uart.log (240.0 KB)

Flash -u key1 -v key2 jetson-xavier-nx-devkit-emmc mmcblk0p1

Steps we executed form documentation:
To generate the tos.img with ATF and Trusty images:

  1. Unpack the L4T tarball from the BSP package.
    tar xpf Jetson_Linux_R_aarch64.tbz2
  2. Copy the ATF image bl31.bin and Trusty image lk.bin to this directory.
    <Linux_for_Tegra>/nv_tegra/tos-scripts
  3. Generate the tos.img with the commands:
    cd <Linux_for_Tegra>/nv_tegra/tos-scripts/
    • Jetson Xavier:
      ./gen_tos_part_img.py --monitor bl31.bin --os lk.bin tos_t194.img

Applying tos-mon-only_t194.img file in this thread did not work for us

Any help would be appreciated.

hello KavehA,

did you used the same version of sources release package? i.e. jetson-linux-r3541.
there should be optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to create EKS image.

Hi JerryChang,
Thank you for getting back to us, we are downloading: https://developer.nvidia.com/downloads/embedded/l4T/r35_release_v4.1/sources/public_sources.tbz2 for the jetpack5.1.2, and then extracting atf_src.tbz2.
We are going based on the:
…trusty/app/sample/hwkey-agent/CA_sample/tool/gen_ekb/example.sh
(note that this is in the CA_sample and not host directory).

here is what we execute:
…trusty/app/sample/hwkey-agent/CA_sample/tool/gen_ekb/gen_ekb.py
-kek2_key keys/kek2
-fv keys/kek2_iv
-in_sym_key keys/sym.key
-out scripts/trusty/eks.img

and then copy eks.img to the bootloader directory

We have been using the atf_src.tbz2 package for BSP 4.x, has anything changed for BSP 5.1.2 and do we need to use the nvidia-jetson-optee-source.tbz2 package now?

yes, please using nvidia-jetson-optee-source.tbz2 since JP-5.x is now using OP-TEE.

Thank you, do you know which files on the Jetson NX need to be updated once we migrate upgrade our devices from 4.x to 5.1.2, our upgrade process is manual; is it image in the /boot directory or are there other files? We do not want to flash every device for our upgrade since some of them are remote running in production.

hello KavehA,

I had never try updating from JP-4.x to JP-5.x manually.
anyways, there’re secure-os, (tos-optee_t194_sigheader.img.encrypt) and eks (eks_t194_sigheader.img.encrypt) partitions they’re related to OP-TEE.
you may give it a try to update these two for confirmation.

That is very helpful, thank you JerryChang,
With trusty (previous version in JP 4.x) we used to generate the eks.img also using our keys (see below). Has this step been eliminated from JP5 or can we still generate the eks.img this way.

gen_ekb.py
-kek2_key $(KEY1)
-fv $(KEY2)
-in_sym_key $(SYMET_KEY)
-out eks.img

hello KavehA,

please refer to sample script, optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to create EKS image with your own keys.

Thank you JerryChang
I noticed that the new gen_ekb.py program in the above example takes an additional key (compared to the older version), it is the in_sym_key2 key, a 16 byte hex key. I assume that we just need to generate this key on the build machine and the device does not need to know (or be fused) with/about this key. Is that correct?

FYI,
EKB (Encrypted Binary Blob) stores two keys, one is the kernel encryption key (sym_key_file), and another one is the LUKS key (sym2_key_file) for disk encryption support.
LUKS disk encryption support with a specific key. you should execute the script file, gen_ekb.py to generate an image. also, in the developer guide, [Tool for EKB Generation] that sym2.key is equivalent to ekb.key

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