Which is better to specify console, "console= " or "stdout-path" ?

Hi Masahiro,

On 10/22/2015 12:20 AM, Masahiro Yamada wrote:

2015-10-22 1:26 GMT+09:00 Peter Hurley [off-list ref]:

quoted

On 10/21/2015 11:38 AM, Masahiro Yamada wrote:

quoted

2015-10-21 21:46 GMT+09:00 Peter Hurley [off-list ref]:

quoted

On 10/21/2015 04:58 AM, Sudeep Holla wrote:

quoted

On 21/10/15 06:09, Masahiro Yamada wrote:

quoted

I think there exist two ways to specify the console port and baudrate.


[1] Specify console in bootargs

   chosen {
         bootargs = "console=ttyS0,115200";
   };


[2] Specify stdout-path

    chosen {
          stdout-path = "serial0:115200n8";

This will work for even early/boot console, so this is better than
option [1]

Be aware that options specified via /chosen/stdout-path are
currently ignored by earlycon. There were some hiccups getting the
initial support upstream; when 4.4 hits mainline, I'll resubmit
my series that implements the of_serial i/o properties and
options passthrough to earlycon setup.

As I said in another thread ("serial: earlycon: allow to specify
uartclk in earlycon kernel-parameter"),
stdout-path can pass dev->baud, but not port->uartclk.

That's true but I'm not seeing in that thread where you wrote that?

Sorry, I made you confused.  I was talking about the kernel parameter (console=)
in the thread.

quoted

My replies there were specific to uartclk on the kernel command line,
which isn't necessary if the bootloader has already initialized the
uart.

quoted

It is usually specified "clocks" phandle, but
clk is not ready at the point of earlycon.

It seems impossible to set up the baudrate even if the options are passed.

It's difficult to understand what you're trying to do when I can't
see the code you're referring to.  For example, I only recently
understood that you're talking about a earlycon implementation
that you're working on and not the 8250 earlycon itself.

Sorry again for making you confused.

I was talking both.

Now I am tackling on some ARM board porting.


The board has a pure 8250 family device (compatible = "ns16550a") on it.

In addition, there exist 8250-variant IPs inside the SoC.
(this is similar to 8250, but slightly different.
drivers/tty/serial/8250/8250_uniphier.c)


What I want to do is:
  [1] To use  drivers/tty/serial/8250/8250_early.c  for the on-board ns16550a.
  [2] To implement my own EARLYCON_DECLARE() in
drivers/tty/serial/8250/8250_uniphier.c

quoted

If you look at other non-8250 earlycons, you'll see they all ignore
the baud rate, on the assumption the bootloader already set it up.

OK, I will do so for [2].

quoted

The 8250 earlycon is a little different because legacy platforms
do not initialize the uart.

Make sense.

For legacy platforms, earlycon initializes the uart,
assuming the hard-coded "port->uartclk = BASE_BAUD * 16"
is the value.


For embedded boards such as ARM, the boot-loader should initialize the UART
and the earlycon should preserve it because port->uartclk varies from
board to board.
(For example, the ns16550a on my board expects   BASE_BAUD is 1228000,
but it does not match the one in include/asm-generic/serial.h )

I want to clarify one point: if you have a configuration for which the
earlycon uart is not initialized by the bootloader (or boot prom), then
we can add a way for the ASoC init to set BASE_BAUD. This was done for
the ARC arch, but I would like to use this as a last resort for the ARM
arch.

An example configuration I can envision that would require this solution
is u-boot's so-called 'falcon mode' without devicetree (or boot prom).

Regards,
Peter Hurley