Where can we find outputs from TLOGI applied in Trusted Application

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
#1

Dear All,
I am working on the development of Trusted Applications on Trusty TEE (using Jetson AGX Xavier). Even though we are not allowed to expose any data isolated in TA in runtime, I notice examples existed using TLOGI to output some messages. Where can we find outputs from TLOGI applied in Trusted Application ? Or in other words, is that possible to “debug” the TA code through standard outputs on the screen ?

Here is the code in common.h.

#define TLOGI(fmt, ...) \
    fprintf(stderr, "%s: %d:" fmt, LOG_TAG, __LINE__, ##__VA_ARGS__)

Best,
Tianchi

Why using C library function `sprintf` in Trusted Application will crash Trusty?
#3

Hi,
We can see the prints in debug uart log. Could you check it?

Please also adjust the debug level in make command:

   - Jetson Xavier:
     make t186 PROJECT=t186 TARGET=t186 BUILDROOT=./t194ref \
         TOOLCHAIN_PREFIX="${CROSS_COMPILE_AARCH64}" \
         ARCH_arm_TOOLCHAIN_PREFIX="${CROSS_COMPILE_ARM}" \
         ARCH_arm64_TOOLCHAIN_PREFIX="${CROSS_COMPILE_AARCH64}" \
         DEBUG=0 DEBUG_LVL=0 DEFAULT_OTE_APP_DEBUGLEVEL=1 NOECHO=@ \
         TRUSTY_VARIANT=l4t-public TRUSTY_MULTI_GUEST_CONFIGURATION= \
         TARGET_SOC=t194
#4

Hi,
Thanks for your quick reply. I did check the debug UART log by debug port /dev/ttyUSB3, strange thing is that the initialization was going well and I could see prints of TLOGI in main functions of all services in TAs during the setting up. However, when I executed a simple echo program from CA to TA, the TLOGIs called in TA services don’t work and there is no print in debug UART log. Where could I make a mistake ?

Another question is about Trusty crashing. I flashed a TA in Trusty, and it is well initialized. But once I execute CA program to connect its service (a simple one), the Trusty will crash directly and Xavier Board will reboot. Debug UART log shows that as well. What could be the problem of this ?

Thanks in advance !

#5

Hi,
Ideally if you follow atf_and_trusty_README.txt it should work fine. For further check we would need your help to share steps so that we can replicate the issue you are facing first.

And you may try upstream ATF. A user has tried it and found an issue, and the issue is fixed. Please check:
Upstream ATF Support

#6

Hi,

Thanks again.
Just to make sure you understand my requirements: I would like to watch the debug logs on console in ttyTCU0 of Jeston Xavier by redirecting fprintf in C code to UART debug log. So far the boot logs appear, while no logs can show after more executions of programs.

Here is what I got on UART Debug log:

...
[0013.836] I> Boot-device: eMMC
[0013.838] I> Add boot-sdmmc to plugin-manager/misc-data
[0013.844] I> Add storage-sdmmc to plugin-manager/misc-data
[0013.849] W> Unknown storage device
[0013.853] I> Add serial number:1425220002042 as DT property
[0013.859] I> Plugin-manager override starting
[0013.862] I> node /plugin-manager/fragement-tegra-wdt-en matches
[0013.869] I> node /plugin-manager/fragement-soft-wdt matches
[0013.876] I> node /plugin-manager/fragment-pcie-c5-rp matches
[0013.881] I> node /plugin-manager/fragment-tegra-ufs-lane10 matches
[0013.893] I> Disable plugin-manager status in FDT
[0013.893] I> Plugin-manager override finished successfully
[0013.895] I> tegrabl_load_kernel_and_dtb: Done
[0013.899] E> tegrabl_display_clear: display is not initialized
[0013.905] W> Boot logo display failed...
[0013.908] I> Kernel EP: 0x80080000, DTB: 0x90000000
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.253-tegra (buildbrain@mobile-u64-5497-d3000) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) )1
[    0.000000] Boot CPU: AArch64 Processor [4e0f0040]
[    0.000000] OF: fdt:memory scan node memory, reg size 48,
[    0.000000] OF: fdt: - 80000000 ,  2c000000
[    0.000000] OF: fdt: - ac200000 ,  44800000
[    0.000000] OF: fdt: - 100000000 ,  780000000
[    0.000000] earlycon: tegra_comb_uart0 at MMIO32 0x000000000c168000 (options '')
[    0.000000] bootconsole [tegra_comb_uart0] enabled
[    6.246573] cgroup: cgroup2: unknown option "nsdelegate"
[    7.397556] using random self ethernet address
[    7.397679] using random host ethernet address
[    7.519908] FAT-fs (loop0): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[    7.574987] random: crng init done
[    7.575089] random: 7 urandom warning(s) missed due to ratelimiting
[    8.065563] using random self ethernet address
[    8.065682] using random host ethernet address
[    8.448120] CPU2: shutdown
[    8.524393] CPU3: shutdown
[    8.588135] CPU4: shutdown
[    8.665543] CPU5: shutdown
[    8.820201] CPU6: shutdown
[    8.916874] CPU7: shutdown
[   10.691716] Bridge firewalling registered

Ubuntu 18.04.5 LTS xavier-desktop ttyTCU0

xavier-desktop login:

And in Xavier :

[    0.000000] Kernel command line: console=ttyTCU0,115200 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1    quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4
[    0.001468] console [tty0] enabled
[    1.659520] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 51, base_baud = 0) is a TEGRA_UART
[    1.660779] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 52, base_baud = 0) is a TEGRA_UART
[    1.661608] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 53, base_baud = 0) is a TEGRA_UART
[    1.662620] console [ttyTCU0] enabled

Edited :

I find a similar unsolved problem in forum here.

#7

Hi,
We have reference samples in:

Linux_for_Tegra/source/public/trusty/app/nvidia-sample$ ls
hwkey-agent  luks-srv
Linux_for_Tegra/source/public/trusty/app/nvidia-sample$ ls ../sample/
hwcrypto           ipc-unittest  skel   spinner           timer
hwcrypto-unittest  LICENSE       skel2  storage-unittest

So if you add TLOGI in either sample, you don’t see it be printed in UART log. Is this correct?

#8

Yes.
Even I didn’t test for each of them, but I re-checked the sample for luks_srv, and I cannot get the UART logs (except the booting steps).

#9

Hi,

Do you have any further information about the possible reasons ?

Thanks !

#10

Hi,
We think the application is not built with correct level to show TLOGI. Do you rebuild the application?

If you have confirmed the application is built with correct debug level we would need to set up and replicate the issue.

#11

Hi,
Yes, I checked the make command, rebuild the applications with correct debug level. But there is still no TLOGI showing. So I attached a patch file for luks-srv sample here, what I did is only muting key_mgnt_processing which is not used, and adding several TLOGIs in the program.
luks-srv.patch (1.2 KB)

The bootstrap of Trusty is as following :
bootstrap
While there is no more TLOGI showing after I executed program in CA_sample with any commands, e.g.“./luks-srv-app -c test -g”.

#12

Hi,
Pleas try dmesg or echo 7 > /pros/sys/kernel/printk

And do you use Xavier developer kit? The debug port is the micro-B port. If you connect it to a host PC and run minicom, should be able to see the log from bootloader, kernel to userspace.

#14

Hi,
Yes, I am using Xavier Developer Kit and always keeping micro-B port as the debug port as you said (connecting with a PC and run minicom as minicom -D /dev/ttyUSB3).

Thanks firstly, I tried dmesg in Xavier, and it is true that we could see the outputs from TLOGI on Xavier! But I cannot see the logs by minicom on host PC. Only bootloader can be shown. Is that normal ?

#15

Hi,
Since dmesg works, please check dmesg for TLOGI prints.

#16

Hi,

Yes, dmesg works for TLOGI prints and it is helpful for debugging. I am just curious about the reason why debug port has this issue of printing logs.
In any case, I am going to close this question. And thanks a lot for your helps.
If you have further possible conclusions, please let me know.

#17

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