From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter@hurleysoftware.com (Peter Hurley) Date: Wed, 21 Oct 2015 15:24:41 -0400 Subject: console vs earlycon ? In-Reply-To: <3890353.0icCv0Zeuq@wuerfel> References: <4963882.HSXu6hF7zO@wuerfel> <5627AFFF.6060900@hurleysoftware.com> <3890353.0icCv0Zeuq@wuerfel> Message-ID: <5627E679.1050207@hurleysoftware.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/21/2015 03:00 PM, Arnd Bergmann wrote: > On Wednesday 21 October 2015 11:32:15 Peter Hurley wrote: >> On 10/21/2015 10:13 AM, Arnd Bergmann wrote: >>> On Wednesday 21 October 2015 09:53:47 Peter Hurley wrote: >>>> I'm assuming the issue with trying to get console_init() working >>>> is because the dummy color console causes the earlycon to be disabled? >>> >>> I don't think so. >>> >>> My line of thinking was more about usability: earlycon requires that >>> you edit the kernel command line at the moment, while console_init() >>> doesn't require any user interaction and just uses the stdout-path. >>> >>> I guess we could enable earlycon using a Kconfig symbol if we want >>> to, or make it a per-architecture decision whether it's enabled even >>> in the absence of the command line flag. >> >> Ah, I see. You want to start the stdout-path console at console_init() >> time. > > Yes, I see this as a tradeoff: we want the console to be as early as > possible in order to report boot-time errors to the user, but not so early > to require hacks that can cause problems themselves. earlycon has to > do some scary stuff and is relatively recent, while the hacks > necessary for console_init() are much older and better tested. I assume you mean the hacks necessary to get _earlycon_ working at console_init() time, because the hacks necessary to get non-8250 serial consoles working at console_init() would be extensive and brand new. Regards, Peter Hurley