Disable serial console of u-boot on TX2

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I currently have a Tx2 on a custom carrier connected on ttyS0 and ttyTHS2.
I removed the console output on uart0 by changing inside p2771.000.cinf.common :

-CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";
+CMDLINE_ADD="console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";

Now I can’t boot if the other board on the uart is already up, as it’s a PIC it obviously boot faster than the TX2, and already try to communicate (not that I can’t change the second board).

I also followed : this post which leads to edit this file tegra186-mb1-bct-misc-si-l4t.cfg:

-debug.enable_log=1;
+debug.enable_log=0;

but this doesn’t prevent stdin during u-boot, thus my system is most of the time unable to complete a boot:

for reference my problem is in this part of the nvidia documentation:

To interrupt U-Boot
1. Connect a terminal application to the serial port of the board.
2. Power on or reset the board.
3. Wait for the U-Boot sign on message to appear. Key presses before this point in time may be ignored.
4. Press any key to interrupt the automatic boot process.

is there any way to ask for a specific key sequence; purely disable the stdin on ttyS0 & ttyTHS2 during u-boot ?

2

My information is a bit out of date, but there was a similar topic on changing to an alternate serial port for serial console is listed here (beware it was an earlier release, so some parts may differ):
https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368

Serial console on U-Boot itself is a separate program. Changing this in Linux won’t have any effect on U-Boot. There are some device tree changes on newer releases which will have an effect on both Linux and U-Boot…this is because instead of Linux reading this from a file in “/boot” stages prior to U-Boot read the device tree from a partition, and then pass it on to U-Boot (possibly editing prior to U-Boot seeing this). Then U-Boot passes it on to Linux.

So I’m not sure what to tell you on actual instructions, but I believe you’ll need to either disable serial console in U-Boot, or better yet, change it to a different serial port. I suppose this might depend on both release and which carrier board you use. Is this a dev carrier?

Just FYI, the naming convention of “ttyS#” is for ordinary serial UART mode. The naming convention for “ttyTHS#” is for the driver which enables DMA. There are no drivers capable of DMA in U-Boot, and so it must be a “ttyS#” name in U-Boot; to maintain serial console during boot it is then necessary for the Linux kernel to use that same driver setting…and thus the same “ttyS#” syntax. Switching to DMA mode would break continuity of service during boot as a new driver is used. On the other hand, “/dev/ttyS0” and “/dev/ttyTHS0” are the same hardware…just with different drivers.

In the device tree you will see a “compatible” entry naming which drivers a device can use. For serial UARTs you will find something like this:

serial@3100000 {
    compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
    ...

The “hsuart” is the DMA high-speed UART driver…the other is your ordinary 16550A compatible driver. When the comma separated list of drivers for that controller has both listed, then it is up to the operating system or boot loader which to use.

Perhaps someone can answer the specific case though: If just disabling serial console on a recent release of a TX2, can this be done just by device tree? Or does U-Boot itself need to be recompiled with the alternate console (or disabled console)?

3

Thank you,

I musty admit that I’m a neophyte on those and currently struggling to how to edit the dtb.

On the post you linked I know how to modify point 1) 3) & 4) but point 2) is where I’m struggling:

dtc -I dtb -O dts -o extracted.dts kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb

If I understood correctly I need to edit tegra186-quill-p3310-1000-c03-00-base.dtb, but I’m getting a nofile error (out of office, will post error this afternoon).
If I’m not wrong I need to edit this on the host before flashing, right?

Then reflash the image,

sudo ./flash.sh jetson-tx2 mmcblk0p1

then:

sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

EDIT: could edit & recompile the DTB durrently reflashing & I’ll let you know.

4

Well, I moved the output to serial3 (is this really tty3 ?) (serial@3130000 in the dtb) :

serial@3100000 {
- compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
+ compatible = "nvidia,tegra186-hsuart";
console-port;
sqa-automation-port;
status = "okay";
@@ -53,7 +53,7 @@
};

serial@3130000 {
- compatible = "nvidia,tegra186-hsuart";
+ compatible = "nvidia,tegra20-uart", "nvidia,tegra186-hsuart";
status = "okay";
};

in BCT/tegra186-mb1-bct-misc-si-l4t.cfg

****************************
cpu.nafll_b_cluster_data = 0x11F04461;
##### debug variables #####
debug.enable_log = 1;
-debug.uart_instance = 0;
+debug.uart_instance = 3;
##### sw_carveout variables #####

and in p2771-0000.conf.common:

-CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";
+CMDLINE_ADD="console=tty3 OS=l4t fbcon=map:0 net.ifnames=0";

still refuse to boot if a message arrive on ttyS0 during uboot.

Any other idea, or did I miss a step ?

EDIT:

The only difference between serial@3130000 and serial@c280000 (example in other post) is

serial@c280000
{
[...]
dma-names = "rx", "tx";
[...]
}
[...]
serial@3130000
{
[...]
dma-names = "tx"; <b>//no rx</b>
[...]
}

is this important ?

I’ll retry moving the uart to serial@c290000 (serial6 , i.e. tty6 (?)) and change its status to “okay” and let you know.

5

I’m unsure of your specific edits, but the gist is that a given UART will have a controller base address. The “serial@xxxxxxx” implies the serial UART controller at that base address. The labels given in “/dev/” depend partially on the Linux kernel’s naming conventions and udev. If the “compatible” includes both the “hs” and non-hs variant, then both ttyS# and ttyTHS# formats are generated (just don’t use both at the same time). The serial console will always require the ttyS# format because otherwise the transition from bootloader to kernel will not work correctly and serial data will be lost.

DMA names will not matter if you don’t use the ttyTHS# device. I’m not familiar as to when and why one would have just “tx” and the other both “tx” and “rx”, but I’m thinking you’d want both if your UART isn’t one way.

Do keep in mind though that you need to edit the bootloader itself, and then rebuild and install the edited bootloader. The bootloader is its own independent program…it’s only purpose is more or less to overwrite itself with the kernel and die. There are times when the bootloader does use device tree, but there are more times when it ignores device tree, or even uses the tree differently than the Linux kernel uses the tree. When boot halts on activity you know it is in the bootloader stage and that the Linux kernel never began executing. I am not sure if serial console settings in the device tree has any effect on U-Boot.

6

I came to the same conclusion.

I’m now digging on the u-boot sources to see if I can redefine the UART port used.

I’ll post my progress, in the mean time as its far from my field, can you explain how I can recompile the u-boot & flash it ?

Ok, the more I dig in the u-boot files the less I understand where I should changeOk, the more I dig in the u-boot files the less I understand where I should change。

The only thing I saw that might be related is in u-boot/include/configs/p2371-2180.h

#define CONFIG_TEGRA_ENABLE_UARTA

and I saw in another file the enum for UARTA/B/C/D/E/F that might be tty0 to tty5

I still dig to see if only changing this would lead to have the u-boot reading another uart port.

On a side note, moving the u-boot uart port wont prevent me to reflash ?

EDIT:

In sources/u-boot/arch/arm/mach-tegra/board.c:

enum {
	/* UARTs which we can enable */
	UARTA	= 1 << 0,
	UARTB	= 1 << 1,
	UARTC	= 1 << 2,
	UARTD	= 1 << 3,
	UARTE	= 1 << 4,
	UART_COUNT = 5,
};

[...]

void board_init_uart_f(void)
{
	int uart_ids = 0;	/* bit mask of which UART ids to enable */

#ifdef CONFIG_TEGRA_ENABLE_UARTA
	uart_ids |= UARTA;
#endif
#ifdef CONFIG_TEGRA_ENABLE_UARTB
	uart_ids |= UARTB;
#endif
#ifdef CONFIG_TEGRA_ENABLE_UARTC
	uart_ids |= UARTC;
#endif
#ifdef CONFIG_TEGRA_ENABLE_UARTD
	uart_ids |= UARTD;
#endif
#ifdef CONFIG_TEGRA_ENABLE_UARTE
	uart_ids |= UARTE;
#endif
	setup_uarts(uart_ids);
}

So I have something I can try, now learning how to compile the u-boot, also as u-boot is totally dissociate to the OS itself, I should also revert my kernel & dtb update (except removing console output from ttyS0).

7

I don’t think tty3 indicates the serial 3. It just indicates the command line terminal on ubuntu.
It looks like this function (disable UART log in uboot) does not work anymore after rel-28. We are not sure the reason. Does this cause any trouble to you?

8

If disabling the log during u-boot also disable the uart u-boot interrupt then yes it’s causing a lot of troubles.

Our problem is simple, currently having another board sending data on the TX2 Uart RX prevent it to complete it’s boot (u-boot interrupt).

9

I am checking this issue.

But…sorry that I don’t get your last comment. “If disabling the log during u-boot also disable the uart u-boot interrupt then yes it’s causing a lot of troubles”

Aren’t you trying to disable uart log?

Also, what does it mean “another board sending data on the TX2 Uart RX prevent it to complete it’s boot”. What case would you stop this TX2 to boot up?

10

His system is using the UART for another purpose than serial console. The system is failing to boot even after he disabled serial console in Linux because of stray activity halting U-Boot. He has to rebuild or alter U-Boot such that ttyS0 no longer talks to U-Boot.

11

Thanks linuxdev.

Could I just simplify this issue to the need of disabling any UART activity on u-boot?

12

Yes, it’s exactly what I’m trying to do.

13

How about trying to change this env parameters?

stdout=serial', 'stderr=serial
14

The out on uart debug isn’t a problem and is fixed.

the problem is on the stdin on UART0 during u-boot.

15

Could you briefly share what you have done here?

16

To remove the stdout & stderr from serial console I did what is in my first post:

I removed the console output on uart0 by changing inside p2771.000.conf.common :

-CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";
+CMDLINE_ADD="console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";

and edited this file tegra186-mb1-bct-misc-si-l4t.cfg:

-debug.enable_log=1;
+debug.enable_log=0;
17

It seems debug.enable_log only works for MB2/MB1/cboot. Have you done anything to your U-boot?

18

u-boot is as it.

I do not receive any data on UART0 from console anymore so I think that the stdout/stderr side of the problem is “fixed”.

Problem is when the second board is already sending to the UART during Tx2-u-boot, the u-boot sequence never complete.

19

Elleryn,

I just wonder how do you know it is stuck on u-boot if you don’t have any stdout during boot sequence.

20

By simple tests.

If I unplug the UART0 the system boot perfectly.
If I plug the UART0 the system doesn’t boot.
If I plug the UART0 and cut the UART0-RX cable the TX2 boot perfectly well.

So by deduction the only thing preventing me to boot is activity on the UART0 stdin during u-boot.