How to determine whether TLK is applied to TX1 using R24.2.3 of L4T

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

There is a point I would like to confirm about Security Bulletin at the following URL.
https://nvidia.custhelp.com/app/answers/detail/a_id/5205#security-updates

In the case of TX1, it is said that the necessity of support changes depending on whether or not “Trusty trusted Linux kernel (TLK)” is used, but how should we proceed to determine whether or not TLK is used?

The current environment is as follows.
L4T version：R24.2.3
kernel version：3.10.96-tegra

Best regards

3

hello ToruUno,

please check the affected versions, it’s only applied to rel-28 or rel-32 release code-line.

4

hello, JerryChang
Thank you for your support.

Security Bulletin says “Versions prior to 32.5.1 (if using TLK)”, “Versions prior to 28.5”, and I recognized that R24.x is also in that category.

In the case of TX1, is it correct to understand that the version of L4T affected by this Security Bulletin is as follows, and R24.x does not affect it?
・ R32.1 to R32.5.1: affected
・ R28.1 to R28.4: affected
・ R24.x, R23.x: not affected

Best regards

5

hello ToruUno,

rel-24 was very long ago release, if I remember correctly, trusty linux kernel (TLK) was not even enabled.

6

hello, JerryChang
Thank you for your support.

As you pointed out, R24.x is a very old version, but I haven’t had any issues.
There is a big gap between R28.5 and R24.x in sevelal ways.
It takes a great deal of effort to apply the customization made for R24.3.2 to R28.5.

For example, check the description in the kernel resource, execute some command on TX1 running on R24.3.2, and so on.
Is there any way to determine whether TLK is valid/invalid for R24.3.2 built for TX1?

By the way, is it okay to understand that TLK is an abbreviation for “Trusty trusted Linux kernel” and is different from “trusted-little-kernel”?
When I opened the kernel source code directory of R24.3.2 with VScode and searched for “TLK”, I hit with some resources.

For example, I asked “arch/arm64/boot/dts/tegra210-soc-base.dtsi” because it had the following contents.

	tlk {
		compatible = "nvidia,trusted-little-kernel";
		logger = "enabled";
		storage = "enabled";
	};

Thanks

7

hello ToruUno,

the fastest way is checking bootloader messages,
please setup serial console and gather bootloader logs for reference,
thanks

1 Like
9

hello JerryChang,

Captured the TX1 serial output at boot time.
In the first line of the log at startup, the output was as follows.

“[2.211445] console [ttyS0] enabled, bootconsole disabled”

It says “bootconsole disabled”, is this log useful?

Thanks

10

FYI, if you see “quiet” in the “extlinux.conf” file, then you should remove it. It’ll be part of the “APPEND” key/value pair if there. You can see if it is there by examining “cat /proc/cmdline”. Passing “quiet” to the kernel command line disables most logging. Prior to Linux running (within bootloader stages) is a separate topic for enable/disable of console logging.

Currently extlinux.conf is found at “/boot/extlinux/extlinux.conf”. Some of the earlier releases had this at “/boot/extlinux.conf”.

11

hello ToruUno,

please refer to Serial Console - NVIDIA Jetson TX1 - JetsonHacks to wire up J21 for uart signaling,
you should capture the logs into a single text file and attach it to the thread for reference, thanks

12

hello JerryChang

“[2.211445] Console [ttyS0] enabled, Boot Console disabled” is the first line of UART output and its capture.

I also referred to the entry at the URL below.
Jetson/General debug

Perhaps the console output of bootloader is disabled, or it is output with a setting different from the baud rate of the Linux boot stage.
I’ll try to check it, but I would appreciate any other advice.

Thanks

13

hello linuxdev,

I connected TX1 and PC with UART and accessed from PC with console terminal (TeraTerm).
The first message in the log output that appears while TX1 is booting is as described above.

After booting, I checked the contents of “extlinux.conf”.
check_the_extlinux.conf.txt (1.2 KB)

Unfortunately I couldn’t find the phrase “quiet”.
It was also not found in the output of “cat /proc/cmdline”.
cat-proc_cmdline.txt (801 Bytes)

An engineer other than me was in charge of customizing the boot.
I’ll check with the engineer about the bootloader console output settings.
If you have any other advice, I would appreciate it.

Thanks

14

hello ToruUno,

there’s timestamp in the beginning of each line, it should be start from [0.0000] for the very first message.
it should be part of logs in the beginning has been overwritten due to the buffer size.
so, could you please keep the Tx/Rx connected and reboot the board to gather complete logs.
thanks

15

hello JerryChang,

I report the console output when shutting down and turning on the power.
From “–Shutdown Start-” to “–Shutdown End-” is the console output content at shutdown.
The contents from “–Power On Start-” to “–Power On End-” are the contents of the console output when the power is turned on.
Shutdown-> Power on was performed without closing the terminal screen of the host PC and maintaining the UART connection.
The buffer setting on the terminal screen is 32764 lines, so there should be no shortage of buffers.
However, the time stamp of the console output at power-on was not from [0.000000].
PowerOffOnUartOutput.txt (33.5 KB)

Instead, I also report dmesg after startup.
Perhaps this is not the bootloader console output, but the timestamp starts at [0.000000].
dmesg_dump.txt (56.1 KB)

I would be grateful if I could get any suggestions.
thanks

16

hello JerryChang , linuxdev,

I’m very sorry, the console output so far was not the one of the specified UART port, but the port corresponding to J17 of P2597 on our custom board.
After removing TX1 from the custom board and reattaching it to P2597, I connected the J21 UART (Pin8 & Pin10) to the PC.

The bootloader log was output to the console at boot time in this environment.

I saved the whole log, but there are more than 1200 lines.
If you need all the fields, I’ll send you a direct message.
Or, if you have a phrase to check here, please tell me again.

Thanks

17

okay… there’s no bootloader logs for confirmation.

I don’t have TX1 on hand and r24 is really an old release version.
could you please check if there any crypto service running in the background?
thanks

18

hello ToruUno,

actually, you’re able to edit your post to attach the text file for reference,

19

hello JerryChang,

I attach the log below.
P2597_J21_Consloe_Out.txt (67.6 KB)

I hope this is useful information.

thanks

20

hello ToruUno,

here it is…

64NOTICE:	BL31:	v1.2(release):e20ca65
NOTICE:	BL31:	Built	:	11:33:35,	May	2	2018
NOTICE:	Trusty	image	missing.
ERROR:	Error	initializing	runtime	service	trusty_fast

bl31 is binary file of arm trusted firmware (ATF), all trusty service, LK running after bl31 initialization.
since I don’t see any related messages pop-up, so it’s able to determine TLK is not used on your target.

1 Like
21

hello JerryChang

With your help, I was able to determine the TLK application status.
Due to my lack of understanding, I am sorry that I made a detour to confirm.

Thank you very much for helping us.

22

Apparently the other engineer has already removed “quiet”, which is as it should be, so that is good, with nothing to do there so far as “once the Linux kernel loads”. Sounds like you solved this though by means of using a different set of pins, so your logs seem to be complete now.

1 Like