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? > 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. >>>> 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. 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(). > (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. >, 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 * > 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. > Any help will be appreciated. Regards, Peter Hurley -- 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
