Failed to access UART registers from OP-TEE

I changed the line in the tegra234-firewall-config-base.dtsi file, and tried flashing it using the command:
sudo ./ jetson-agx-orin-devkit mmcblk0p1
Then I get the following error:
flash_error.txt (43.5 KB)

I am using this command at the Linux_for_Tegra directory that I downloaded from the L4T35.3.1 webpage.

I also tried flashing using the commands:
sudo ./ -k BCT jetson-agx-orin-devkit mmcblk0p1
sudo ./ -k A_mb2 jetson-agx-orin-devkit mmcblk0p1

I was able to flash it, but when I try to write to the UART-A reset line, I am getting the same firewall error.

Update: I am also unable to write to the clock enable registers for UART-A, but I am able to read from it.

Is there anything under your /home/smanupa/secure-camera/Orin_TEE/Linux_for_Tegra/rootfs/?

Could you flash the whole board successfully with this command before modifying the firewall dtsi?

sudo ./ jetson-agx-orin-devkit mmcblk0p1

There are the standard files that I got, when extracting the source files from the zip file, i.e. ‘boot’ folder, etc, README.txt. The README.txt file says:

Download and extract the sample filesystem to this directory


No, I couldn’t do that. Is it because the location of the Linux_for_Tegra I am working in is at a different location from where the SDK manager was installed? But I am able to flash the modified version of OP-TEE at the present working location itself.

When I copied the modified tegra234-firewall-config-base.dtsi file into the location where the SDK HW target is located, I was able to flash the board completely using the command:

I tried de-asserting the UART-A reset line, but still getting the FIREWALL_ERR.

Please share the result of ls -l in that folder.

Do you get the exact same FIREWALL_ERR?

The output of ls -l in ‘~/secure-camera/Orin_TEE/Linux_for_Tegra/rootfs’ is:

(base) smanupa@eb2-3224-grd01:~/secure-camera/Orin_TEE/Linux_for_Tegra/rootfs$ ls -l
total 12
drwxr-xr-x 2 smanupa kvm 4096 Aug 14 14:11 boot
-rw-r–r-- 1 smanupa kvm 118 Aug 24 09:43 etc
-rw-r–r-- 1 smanupa kvm 62 Aug 14 14:11 README.txt

The output of ls -l in ‘~/secure-camera/Orin_TEE/Linux_for_Tegra/rootfs/boot’ is:

(base) smanupa@eb2-3224-grd01:~/secure-camera/Orin_TEE/Linux_for_Tegra/rootfs/boot$ ls -l
total 41448
-rw-r–r-- 1 smanupa kvm 33718784 Aug 24 09:43 Image
-rw-r–r-- 1 smanupa kvm 9342070 Aug 24 09:43 initrd
-rw-r–r-- 1 smanupa kvm 420844 Aug 24 09:43 kernel_tegra234-p3701-0000-p3737-0000.dtb

Yes, I am getting the same FIREWALL_ERR. Here is the screenshot of it:

It seems not completed, do you extract the sample rootfs in this directory w/o issue?

Could you try to remove the following 3 nodes in tegra234-firewall-config-base.dtsi?


I am getting some issue, and unable to extract it properly.

I removed them, and flashed the board. But still getting the same error.

What issue did you get?

This method seems not work…

What’s your use case to do this?

I downloaded the driver files, and tried again. I am able to extract it completely.

Is there any other method, or documentation that you can suggest for resolving the issue? Is there any other technical document other than Orin SoC manual, and L4T documentation, that could give me a better idea about the problem, and how to resolve it?

I want to communicate with UART-A port through secure world only, which is connected to another device.

Hi KevinFFF,

Is it possible that the firewall error I am getting is because I am writing to the CAR registers from the main CPU (CCPLEX), but not via BPMP? If this is the case, could you please point out resources for how to communicate with BPMP processor to write to the CAR registers. In the Boot and Power Management section of the Orin SoC Technical Reference Manual, I see that:

The BPMP processor runs NVIDIA supplied software and is controlled through a NVIDIA API.
Details of the hardware programming interface are not supplied in this document.

Also, I see that in the Clock and Reset Controller(CAR) sub-section of System Components section:

For Orin, clocks and resets are controlled by NVIDIA provided firmware running on BPMP.
The hardware interface to the clock and reset controls is not documented, and the software
documentation should be consulted for details of how these functions are controlled.

Update: The TIMEOUT ERR is due to the UART clock not being initialized, or the reset line not being de-asserted before writing to the UART registers.
I am able to write to the UART registers from the Trusted OS (OP-TEE) by initializing the UART clock for port-A, and de-asserting the reset line before writing to the registers.

1 Like

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