Hi.




2016-07-28 16:44 GMT+09:00 Arnd Bergmann [off-list ref]:

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