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

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

[Masahiro Yamada]

Hi.


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";
   };



Now I have both in my DTS, but it is redundant.

So, I want to select either [1] or [2].


Which is a preferable way?


Thanks,



-- 
Best Regards
Masahiro Yamada

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

[Arnd Bergmann]

On Wednesday 21 October 2015 14:09:42 Masahiro Yamada wrote:
> 
> 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";
>    };
> 
> 
> 
> Now I have both in my DTS, but it is redundant.
> 
> So, I want to select either [1] or [2].
> 
> 
> Which is a preferable way?
> 

stdout-path is better. It took us a while to get that implemented
on arm32, but now that it works, we should all use it.

	Arnd

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

[Sudeep Holla]

On 21/10/15 06:09, Masahiro Yamada wrote:
> Hi.
>
>
> 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]

-- 
Regards,
Sudeep

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

[Peter Hurley]

On 10/21/2015 04:58 AM, Sudeep Holla wrote:
> On 21/10/15 06:09, Masahiro Yamada wrote:
>> 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.

Regards,
Peter Hurley

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

[Sudeep Holla]

On 21/10/15 13:46, Peter Hurley wrote:
> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>> 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.
>

Yes I am aware of that. IIUC it's in -next now and works fine for me.
But having stdout-path in the DTS won't hinder normal console in anyway.
So I prefer it even without the patch you are referring(to support early
console parsing stdout-path)

-- 
Regards,
Sudeep

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

[Peter Hurley]

On 10/21/2015 08:54 AM, Sudeep Holla wrote:
> 
> 
> On 21/10/15 13:46, Peter Hurley wrote:
>> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>>> 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.
>>
> 
> Yes I am aware of that.

The others to which my email was addressed might not know that.

> IIUC it's in -next now and works fine for me.

Well, the fix in -next doesn't actually do anything wrt earlycon baud
rate; those changes were part of a larger series that depends on
the fix in -next.

Regards,
Peter Hurley

> But having stdout-path in the DTS won't hinder normal console in anyway.
> So I prefer it even without the patch you are referring(to support early
> console parsing stdout-path)

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

[Sudeep Holla]

On 21/10/15 14:02, Peter Hurley wrote:
> On 10/21/2015 08:54 AM, Sudeep Holla wrote:
>> On 21/10/15 13:46, Peter Hurley wrote:

[..]

>>> 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.
>>>
>>
>> Yes I am aware of that.
>
> The others to which my email was addressed might not know that.
>

True, good that you pointed it out.

>> IIUC it's in -next now and works fine for me.
>
> Well, the fix in -next doesn't actually do anything wrt earlycon baud
> rate; those changes were part of a larger series that depends on
> the fix in -next.
>

Ah ok.

-- 
Regards,
Sudeep

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

[Masahiro Yamada]

Hi Peter.

2015-10-21 21:46 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>> 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.

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.


-- 
Best Regards
Masahiro Yamada

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

[Peter Hurley]

On 10/21/2015 11:38 AM, Masahiro Yamada wrote:
> Hi Peter.
> 
> 2015-10-21 21:46 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
>> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>>> 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?
My replies there were specific to uartclk on the kernel command line,
which isn't necessary if the bootloader has already initialized the
uart.

> 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.

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.

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

Regards,
Peter Hurley

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

[Masahiro Yamada]

Hi Peter,

2015-10-22 1:26 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
> On 10/21/2015 11:38 AM, Masahiro Yamada wrote:
>> Hi Peter.
>>
>> 2015-10-21 21:46 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
>>> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>>>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>>>> 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.

> My replies there were specific to uartclk on the kernel command line,
> which isn't necessary if the bootloader has already initialized the
> uart.
>
>> 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



> 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].


> 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 )


-- 
Best Regards
Masahiro Yamada

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

[Peter Hurley]

Hi Masahiro,

On 10/22/2015 12:20 AM, Masahiro Yamada wrote:
> 2015-10-22 1:26 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
>> On 10/21/2015 11:38 AM, Masahiro Yamada wrote:
>>> 2015-10-21 21:46 GMT+09:00 Peter Hurley <peter@hurleysoftware.com>:
>>>> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>>>>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>>>>> 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.
> 
>> My replies there were specific to uartclk on the kernel command line,
>> which isn't necessary if the bootloader has already initialized the
>> uart.
>>
>>> 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
> 
> 
> 
>> 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].
> 
> 
>> 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