How can I disable OP-TEE on Nvidia Jetson Xavier NX?

My Nvidia Jetson Xavier NX is flashed with Jetson Linux 35.1, which comes with OP-TEE.

I have two questions with respect to OP-TEE:

  1. How can I find out what physical address range has been reserved for OP-TEE?
  2. How can I completely disable OP-TEE so there is no physical address range reserved for OP-TEE?

hello ptrk1,

please refer to developer guide about OP-TEE.
as you can see in flash configuration file, it’s secure-os partition reserved for OP-TEE.
unfortunately, we don’t test the use-case by disabling OP-TEE.

Hi Jerry, thanks for getting back to me. Please excuse my naivety but do you mind highlighting which flash configuration file you’re referring to? Thanks in advance.

hello ptrk1,

assume you install the release image with SDKManger,
you’ll see the cfg file within the default installation path.
for example, ~/nvidia/nvidia_sdk/JetPack_5.0.2_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/t186ref/cfg/flash_t194_uefi_spi_sd_p3668.xml

Hi Jerry, thank you for pointing that out! I’ve found the file and the relevant secure-os section you were referring to as shown below:

<partition_layout version="01.00.0000">
...
        <partition name="secure-os" type="data" oem_sign="true">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 2621440 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename> TOSFILE </filename>
            <description> **Required.** Slot A; contains the trusted OS. </description>
         </partition>
       ...
</partition_layout>

As I understand from looking at this file, this config file determines how the SDKManager flashes/partitions the SD card or eMMC on the Xavier. Is this correct?

My follow-up question is, if I wish to disable OP-TEE (despite knowing it is untested), do I simply remove the above secure-os partition from the config file and try flashing the device via SDKManager?

If it is not possible to disable OP-TEE, how do I go about finding out the physical memory address range that is reserved for OP-TEE once the system is booted? I tried a few different strategies of finding this information such as taking a look through the source code of the bootloader, which I believe is here; however, I wasn’t able to find the answer to my question.

My ultimate objective is to either turn off OP-TEE or if that is not possible, avoid interacting with the memory region reserved for OP-TEE (which requires me to find out the physical memory address that has been reserved for OP-TEE).

hello ptrk1,

that’s correct. this xml file list all the partition flash to the target. you may try removing the above secure-os partition from the config file, but you’ll need to perform flash.sh for image flashing manually.

may I know which l4t release version you’re working with.
this is source of UEFI, and it’s supported start with l4t-35.x release.

Thank you for confirming, I will try to flash the device manually after removing the secure-os partition from the config file and I will report back if I encounter any issues. Also, I’m using Jetson_Linux_R35.1.

hello ptrk1,

you may use mon-only image to disable OP-TEE.
here show the steps for reference.

  1. please modify p3668.conf.common flash configuration file, TOSFILE="bootloader/tos-mon-only_t194.img";
  2. please enter the $OUT/Linux_For_Tegra/bootloader folder, please also setting soft links for the binary file, $ ln -sf tos-mon-only_t194.img tos_t194.img
  3. perform a full flash. $ sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

Hi Jerry, thank you for the detailed instructions. Once I’ve finished flashing the device, what would be the easiest way to confirm that OP-TEE is indeed turned off? Is there some variable in the UEFI bootloader that I can check to confirm that OP-TEE has been turned off?

hello ptrk1,

you may check serial console logs, it’ll print OP-TEE version: to bootloader, you won’t see this message if you’ve disable OP-TEE.

Hi Jerry. Unfortunately, I’ve been having a few problems with flashing my Xavier manually.

The flashing process consistently gets stuck at CPU Bootloader is not running on device.

...
[   7.6626 ] Applet version 01.00.0000
[   8.7760 ] Sending blob
[   8.7762 ] [................................................] 100%
[   9.5566 ] tegrarcm_v2 --boot recovery
[   9.5580 ] Applet version 01.00.0000
[  11.6817 ] tegrarcm_v2 --isapplet
[ 1016.0394 ] tegrarcm_v2 --ismb2
[ 2031.8470 ] tegradevflash_v2 --iscpubl
[ 2031.8505 ] CPU Bootloader is not running on device.

I’ve also attached the entire log to help with debugging: cpu-bootloader-not-running-on-device.txt (62.9 KB)

For context, I am flashing via an x86 laptop (not a VM) running Ubuntu 20.04. I have been able to flash my Xavier several times to Jetson 35.1 using Nvidia’s official SDKManager GUI application on the same laptop without any issues or errors. This is my first time attempting to flash manually via the official command-line tools.

The Xavier device I am using is this one. As per this device’s official documentation, it supports manual flashing via the terminal in addition to automatic flashing via SDKManager.

I downloaded both the Driver Package and Sample Root File System from this link: Jetson Linux 35.1 | NVIDIA Developer

I decided to flash Jetson Linux v35.1 because I’ve been able to successfully flash 35.1 to my device via SDKManager several times already and this is the version of Jetson Linux we’ve been discussing lately.

And I ran all the required terminal commands for a manual flash:

$ tar xf <L4T_RELEASE_PACKAGE>
$ cd Linux_for_Tegra/rootfs/
$ sudo tar xpf ../../<SAMPLE_FS_PACKAGE>
$ cd ..
$ sudo ./apply_binaries.sh
$ sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

However, the manual flash consistently is stuck at CPU Bootloader is not running on device..

I’ve also made the changes you referenced to disable OP-TEE; however, I have reason to believe this issue is unrelated to those changes I’ve made since I’ve been able to consistently generate a valid system.img file as you should be able to see in the logs I attached earlier. The issue seems to arise during the flashing process.

I’ve searched around on this forum for this particular error message already but many posts don’t really have a definitive solution so I was hoping you might be able to lend a hand with debugging? Thank you in advance.

hello ptrk1,

please check developer guide, To Determine Whether the Developer Kit Is in Force Recovery Mode before image flashing.

Hi Jerry, the device is in Force Recovery Mode the entire time I’m attempting to flash it as shown by the output of the lsusb command:

Bus 001 Device 045: ID 0955:7e19 NVIDIA Corp. APX

During the entire duration of the flash, I have the relevant Force Recovery Mode pins shorted on the Xavier with a jumper cable since this is how I do it when I am flashing via the SDKManager GUI tool. I ran the above lsusb command while the ./flash script was still running.

Also, I have noticed that if I wait long enough, the script will just endlessly loop and print CPU Bootloader is not running on device as shown below:

...
[  10.8024 ] tegrarcm_v2 --boot recovery
[  10.8047 ] Applet version 01.00.0000
[  12.4913 ] tegrarcm_v2 --isapplet
[ 1027.8101 ] tegrarcm_v2 --ismb2
[ 2043.6177 ] tegradevflash_v2 --iscpubl
[ 2043.6213 ] CPU Bootloader is not running on device.
[ 3060.4269 ] tegrarcm_v2 --isapplet
[ 4075.2343 ] tegrarcm_v2 --ismb2
[ 5091.0401 ] tegradevflash_v2 --iscpubl
[ 5091.0425 ] CPU Bootloader is not running on device.
[ 6107.8505 ] tegrarcm_v2 --isapplet
[ 7122.6554 ] tegrarcm_v2 --ismb2
[ 8138.4663 ] tegradevflash_v2 --iscpubl
[ 8138.4703 ] CPU Bootloader is not running on device.
[ 9155.2744 ] tegrarcm_v2 --isapplet
[ 10170.0803 ] tegrarcm_v2 --ismb2
[ 11185.8896 ] tegradevflash_v2 --iscpubl
[ 11185.8928 ] CPU Bootloader is not running on device.
...

hello ptrk1,

since this is not an developer kit.
you may contact with seeedstudio for checking r35.1 flash details.

hello ptrk1,

there’s fix on T194 mon-only image to update spd setting, could you please download JetPack 5.1 and use the T194 mon-only image from this release for confirmation.
thanks

BTW,
you may try replacing tos-mon-only_t194.img with attachment, Topic240460_Feb06.7z (27.0 KB)

Hi Jerry, thanks for getting back to me. I tried flashing with JetPack 5.1 and using the T194 mon-only image but I’m still getting the same issue where it is stuck at CPU Bootloader is not running on device as shown below:

[  10.0867 ] tegrarcm_v2 --boot recovery
[  10.0885 ] Applet version 01.00.0000
[  12.2685 ] tegrarcm_v2 --isapplet
[ 1022.1329 ] tegrarcm_v2 --ismb2
[ 2037.9416 ] tegradevflash_v2 --iscpubl
[ 2037.9452 ] CPU Bootloader is not running on device.
[ 3054.7497 ] tegrarcm_v2 --isapplet
[ 4069.5556 ] tegrarcm_v2 --ismb2
[ 5085.3636 ] tegradevflash_v2 --iscpubl
[ 5085.3669 ] CPU Bootloader is not running on device.
[ 6102.1733 ] tegrarcm_v2 --isapplet

Full log is here: error-cpu-bootloader-35-2.txt (47.6 KB)

I tried flashing JetPack 5.1 without making the changes to disable OP-TEE and I have been able to successfully flash the Xavier via the Command Line Tools.

As such, I believe this error is related to the tos-mon-only_t194.img that I’m trying to flash.

May I ask if you have been able to successfully flash a Xavier with tos-mon-only_t194.img? If so, I must be doing something wrong here so maybe it would be helpful to detail your exact steps?

Alternatively, it might be an easier solution if you could disclose the physical address range reserved for OP-TEE if that is possible? That way I can simply avoid interacting with this memory region.

Hey Jerry, just bumping this thread!

hello ptrk1,

may I know what’s your steps in details to replace tos-mon-only_t194.img for image flashing.
for example, had you modify p3668.conf.common, and revise TOSFILE=“bootloader/tos-mon-only_t194.img"; to perform full flash to update that?