Thread (24 messages) 24 messages, 2 authors, 2015-03-01

Re: [PATCH -next 00/13] Extensible console matching & direct earlycon

From: Rob Herring <robh@kernel.org>
Date: 2015-02-26 14:58:39
Also in: lkml

On Thu, Feb 26, 2015 at 8:48 AM, Peter Hurley [off-list ref] wrote:
Hi Rob,

On 02/24/2015 03:20 PM, Rob Herring wrote:
quoted
On Tue, Feb 24, 2015 at 1:53 PM, Peter Hurley [off-list ref] wrote:
[...]
quoted
quoted
quoted
quoted
Direct earlycon

This feature enables arches and proms to start an earlycon directly,
rather than requiring an "earlycon=" command line parameter.
Devicetree can already do this via the 'linux,stdout-path' property,
but arch and prom code requires direct coupling to the serial driver.

This support is implemented by judicious refactoring and the same
construct that devicetree and early_param use: a link table containing
the necessary information (name and setup() function) to find and
bind the appropriate earlycon "driver".
I've skimmed thru this and it looks like a great improvement.

One problem we have currently with DT stdout-path and earlycon is a
preferred console does not get registered, so the console will get
switched to tty0 and you lose your console. The problem is DT does not
know the console name to register a preferred console. It looks like
this series may help this problem, but I'm not sure and wanted your
thoughts.
I thought that of_alias_scan() + of_console_check() caused DT stdout-path
to add_preferred_console() the driver console @ port registration time
via uart_add_one_port() -> of_console_check().

Is that not how that works?
Yes, I believe that is how it works with earlycon not enabled. This
doesn't work when earlycon is enabled with just "earlycon" on the
command line. The fix I have is here[1], but I don't like putting DT
specifics into the console code.
After much gnashing of teeth and pulling of hair yesterday, I managed
to mock up the situation you describe, but I need to study it in more
detail. Some things I did learn:

1. The serial console _does_ come back up when using stdout-path but the
   line settings don't match, because the serial core sets them to the
   default of 9600n8 if unspecified.
That may have been what I saw as I tested on QEMU which ignores the
baud rate. But it does stop between the time tty0 is enabled and the
"real" serial console which is a time period we really want the
console.
2. The line settings can now be set with stdout-path like,
     stdout-path = "serial0:115200n8"
   but this breaks DT earlycon (as I wrote in the other email you were
   cc'd on).
Right. We should fix libfdt.
3. omap doesn't support ioremap() at early param parsing :(
ARM in general does not.
4. the ARM arch doesn't support fixmap hacking at early param parsing :(
There's a patch on the list to enable it. It's been slow as fixmap has
been a moving target.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help