Hi Sebastian, On 01/12/2016 06:14 AM, Sebastian Frias wrote: > On 01/11/2016 08:06 PM, Peter Hurley wrote: >> On 01/11/2016 09:56 AM, Sebastian Frias wrote: >>> 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". Ok. The "standard" solution is either command-line or DT earlycon (which we've established isn't working for your setup). Let's fix that so that both of those options work. >>> 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. I sent you a patch yesterday that adds earlycon support for this uart (so command line should work), plus the series I sent today should get DT earlycon up and running. Please test both. >>>>>> 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. No big deal, I was just explaining the earlier advice. >> 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. Yes. >>> (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? The dummy console is a hack used to preserve the priority of the display console in the event no console is specified. Here's an example: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.4.0-rc6+ (peter@thor) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #86 PREEMPT Tue Jan 12 12:30:39 PST 2016 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: TI AM335x BeagleBone Black [ 0.000000] earlycon: omap8250 at MMIO 0x44e09000 (options '') [ 0.000000] bootconsole [omap8250] enabled [ 0.000000] cma: Reserved 16 MiB at 0x9f000000 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] AM335X ES2.1 (sgx neon ) [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129920 [ 0.000000] Kernel command line: earlycon root=/dev/mmcblk0p2 ro fixrtc rootfstype=ext4 rootwait [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 486332K/524288K available (10582K kernel code, 862K rwdata, 3396K rodata, 596K init, 871K bss, 21572K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xe0800000 - 0xff800000 ( 496 MB) [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0daebf0 (13979 kB) [ 0.000000] .init : 0xc0daf000 - 0xc0e44000 ( 596 kB) [ 0.000000] .data : 0xc0e44000 - 0xc0f1bb3c ( 863 kB) [ 0.000000] .bss : 0xc0f1e000 - 0xc0ff7d84 ( 872 kB) [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts [ 0.000000] OMAP clockevent source: timer2 at 24000000 Hz [ 0.000014] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [ 0.008083] clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.017570] OMAP clocksource: timer1 at 24000000 Hz [ 0.022969] Console: colour dummy device 80x30 [ 0.027570] console [tty0] enabled [ 0.031100] bootconsole [omap8250] disabled Ubuntu 14.04.3 LTS black ttyS0 black login: As you can see, there's boot console but no regular console until getty spawns. I've fixed the problem once, but that broke some setups and had to be reverted so I need to rethink an alternate approach. A unified, coherent solution is elusive because of the many different possible console setups. 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
