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
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:
- Correct 2nd occurrence:
(note the “
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.
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
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
cmdline, and yet seeing in the
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.