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
| ||
|
Date: Tue, 12 Jan 2016 15:14:31 +0100 From: Sebastian Frias <sf84@...oste.net> To: Peter Hurley <peter@...leysoftware.com> CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, mason <slash.tmp@...e.fr>, Måns Rullgård <mans@...sr.com> Subject: Re: [RFC PATCH] always probe UART HW when options are not specified Hi Peter, On 01/11/2016 08:06 PM, Peter Hurley wrote: > On 01/11/2016 09:56 AM, Sebastian Frias wrote: >> Hi Peter, >> >> On 01/11/2016 05:11 PM, Peter Hurley wrote: >>> On 01/11/2016 07:07 AM, Sebastian Frias wrote: >>>> On 12/22/2015 06:56 PM, Sebastian Frias wrote: >>>>> >>>>> OF_EARLYCON_DECLARE(rt2880, "ralink,rt2880-uart", >>>>> early_serial8250_setup); >>> >>> There is no support for this uart in 8250 earlycon; the registers >>> need remapped. >> >> Ok, two questions then: >> 1) If the UART is not supported on 8250 earlycon, what is the >> suggested/advised solution? Using just "earlyprintk"? > > I don't have enough information to suggest what you "should" use > here. > > Is this going to be a shipping product? > Is it single-core? > etc. > > And what is your purpose for outputting early boot information > before loading the serial driver which does provide console output? > No, it is not for production, just for debug, but we would like to understand if there is a standard way of doing so, so that whenever somebody ask us for "early print", we can provide with the good way. I know we can always provide with hacks, I'm just wondering if there's a "standard way". > >> 2) What would it take to make the "rt2880" work with the 8250 >> earlycon? I mean, it is already pretty much supported in there, what >> would be missing? (I don't see why it blocks on earlycon_map) And >> would it be worth doing? > > The rt2880 does not have the same register locations as a 8250. > The 8250 port driver remaps all register accesses with a LUT. > > Adding support would be trivial. Ok, I will see if I can find some commit that does something similar to get some inspiration. > >>>>> 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. >> >> Ok, thanks. >> >> So, just to recap. >> We would like to understand what is the right way of doing this: >> >> - we are using 8250 (rt288x variant) UART: CONFIG_SERIAL_8250_RT288X=y >> - the UART hardware is setup prior to Linux boot >> - we don't want Linux to change the UART settings, just to pick up >> whatever settings the UART has and take over the UART. >> There were two replies to that, one by Greg Kroah-Hartman >> (http://www.spinics.net/lists/linux-serial/msg20278.html) and one by >> you, where you suggested we use "console=uart", but as I reported >> (http://www.spinics.net/lists/linux-serial/msg20307.html) it does not >> work, you replied that iotype and mmio are not optional but mandatory >> (http://www.spinics.net/lists/linux-serial/msg20310.html), and I >> wondered if it was really necessary to duplicate data that is already >> on the DT among other questions > > At the time, I didn't know you were describing your h/w with DT. Oh, sorry for the inconvenience then. > > If you use the console command line (console= or earlycon=) to start > an earlycon, then the uart address and iotype are mandatory. > For this usage, earlycon matching is attempted with every EARLYCON_DECLARE(). > > If you use plain "earlycon" on the command line, that will attempt to > register the uart described by stdout-path in DT. For this usage, > earlycon matching is attempted with the compatible string of every > OF_EARLYCON_DECLARE(). I see, and since rt288x variant is not fully supported (no OF_EARLYCON_DECLARE) "earlycon" fails. > >> (http://www.spinics.net/lists/linux-serial/msg20383.html), like how >> are DT described drivers supposed to interact with the >> "console="/"earlycon=" commandlines > > They don't; those are orthogonal. Ok. > >> , or, the contradiction between >> "console=ttyS0" means '9600n81' and "if unspecified [the uart >> options], the h/w is not re-initialized"> > > I thought I was clear on that: "console=ttyS0" initializes the h/w > to 9600n81 *because there are already existing users that must not break*. > > "console=uart,..." probes the h/w > *because there are already existing users that must not break * Thanks, I had misunderstood. > >> So, for us, it is still not clear what is the recommended way of >> achieving our goal above, and it seems it is not clear what does >> "console=ttyS0" is supposed to do, hardcode ('9600n81') or probe >> ('the h/w is not re-initialized') > > The DT way will be simplest at this point because you won't > have to write console handover matching for "console=rt288x,..." > > With DT (ie, stdout-path) earlycon, when a serial driver loads, > an attempt is made to cross-reference any existing console with > the node that is loading and will do a console takeover from > a running earlycon for a matching uart node. > > There is a bug with DT earlycon though. > If you have a dummy console that loads, the DT earlycon is > disabled at that point because boot consoles are disabled when > "real" consoles load. I'm sorry for my ignorance, but what is a "dummy console"? Under what circumstances would it load and this bug be seen? Regards, Sebastian
Powered by blists - more mailing lists