how to get console log in console tty1 after remove console ttyS0 in extlinux.conf

Hi, all

For a faster boot of Tx1 , I remove console = ttyS0 from extlinux.conf.

Then we can’t have a interactive serial terminal with Tx1. But the boot message is still important for debugging system.

Therefore ,I learn the l4t-document for driver , and get that we can use console = tty1 for log message.

It seems that the console tty1 is a framebuffer console . The problem is that the message flashes away quickly on the screen and we learn little message.

I want to know where I can get the tty1 boot message. Is it a log file in ubuntu ?

I also try

cat /dev/tty1 > log.log

but I get nothing in log.log. It’s empty.

So , is there also a way to interact with Tx1 besides UART (ttyS0) , or even just get entire boot message ?

Any suggestion is appreciated. Thanks.

I don’t think the serial console would slow boot so much as watching it on the local terminal. Once Linux takes over there is this as part of the argument to the kernel telling it to use both serial console and local console:

console=ttyS0,115200n8 <b>console=tty0</b>
# console=tty0 implies local console.
# console=ttyS0,115200n8 implies serial console.

Changes to this will of course not change what happens in U-Boot, but removing “console=tty0” would eliminate output to the local framebuffer console while keeping serial console. Was it actually removal of ttyS0 which sped up boot? Or did you also eliminate tty0?

Just a thought on this. Serial console is set for 115200 speed. The default on a local terminal/console is 38400. The local terminal is three times slower than the serial console.

Hi, linuxdev.

I just remove console=ttyS0,115200n8 from /boot/extlinux/extlinux.conf and keep console=tty0.

The entire boot time decreases about 10 seconds which I have tested on Tx1.

I found that it would not show boot message of kernel print. Maybe the time is saved ?

L4t-documentation-24.2.1 tells ttyS0 is the bottleneck of boot time. You can reference to it.

To be honest , I don’t understand the mechanism too much. I just do it according to the documentation.

I suppose tying two console streams together would imply the stream with the least buffering would limit both streams. Now that I think of it, a framebuffer console (by definition) has a huge buffer, whereas a serial UART has very little buffer. Many people think C++ streams are slow, but this is not the case, it’s really tying the C and C++ I/O together causing the slowing…C++ I/O without C tying is just as fast as pure C.

One of the reasons stderr is so much slower than stdout is that it doesn’t buffer, and the reason it doesn’t buffer is to guarantee delivery even during failures…a buffer would go away with unflushed output if there is an application crash. I suppose serial console has the same concept in its design. It would seem it should be possible to add buffer to serial console and disable tying serial console and regular console and still achieve a fast boot, but this would remove serial console reliability at message delivery during a system failure.

Still, so long as software did not crash, the directly connected terminal on tty1 should show boot software. After boot finishes tty0 is visible from another console via “ALT-F1”, or from the GUI you’d switch via “CTRL-ALT-F1” so long as you left “console=tty0” in. If this is not the case, can you provide the output from “cat /proc/cmdline”?

Much of what you see in that console will be either in “dmesg”, or else in “/var/log/kern.log”. Do these two files provide what you want?

Somewhat interesting for these circumstances, there are ways to set up logging to go to a remote network facility instead of to the local disk. If something happens to the original system, then the remote system still has the logs. Plus the local system can conserve on disk space and any risk of filling the system with logs would go to the remote system. This may not be worthwhile to you because it can’t exist until networking is up.

Yes,We can get kernel boot message from dmesg and kernel log.

cat /proc/cmdline

fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none
androidboot.serialno=P2180A00P00940c003fd tegraid=
ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 usb_port_owner_info=0 lane_owner_info=0
emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0
earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec}
nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal
androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0
androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait

I have tried removing console=ttyS0,115200n8 .

According to this you are still sending output to both serial console and regular console (at least once the Linux kernel loads):

console=tty0 console=ttyS0,115200n8

It’s useful to note that (especially in R28.1) some of the kernel command line is passed through from U-Boot, which in turn is from the device tree binary in one of the hidden partitions. If you removed “console=ttyS0,115200n8”, yet this still appears in “/proc/cmdline”, then it stands to reason that you need to edit the entry in the U-Boot device tree as well.

On R28.1 see this for device tree editing, which also adds an URL:

There thread talks about switching serial console from ttyS0 to ttyS1, and basically you’d be editing the same thing in the dtb file…but you’d be disabling that port’s console (or more accurately, setting the port to normal serial UART operation without binding it to serial console function) while not enabling the alternate port:

Your answer is obliged, thanks. I have been trying it.