Jetson NX Boot messages are not hiding

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
,
1

Hello

Jetson NX Boot messages are not hiding in our product.
I’m using our custom board, which has 2xHDMI and tc358743 chip.
Our kernel of JetPack 4.6.1 is customized. Our product should remove the boot message.

I referenced the following topics:

This might have warnings, ignore them for now unless something fails.

dtc -I fs -O dts -o extracted.dts /proc/device-tree

Now use a text editor on extracted.dts, find “bootargs” under “chosen”. Look for “console=tty0”,

and remove it. Then create a binary from this:

dtc -I dts -O dtb -o edited.dtb extracted.dts

Place a copy of this at:

/boot

Add an FDT key/value pair naming this in “/boot/extlinux/extlinux.conf”, causing it to become:

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
FDT /boot/edited.dtb
INITRD /boot/initrd
FDT /boot/edited.dtb
APPEND ${cbootargs} vt.global_cursor_default=0 loglevel=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 net.ifnames=0 quiet console=ttyTCU0,115200n8 console=

However, Jetson NX Boot messages are not hiding.
aos@glow:~$ cat /proc/cmdline
console=ttyTCU0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0xa06b1000 lut_mem=0x2008@0xa06ae000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1

I can’t remove “console=tty0”. Could you give me some advice?

Thanks in Advance,

2

Are security fuses burned on this? If so, then the device tree will only be accepted from the signed partition. If not, then get a full serial console boot log…since it is still logging, the log should tell you where the device tree is loaded from.

There is also the “APPEND” key/value pair in “extlinux.conf” which could add that content. Be sure to check if the console is added there.

3

I’m not using security fuses.

When I use reComputer J202 (Jetson Xavier™ NX Dev Kit carrier board), it’s possible to remove the boot messages. The kernel parameter of FDT /boot/edited.dtb is effective.

J202:
aos@glow:~$ cat /proc/cmdline
console=ttyTCU0,115200 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0xa06b2000 lut_mem=0x2008@0xa06af000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1 vt.global_cursor_default=0 loglevel=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 net.ifnames=0 quiet console=ttyTCU0,115200n8 console=

However, When I use our custom board, It’s failed to delete boot message. The kernel parameter of FDT /boot/edited.dtb is not effective.

Our custom board:
aos@glow:~$ cat /proc/cmdline
console=ttyTCU0,115200 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0xa06b2000 lut_mem=0x2008@0xa06af000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1 vt.global_cursor_default=0 loglevel=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 net.ifnames=0 quiet console=ttyTCU0,115200n8 console=

I don’t know why the kernel parameter of FDT /boot/edited.dtb is not effective. Our kernel of JetPack 4.6.1 is customized for 2xHDMI and tc358743 chip. Our kernel is working well, but there’s something wrong with our customization, maybe.

My workaround is to modify “Linux_for_Tegra/p3668.conf.common” like the following:.

CMDLINE_ADD=“console=ttyTCU0,115200n8 vt.global_cursor_default=0 loglevel=0 console=tty2 fbcon=map:2 net.ifnames=0”;

I removed “console=tty0” and ran kernel build. My problem is solved.

Thanks,

4

In the above this should work, but the “console=” parameter is a bit different than most kernel arguments. Most arguments can be used only once, and the very last argument is the one which is effective. console is different because it can be used more than once (thus the ability to name both a regular console and a serial console). In many cases if the last argument is “something=” (without any right hand side) it will be the same as not setting the parameter, but for one like this where it can occur more than once I don’t know if it would apply to the intended console. Obviously, since it works on the J202 like this, it is reasonable to think it might work like that on the other board, but I would not guarantee it.

The edit you made of course works, but might not be particularly convenient. If you want to investigate further, then you’ll need to attach a full serial console boot log. This can show where device trees are loaded from.

5

Hello

Thank you for your opinion.
I referenced the following link:

This time, I use original “Linux_for_Tegra/p3668.conf.common”. I don’t modify it.

I remove the “console=tty0 ” from extracted.dts, and I attach it.
extracted.dts (241.7 KB)

$ cat /boot/extlinux/extlinux.conf
extlinux.conf (852 Bytes)

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
FDT /boot/edited.dtb
INITRD /boot/initrd
APPEND ${cbootargs} vt.global_cursor_default=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 net.ifnames=0 quiet

I attach dmesg.log
dmesg.log (71.9 KB)

Our custom board:
$ cat /proc/cmdline
console=ttyTCU0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0xa06b1000 lut_mem=0x2008@0xa06ae000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1

FDT /boot/edited.dtb doesn’t seem to work. I don’t know the reason.
Could you give me your opinion? If I have another solution, I’ll be happier.
Because I can avoid kernel build.

Thanks,

6

Please note that what we really need is a serial console log, and not just dmesg. Without that we can’t tell what occurs during bootloader stages. Also, is this booting from an external device, or is it booting from eMMC? Pay attention to notes on the “quiet” parameter in this reply (there is a subtle reason why this might be important, but not because of what quiet is supposed to do). Mostly I’ll describe some details, and provide a more interesting question at the end.

You are missing the “quiet” parameter in “/proc/cmdline”. This would probably help once the Linux kernel loads (add it at the end of the kernel command line; this implies either via device tree “chosen->bootargs” or through extlinux.conf’s APPEND). On the other hand, this might also reduce messages to serial console, and you might not want that to occur. Also, if the regular console is disabled, then quiet won’t matter for the HDMI monitor (I suggest leaving out quiet while figuring this out, but consider adding it back in later if you don’t need serial console debug).

It is interesting that the serial console part is listed twice, and listed differently (but ignore this for now because it will only affect serial console):

  • Incorrect first occurrence: console=ttyTCU0,115200
  • Correct 2nd occurrence: console=ttyTCU0,115200n8
    (note the “n8”)

You are correct that the extracted device tree does not show “console=tty0”, nor does the extlinux.conf. Sometimes boot stages edit a device tree entry before passing it on to the Linux kernel, but we don’t have a serial console boot log so I can’t confirm (and I suspect this editing is not the case). The reason this is interesting is because your “extlinux.conf” does have quiet in it, and yet cmdline does not show this. More on this at the end of the reply.

Earlier Jetson software used U-Boot, but more recent JetPack 4.x (L4T R32.x) actually uses only CBoot, although much of the U-Boot function has been ported to CBoot (it only looks like U-Boot, but some U-Boot function will differ or be missing). Possibly CBoot has defined a default console? This I do not know. I don’t think this is the reason for having tty0 debug messages.

The cmdline confirms though that there is a tty0 console prior to reaching the Linux kernel. This occurs only after Linux has started:

[    0.008855] Console: colour dummy device 80x25
[    0.012441] console [tty0] enabled
[    0.015603] bootconsole [tegra_comb_uart0] disabled

The tegra_comb_uart0 is serial so far as I know, and should not affect tty0. Perhaps I am wrong? Regardless “[ 0.012441] console [tty0] enabled” is what specifically states the point during boot in which tty0 is enabled (at least for Linux; the answer might differ in earlier boot stages).

What I think is happening…

If you boot an external device, then quite possibly you are not using the extlinux.conf you think you are using. Depending on boot order and setup, it becomes possible that an extlinux.conf on eMMC is used despite an external rootfs, or also the reverse of that. Not seeing quiet in cmdline, and yet seeing in the APPEND of extlinux.conf tells me this is likely occurring.

Also, you are using an initrd. This is often used when an external device is to be loaded. This can in fact also change which extlinux.conf is used.

If a different extlinux.conf is used versus what you think is used, then the device tree which is loaded might also differ and not be what you expect. I’m thinking you will need to review which extlinux.conf you are editing, and pay attention to other extlinux.conf files. Perhaps the initrd could be examined, but a serial console log would maybe be an easier way to figure that out.

7

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