From: Sebastian Reichel <sre@kernel.org> Date: 2016-07-27 02:18:07
Hi,
On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
When the kernel fails to boot and its log console is silent,
I use earlycon and I often find the cause of error with it.
But, I have been wondering if there is an easy-to-use
debug tip which is available after earlycon is disabled.
I noticed the current mainline would not boot on my ARMv8 board.
According to the following log, I am guessing something wrong
is happening after the "bootconsole [uniphier0] disabled" log.
Is there a good practice to see more log?
Documentation/kernel-parameters.txt
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
between unregistering the boot console and initializing
the real console.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160727/9697ab95/attachment.sig>
Hi Sebastian,
2016-07-27 11:17 GMT+09:00 Sebastian Reichel [off-list ref]:
Hi,
On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
quoted
When the kernel fails to boot and its log console is silent,
I use earlycon and I often find the cause of error with it.
But, I have been wondering if there is an easy-to-use
debug tip which is available after earlycon is disabled.
I noticed the current mainline would not boot on my ARMv8 board.
According to the following log, I am guessing something wrong
is happening after the "bootconsole [uniphier0] disabled" log.
Is there a good practice to see more log?
Documentation/kernel-parameters.txt
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
between unregistering the boot console and initializing
the real console.
I did not know this kernel parameter, and it is exactly what I wanted.
Thanks a lot!
--
Best Regards
Masahiro Yamada
I assume that the original console is on a uart, while the new console
appears to be on the framebuffer. Maybe you have no screen attached?
I use 8250-compat serial console for both.
The following is the full boot log when success.
I am not sure about:
[ 0.000141] Console: colour dummy device 80x25
[ 0.000550] console [tty0] enabled
This is the UART console I am really using.
[ 0.234743] 54006800.serial: ttyS0 at MMIO 0x54006800 (irq = 6,
base_baud = 3676470) is a 16550A
[ 0.994393] console [ttyS0] enabled
I think the problem is that you have three consoles:
- the boot console that stays active until a real console comes up
- the framebuffer console that is initialized early and goes on to
disable the bootconsole
- the serial console that you are looking at but which doesn't get
initialized until much later
Clearly something is wrong in this setup and we don't want to
disable the boot console before the serial console is up.
I guess you could work around it by disabling the framebuffer console
at compile time, or by having the serial console initialized earlier
than the framebuffer, but I wonder if this is something that could
use a more general solution.
Arnd
From: Russell King - ARM Linux <linux@armlinux.org.uk> Date: 2016-07-28 12:20:46
On Thu, Jul 28, 2016 at 09:44:53AM +0200, Arnd Bergmann wrote:
I think the problem is that you have three consoles:
- the boot console that stays active until a real console comes up
- the framebuffer console that is initialized early and goes on to
disable the bootconsole
- the serial console that you are looking at but which doesn't get
initialized until much later
Clearly something is wrong in this setup and we don't want to
disable the boot console before the serial console is up.
I guess you could work around it by disabling the framebuffer console
at compile time, or by having the serial console initialized earlier
than the framebuffer, but I wonder if this is something that could
use a more general solution.
I think this is down to how the linux,stdout property is handled.
Normally, with command line specified consoles, if you don't specify
anything, you get the framebuffer console (actually, it's the first
registered console, but practically this is the framebuffer if enabled)
by default.
If you specify a console (or consoles) on the command line, you get
all of those you specified, (iirc) with /dev/console's input connected
to the first specified console.
This happens because the command line is parsed for consoles, and
add_preferred_console() is called for each that are found, whether or
not drivers are discovered for them. __add_preferred_console()
prevents the first registered console being automatically initialised
by setting selected_console to a non-negative number.
However, the parsing of DT specified consoles occurs at driver
initialisation time - in uart_add_one_port() via of_console_check().
Only at this time is add_preferred_console() called, which means that
the first console registered prior to _any_ selected UART console
driver mentioned in DT will become active.
When the first console becomes active, the earlycon is disabled, which
means that in the DT case, if we have a framebuffer enabled which
registers prior to any selected UART console, the framebuffer will
stop the earlycon output immediately.
To me, what this means is that the DT parsing of linux,stdout is
broken - while it may look nice from a design point of view, the
design is wrong and fails to take account of non-UART consoles in
the system.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Rabin Vincent <hidden> Date: 2016-08-08 09:09:16
On Thu, Jul 28, 2016 at 01:20:22PM +0100, Russell King - ARM Linux wrote:
To me, what this means is that the DT parsing of linux,stdout is
broken - while it may look nice from a design point of view, the
design is wrong and fails to take account of non-UART consoles in
the system.
Note that the brokeness you describe also leads to stdout-path being
unable to put the console on any serial port but the first, as reported
here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323811.html
It always puts the console on the first serial port if CONFIG_VT_CONSOLE
is not enabled, even if the stdout-path property requests a different
serial port.
I think the problem is that you have three consoles:
- the boot console that stays active until a real console comes up
- the framebuffer console that is initialized early and goes on to
disable the bootconsole
- the serial console that you are looking at but which doesn't get
initialized until much later
Clearly something is wrong in this setup and we don't want to
disable the boot console before the serial console is up.
I guess you could work around it by disabling the framebuffer console
at compile time, or by having the serial console initialized earlier
than the framebuffer, but I wonder if this is something that could
use a more general solution.
Looks like this comes from:
#elif defined(CONFIG_DUMMY_CONSOLE)
conswitchp = &dummy_con;
#endif
console= in the kernel-parameter is no problem,
but stdout-path in the chose node goes wrong with it.
2016-07-28 21:20 GMT+09:00 Russell King - ARM Linux [off-list ref]:
I think this is down to how the linux,stdout property is handled.
Normally, with command line specified consoles, if you don't specify
anything, you get the framebuffer console (actually, it's the first
registered console, but practically this is the framebuffer if enabled)
by default.
If you specify a console (or consoles) on the command line, you get
all of those you specified, (iirc) with /dev/console's input connected
to the first specified console.
This happens because the command line is parsed for consoles, and
add_preferred_console() is called for each that are found, whether or
not drivers are discovered for them. __add_preferred_console()
prevents the first registered console being automatically initialised
by setting selected_console to a non-negative number.
However, the parsing of DT specified consoles occurs at driver
initialisation time - in uart_add_one_port() via of_console_check().
Only at this time is add_preferred_console() called, which means that
the first console registered prior to _any_ selected UART console
driver mentioned in DT will become active.
When the first console becomes active, the earlycon is disabled, which
means that in the DT case, if we have a framebuffer enabled which
registers prior to any selected UART console, the framebuffer will
stop the earlycon output immediately.
To me, what this means is that the DT parsing of linux,stdout is
broken - while it may look nice from a design point of view, the
design is wrong and fails to take account of non-UART consoles in
the system.
Thanks for clarification.
I agree that stdout-path is something wrong.
Since I switched
from
chosen {
bootargs = "console=ttyS0,115200";
};
to
chosen {
stdout-path = "serial0:115200n8";
};
I have had bad experiences.
The combination of stdout-path and earlycon gives doubled log.
I reported this in https://lkml.org/lkml/2015/11/27/170
but not fixed yet.
I could fix the problem by changing
chosen {
stdout-path = "serial0:115200n8";
bootargs = "earlycon";
};
to
chosen {
bootargs = "console=ttyS0,115200
earlycon=uniphier,mmio32,0x54006800,115200";
};
--
Best Regards
Masahiro Yamada