Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306459

Re: [RFC PATCH] always probe UART HW when options are not specified

Show all headers | View raw

On 01/11/2016 07:07 AM, Sebastian Frias wrote:
> On 12/22/2015 06:56 PM, Sebastian Frias wrote:
>> On 12/21/2015 05:50 PM, Sebastian Frias wrote:
>>>> You need to use the format documented in
>>>> Documentation/kernel-parameters.text:
>>>>
>>>>     console=    [KNL] Output console device and options.
>>>>
>>>>         uart[8250],io,<addr>[,options]
>>>>         uart[8250],mmio,<addr>[,options]
>>>>         uart[8250],mmio16,<addr>[,options]
>>>>         uart[8250],mmio32,<addr>[,options]
>>>>         uart[8250],0x<addr>[,options]
>>>>             Start an early, polled-mode console on the 8250/16550
>>>>             UART at the specified I/O port or MMIO address,
>>>>             switching to the matching ttyS device later.
>>>>             MMIO inter-register address stride is either 8-bit
>>>>             (mmio), 16-bit (mmio16), or 32-bit (mmio32).
>>>>             If none of [io|mmio|mmio16|mmio32], <addr> is assumed
>>>>             to be equivalent to 'mmio'. 'options' are specified in
>>>>             the same format described for ttyS above; if unspecified,
>>>>             the h/w is not re-initialized.
>>>>
>>>> The iotype and the uart address are not options.
>>>
>>> Do you mean they are mandatory?
>>> How do they relate to the keys present on the DT? Because the device is
>>> already described in the DT:
>>>
>>>          uart: serial@10700 {
>>>              compatible = "ralink,rt2880-uart";
>>>              reg = <0x10700 0x30>;
>>>              interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
>>>              clock-frequency = <7372800>;
>>>              reg-shift = <2>;
>>>          };
>>>
>>> Are we supposed to duplicate such information (ie: addr) in the
>>> commandline as well?
>>>
>>
>> By the way, I tried using the following command line
>> 'console=uart,mmio32,0x10700,115200n8r mem=256M earlyprintk debug
>> ignore_loglevel' but I think I'm still missing something regarding this,
>> because it does not work, here's a log of Linux 4.1.13+:
>>
>>
>> 1: [arch/arm/kernel/setup.c:932] setup_arch(): r1 = 0xf34, r2 =
>> 0x803b3b50, cmdline ''
>> 1: [arch/arm/kernel/devtree.c:195] arch_get_next_mach(): infoBegin
>> 0xc024faac, mdesc 0xc024faac
>> 1: [arch/arm/kernel/devtree.c:195] arch_get_next_mach(): infoBegin
>> 0xc024faac, mdesc 0xc024fb14
>> 1: [drivers/of/fdt.c:106] of_fdt_is_compatible(): sigma,tango4 vs
>> sigma,vantage-1172
>> 1: [arch/arm/kernel/devtree.c:195] arch_get_next_mach(): infoBegin
>> 0xc024faac, mdesc 0xc024fb7c
>> 1: [drivers/of/fdt.c:749] of_flat_dt_match_machine(): Machine model:
>> Sigma Designs SMP8758 Vantage-1172 Rev E1
>> 1: [arch/arm/kernel/devtree.c:256] setup_machine_fdt(): about to call
>> early_init_dt_scan_nodes
>> 1: [drivers/of/fdt.c:1057] early_init_dt_scan_nodes(): bootcmdline ''
>> 1: [drivers/of/fdt.c:1062] early_init_dt_scan_nodes(): bootcmdline after
>> of_scan_flat_dt 'console=uart,mmio32,0x10700,115200n8r mem=256M
>> earlyprintk debug ignore_loglevel'
>> 1: [arch/arm/kernel/setup.c:946] setup_arch(): using DT at r2
>> 1: [arch/arm/kernel/setup.c:949] setup_arch(): machine name Sigma Tango DT
>> 1: [arch/arm/kernel/setup.c:967] setup_arch(): before parse_early_param
>> 1: [init/main.c:468] parse_early_param(): bootcmdline
>> 'console=uart,mmio32,0x10700,115200n8r mem=256M earlyprintk debug
>> ignore_loglevel'
>> 1: [init/main.c:473] parse_early_param(): mark
>> 1: [init/main.c:428] do_early_param(): enter with: 'console'
>> 'uart,mmio32,0x10700,115200n8r'
>> 1: [init/main.c:446] do_early_param(): 'earlycon', setup_func 0xc024b868
>> 1: [drivers/tty/serial/earlycon.c:214] param_setup_earlycon():
>> 'uart,mmio32,0x10700,115200n8r'
>> 1: [drivers/tty/serial/earlycon.c:181] setup_earlycon():
>> 'uart,mmio32,0x10700,115200n8r'
>> 1: [drivers/tty/serial/earlycon.c:132] register_earlycon():
>> 'mmio32,0x10700,115200n8r' 'uart'
>> 1: [drivers/tty/serial/earlycon.c:86] parse_options():
>> 'mmio32,0x10700,115200n8r'
>> 1: [drivers/tty/serial/earlycon.c:91] parse_options(): addr 0x00010700,
>> options '115200n8r'
>> 1: [drivers/tty/serial/earlycon.c:117] parse_options(): Early serial
>> console at MMIO32 0x10700 (options '115200n8r')
>> 1: [drivers/tty/serial/earlycon.c:138] register_earlycon(): '(null)'
>> 1: [drivers/tty/serial/earlycon.c:62] earlycon_map(): paddr 0x00010700
>> size 64
>>
>> As you can see, now that the options are more complete, the match for
>> "earlycon" succeeds, but it does not work, the last log is in
>> earlycon_map() function.
>> When using just "console=uart", the "earlycon" match will fail but a
>> match for "earlyprink" will succeed. That one will hook printch() from
>> the arch-dependent code to a somewhat simpler 'earlycon'
>> (arch/arm/kernel/early_printk.c).
>>
>> I think the code is the same on mainline.
>>
>> Also, regarding my previous question about using a HW described in DT
>> for earlycon, I noticed there's a of_setup_earlycon() in
>> drivers/tty/serial/earlycon.c but that is hooked to
>> drivers/of/fdt.c:setup_of_earlycon() which is not called. I do have
>> CONFIG_SERIAL_EARLYCON=y.
>>
>> I also have a similar issue (ie: get blocked right after the call to
>> earlycon_map function, log is obviously different from above) if attempt
>> to use of_setup_earlycon.
>> My DT has roughly:
>>
>>      aliases {
>>          serial0 = &uart;
>>      };
>>
>>      chosen {
>>             bootargs = "earlycon console mem=256M earlyprintk debug
>> ignore_loglevel";
>>             stdout-path = "serial0:115200n8";
>>      };
>>
>>      uart: serial@10700 {
>>          compatible = "ralink,rt2880-uart";
>>          reg = <0x10700 0x30>;
>>          interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
>>          clock-frequency = <7372800>;
>>          reg-shift = <2>;
>>      };
>>
>>
>> and then I hack drivers/tty/serial/8250/8250_early.c by adding:
>>
>>      OF_EARLYCON_DECLARE(rt2880, "ralink,rt2880-uart",
>> early_serial8250_setup);

There is no support for this uart in 8250 earlycon; the registers
need remapped.

>> at the end of the file, trying to mimic commit
>> d05f15707bb7659d2b863fafa1a918f286d74a63
>>
>> I'm still trying to figure out the right bootargs, so that's why both
>> "earlycon" and "console" are there. Suggestions welcome.

Just 'earlycon' triggers the attempted registration of earlycon matching the
compatible string of the stdout-path node.

The empty 'console' in bootargs is doing nothing.


> Does anybody has comments or suggestions regarding this thread and the issue above?

Regards,
Peter Hurley

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-11 16:10 +0100
  Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 17:20 +0100
    Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-11 19:00 +0100
      Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 20:10 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 21:00 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-11 21:30 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Mason <slash.tmp@free.fr> - 2016-01-12 10:40 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-12 15:30 +0100
            Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 20:50 +0100
              Re: [RFC PATCH] always probe UART HW when options are not specified Mason <slash.tmp@free.fr> - 2016-01-12 23:30 +0100
                Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 23:50 +0100
              Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-13 12:20 +0100
                Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-13 17:40 +0100
        Re: [RFC PATCH] always probe UART HW when options are not specified Sebastian Frias <sf84@laposte.net> - 2016-01-12 15:20 +0100
          Re: [RFC PATCH] always probe UART HW when options are not specified Peter Hurley <peter@hurleysoftware.com> - 2016-01-12 22:20 +0100

csiph-web