disable console output during kernel bootup

To disable console output during kernel bootup, use the “quiet” option on the kernel command line.

I have append quiet on /boot/extlinux/extlinux.conf. But this doesn’t work.

Can you point out where I should put the quiet?

Are you looking to get rid of text console messages? FYI, you’d still get those messages from boot stages prior to the Linux kernel loading. Are you looking to remove text from regular terminals, but not on serial console?

@linuxdev My final target is Kernel Boot Time Optimization as L4 statement.

I found if I want to “Disable Console over UART”, append “quiet” on /boot/extlinux/extlinux.conf doesn’t work. I need to remove console=ttyS0 within bootcmd in uboot env level. I guest the reason is uboot env already include console=ttyS0, there is no way to remove it with extlinux.conf.

Anyway, after “Disable Console over UART”, I didn’t found boot time is reduced. Still same level. Do you have any comment?

You could just disable it by removing the tty* in kernel command line.
Then the console log during kernel boot would be gone.

Yes, it works.
But the bad news is doesn’t save any boot up time.

Are you working on rel-28 base or rel-32 base?

Just a thought on the topic…look at the boot logs and notice the timestamps. If you see small time increments, then those lines are probably irrelevant in terms of optimizing boot speed. If you run into lines which have a significant pause prior to the next line, then that might be something to look at.

As an example I see one case of R32.1 where all is smooth and relatively fast all the way up to and including the i2c query of the monitor’s EDID data (at around 0.9 seconds in to boot…but I am assuming that the wording of the tegradc probing message is valid and that the probing completed…if it turned out the message was misleading and the message printed at the start of probe instead of end of probe, then the delay would have been the probing instead of the PCIe mentioned next). Then the next line does not occur until around 0.6 seconds later and is the PCIe checking for devices. If one could delay PCIe checks (such as if you know you have nothing on PCIe), then perhaps 0.6 seconds could be saved if you know how to delay PCIe. I do actually see multiple PCIe enumeration attempts, and the total time of actual queries probably consumes around 2.25 seconds.

After that the next delay I see is after audio setup completes. I don’t know if the delay to the next task is because of the length of time that audio setup took prior to that next step, or if instead that next step started and took extra time to log, but the gap is between audio setup and “extcon-disp-state external-connection” (which might be eDP or HDMI…not sure…but if it is eDP then it is taking time to query and not getting a response because I have no eDP). In this case I believe the audio is related to the HDMI (HDMI has audio content, and since eDP does not, then I assume this is the HDMI monitor).

It looks like there is a short delay setting up and mounting the eMMC file system (earlier delays were prior to mounting). This is one you probably cannot improve and should not try to change.

Once again, shortly after this urandom setup takes a moment (it’s trying to build an entropy pool and isn’t something you can configure), followed by an i2c message (the delay is between urandom and i2c). Note that i2c is also the protocol that the HDMI and eDP cables use to pass monitor setup to the video system. So I’m suspecting some of the delays are i2c related.

Then there is login.

You might want to look at your boot logs and concentrate on those delays or operations which seem optional and which consume significant time. The boot log is basically a profiling tool.