On 03/03/2017 18:46, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>> [...]
>>>> [ 0.014325] Console: colour dummy device 80x30
>>>> [ 0.018885] console [tty0] enabled
>>>> [ 0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers. This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
>
> The property is:
>
> stdout-path = "dt-node-name:hw-parameters";
>
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
>
> offset = fdt_path_offset(fdt, "/chosen");
> p = fdt_getprop(fdt, offset, "stdout-path", &l);
>
> q = strchrnul(p, ':');
> if (*q != '\0')
> options = q + 1;
> l = q - p;
>
> /* Get the node specified by stdout-path */
> offset = fdt_path_offset_namelen(fdt, p, l);
> if (offset < 0) {
> pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
>
> So here, offset points at the node named by "dt-node-name" above.
>
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
>
> for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> if (!match->compatible[0])
> continue;
>
> if (fdt_node_check_compatible(fdt, offset, match->compatible))
> continue;
>
> and when a match is found, calls:
>
> of_setup_earlycon(match, offset, options);
>
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method. If everything goes
> to plan, register_console() is called to register the early console.
>
> So there's nothing there which changes the default system console.
>
> The next place is of_alias_scan() in drivers/of/base.c. This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
>
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
>
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised. What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
>
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.
One issue with earlyprintk is that one must hard-code the UART address
directly into the kernel binary. If I build one kernel for two different
boards that don't have the same UART address, I'm going to run into
problems, right?
Is early console a better solution for this use-case?
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
