I wrote a UART device driver in OP-TEE for Jetson AGX Orin, which works in 16450 mode. I mark the register access to UART-A (0x3100000) as non-secure in the device tree of OP-TEE. I made a new set of system calls in OP-TEE to access the UART-A registers from any Trusted Applications (TA). The initialization of UART is done by Linux, since the initialization of UART-A needs BPMP software, which OP-TEE does not have.
However, when I try to access the UART-A registers through my OP-TEE based UART device driver, by performing a write/read to any UART-A register. I get the following error at CBB-Fabric saying Time-out error:
Although, when I try to use minicom after Linux has completed booting and write to the UART-A port, I have no issues. But when I use my OP-TEE based UART driver, I get this error. Also, if I try to use minicom after using OP-TEE based UART driver, I get the same TIMEOUT error, but for different registers of UART-A.
Yes, I will try updating to the latest R35.4.1 and let you know.
I tried accessing the following physical addresses by adding them into the OP-TEE’s MMU at boot time (Used core_mmu_add_mapping function in OP-TEE) to get a virtual address for the UART-A base address, and then access them after Linux has completed booting using their corresponding virtual addresses with R35.2.1. The physical addresses I tried accessing are:
0x3100000 for THR, RBR.
0x3100000 + 0x3 for LCR
0x3100000 + 0x4 for MCR
I tried updating my board to R35.4.1 by updating to the latest Jetpack 5.1.2, and fully flashed the board. When I tried compiling the default OP-TEE sources provided with R35.4.1, without any changes, I was unable to do it and received an error message. PFA is the error I got. unable_to_compile_optee_sources.txt (264.3 KB)
Also, when I try to use the OP-TEE versions provided with R35.3.1, and R35.2.1 with Jetpack 5.1.2, I was able to compile the sources, and flash the image on the board. But the board doesn’t boot, since it is unable to prepare TOS params. unable_to_boot.txt (28.4 KB)
I am currently porting UART accessing PTA to R35.3.1 version of OP-TEE, and will update you soon, by trying to access the registers you suggested.
Yes, I used the same procedure to build OP-TEE for both R35.3.1(success) and R35.4.1 (failed), with the default source code provided (i.e. without any of my custom code).
I believe it is because of a python3 module dependency (cryptography). I did try updating the module according to the instructions provided in the atf_and_optee_README.txt
After updating the module I am getting the following error. unable_to_compile_optee_sources_2.txt (333.0 KB)
I tried accessing the register addresses (0x3100000 for UART_THR_DLAB_0_0,
0x310000C for UART_LCR_0, 0x3100010 for UART_MCR_0) from OP-TEE that you shared, but I still get the same error(TIMEOUT ERROR), with R35.3.1.
When I run the command “pip3 install python3-cryptography”, I get an error, as seen in the image below. But when I use the command “pip3 install cryptography”, I get the following message. FYI, I am using python3.8.
I have also installed the OP-TEE prerequisites mentioned in: Prerequisites — OP-TEE documentation documentation
When I try to install the pre-requisites using the above command, I get the following message: "python3-cryptography is already the newest version (2.8-3ubuntu0.1)”
Th error is:
*ERROR: Could not find a version that satisfies the requirement python3-cryptography (from versions: none) ERROR: No matching distribution found for python3-cryptography
*
I tried using conda to try it on another version of python.
But coming back to the main issue, could you please point out any documents, or any other resource to identify the source of the TIMEOUT error at CBB, while accessing the UART registers. I do not think it would be resolved with the latest version of L4T35.4.1, but it might be a rather different issue.
I was under the assumption that the clocks and reset signals would be controlled by BPMP software, and we communicate with the BPMP R5 processor using bump_atomic_send_receive command. I shall try de-asserting the reset line for UART-A by directly writing to the memory address, and let you know.
So far, I was trying to access the UART-A registers, without de-asserting the reset signal, and not setting the UART-A configuration. Since I assumed that we need to de-assert the reset signal, only at the time of initialization, not when performing UART read/write operations.
I tried de-asserting the reset line for UART-A, and got this FIREWALL_ERR, before trying to read/write to any UART register. Is there anything else that I am missing that should be done at boot time? Should I be changing the setting of SCR/BLF/ARF as you suggested? If so, can you please provide the guidelines as to how to proceed ahead.
For this firewall error, could you try to modify the following line in <Linux_for_Tegra>/bootloader/t186ref/BCT/tegra234-firewall-config-base.dtsi, and re-flash the board to apply?
reg@5694 { /* CBB_FABRIC, CBB_CENTRAL_CBB_FIREWALL_UARTA_CAR_BLF, WRITE_CTL */
exclusion-info = <2>;
- value = <0x00000008>;
+ value = <0x0000000a>;
};
