0

If I understand the dmesg output correctly, there is something happening for almost one second around the UART console initialization:

[    1.090771] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    1.920577] console [ttyAMA0] enabled

Is there any option, how to reduce this extremely long time? Like:

  • kernel compilation options via config?
  • kernel parameters passing (cmdline.txt)?
  • ARM/GPU configuration options (config.txt)?
  • manual UART configuration?
  • anything else?

Any hints welcome. Please note, I would like to use the UART as the console.

  • The serial link is used for boot messages. When boot is complete the serial link is enabled as a console (if configured so). Are you sure you are not just seeing that behavour? – joan Oct 30 '17 at 21:53
  • Oh, I see. You are saying the log messages are stored in a buffer, then after the UART is initialized, they are transfered, which creates this delay. So the faster the UART baudrate is the shorter the delay is. Going to check it... – sharpener Oct 30 '17 at 22:27
0

The delay is the time the just initialized UART transfers all the messages collected since the system start. The faster it is, the shorter the delay is (I was using the original 115200).

Depending on the other end connected, set the UART baudrate to maximum, like (cmdline.txt):

console=ttyAMA0,921600

causes my system to startup significantly faster:

[    0.909290] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    1.012816] console [ttyAMA0] enabled

@joan: Thanks for hint.

| improve this answer | |
  • Please accept your own answer with a click on the tick on its left side. Only this will finish the question and it will not pop up again year for year. – Ingo Feb 13 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.