linux-kernel - Re: debug tip after earlycon is closed?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 13:20:22 +0100
From:	Russell King - ARM Linux <linux@...linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Peter Hurley <peter@...leysoftware.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Rob Herring <robh+dt@...nel.org>, linux-serial@...r.kernel.org
Subject: Re: debug tip after earlycon is closed?

On Thu, Jul 28, 2016 at 09:44:53AM +0200, Arnd Bergmann wrote:
> 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.

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.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.