All of lore.kernel.org
 help / color / mirror / Atom feed
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 16:42 ` Marc Gonzalez
  0 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-03-03 16:42 UTC (permalink / raw)
  To: linux-serial
  Cc: Greg Kroah-Hartman, Thibaud Cornic, Arnd Bergmann, Linux ARM,
	Peter Hurley

Hello,

I'm confused about early consoles and earlyprintk, and all that good stuff.
When my kernel panics, I don't get the expected output.

Using "mem=256M ignore_loglevel earlyprintk"

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65536 pages, LIFO batch:15
[    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
[    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mem=256M ignore_loglevel earlyprintk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
[    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
[    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
[    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[    0.007960] Switching to timer-based delay loop, resolution 37ns
[    0.014325] Console: colour dummy device 80x30
[    0.018885] console [tty0] enabled
[    0.022396] bootconsole [earlycon0] disabled

And it hangs there.


If I use an explicit console= configuration, I do see the panic.
Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65536 pages, LIFO batch:15
[    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
[    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
[    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
[    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
[    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[    0.007961] Switching to timer-based delay loop, resolution 37ns
[    0.014325] Console: colour dummy device 80x30
[    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[    0.029316] pid_max: default: 32768 minimum: 301
[    0.034135] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.040876] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.048527] CPU: Testing write buffer coherency: ok
[    0.053736] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.059560] Setting up static identity map for 0x80100000 - 0x80100034
[    0.120467] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.120530] Brought up 2 CPUs
[    0.129381] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[    0.135771] CPU: All CPU(s) started in SVC mode.
[    0.141062] devtmpfs: initialized
[    0.145393] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.153490] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[    0.163772] NET: Registered protocol family 16
[    0.169026] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.177030] Kernel panic - not syncing: FAKE PANIC
[    0.177030] 
[    0.183510] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #153
[    0.190154] Hardware name: Sigma Tango DT
[    0.194301] [<c010ed94>] (unwind_backtrace) from [<c010ae24>] (show_stack+0x10/0x14)
[    0.202176] [<c010ae24>] (show_stack) from [<c02cecc0>] (dump_stack+0x78/0x8c)
[    0.209527] [<c02cecc0>] (dump_stack) from [<c018b634>] (panic+0xdc/0x248)
[    0.216530] [<c018b634>] (panic) from [<c0607acc>] (xenv_lookup.constprop.1+0x0/0x64)
[    0.224493] [<c0607acc>] (xenv_lookup.constprop.1) from [<c0220830>] (proc_create_data+0x74/0xb8)
[    0.233501] [<c0220830>] (proc_create_data) from [<c050fa08>] (0xc050fa08)
[    0.240499] CPU1: stopping
[    0.243303] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.7-1-rc2 #153
[    0.249946] Hardware name: Sigma Tango DT
[    0.254065] [<c010ed94>] (unwind_backtrace) from [<c010ae24>] (show_stack+0x10/0x14)
[    0.261937] [<c010ae24>] (show_stack) from [<c02cecc0>] (dump_stack+0x78/0x8c)
[    0.269283] [<c02cecc0>] (dump_stack) from [<c010dc10>] (handle_IPI+0x198/0x1ac)
[    0.276803] [<c010dc10>] (handle_IPI) from [<c01014a4>] (gic_handle_irq+0x88/0x8c)
[    0.284499] [<c01014a4>] (gic_handle_irq) from [<c010b90c>] (__irq_svc+0x6c/0xa8)
[    0.292104] Exception stack(0xcf859f98 to 0xcf859fe0)
[    0.297263] 9f80:                                                       00000001 00000000
[    0.305568] 9fa0: 000002d8 c0114620 cf858000 c1002fe4 c1003048 00000002 c100ba2e 413fc090
[    0.313874] 9fc0: 00000000 00000000 32dcd555 cf859fe8 c0108220 c0108224 60000013 ffffffff
[    0.322182] [<c010b90c>] (__irq_svc) from [<c0108224>] (arch_cpu_idle+0x38/0x3c)
[    0.329707] [<c0108224>] (arch_cpu_idle) from [<c0151f4c>] (cpu_startup_entry+0xcc/0x144)
[    0.338015] [<c0151f4c>] (cpu_startup_entry) from [<8010154c>] (0x8010154c)
[    0.345103] ---[ end Kernel panic - not syncing: FAKE PANIC


I suppose this is related to my DT description?

	chosen {
		stdout-path = "serial:115200n8";
	};

Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
console=ttyS0,115200 ?

I must be missing something.

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 16:42 ` Marc Gonzalez
  0 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-03-03 16:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

I'm confused about early consoles and earlyprintk, and all that good stuff.
When my kernel panics, I don't get the expected output.

Using "mem=256M ignore_loglevel earlyprintk"

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65536 pages, LIFO batch:15
[    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
[    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mem=256M ignore_loglevel earlyprintk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
[    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
[    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
[    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[    0.007960] Switching to timer-based delay loop, resolution 37ns
[    0.014325] Console: colour dummy device 80x30
[    0.018885] console [tty0] enabled
[    0.022396] bootconsole [earlycon0] disabled

And it hangs there.


If I use an explicit console= configuration, I do see the panic.
Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 65536
[    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65536 pages, LIFO batch:15
[    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
[    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
[    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
[    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
[    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
[    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
[    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
[    0.007961] Switching to timer-based delay loop, resolution 37ns
[    0.014325] Console: colour dummy device 80x30
[    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[    0.029316] pid_max: default: 32768 minimum: 301
[    0.034135] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.040876] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.048527] CPU: Testing write buffer coherency: ok
[    0.053736] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.059560] Setting up static identity map for 0x80100000 - 0x80100034
[    0.120467] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.120530] Brought up 2 CPUs
[    0.129381] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[    0.135771] CPU: All CPU(s) started in SVC mode.
[    0.141062] devtmpfs: initialized
[    0.145393] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.153490] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[    0.163772] NET: Registered protocol family 16
[    0.169026] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.177030] Kernel panic - not syncing: FAKE PANIC
[    0.177030] 
[    0.183510] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #153
[    0.190154] Hardware name: Sigma Tango DT
[    0.194301] [<c010ed94>] (unwind_backtrace) from [<c010ae24>] (show_stack+0x10/0x14)
[    0.202176] [<c010ae24>] (show_stack) from [<c02cecc0>] (dump_stack+0x78/0x8c)
[    0.209527] [<c02cecc0>] (dump_stack) from [<c018b634>] (panic+0xdc/0x248)
[    0.216530] [<c018b634>] (panic) from [<c0607acc>] (xenv_lookup.constprop.1+0x0/0x64)
[    0.224493] [<c0607acc>] (xenv_lookup.constprop.1) from [<c0220830>] (proc_create_data+0x74/0xb8)
[    0.233501] [<c0220830>] (proc_create_data) from [<c050fa08>] (0xc050fa08)
[    0.240499] CPU1: stopping
[    0.243303] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.7-1-rc2 #153
[    0.249946] Hardware name: Sigma Tango DT
[    0.254065] [<c010ed94>] (unwind_backtrace) from [<c010ae24>] (show_stack+0x10/0x14)
[    0.261937] [<c010ae24>] (show_stack) from [<c02cecc0>] (dump_stack+0x78/0x8c)
[    0.269283] [<c02cecc0>] (dump_stack) from [<c010dc10>] (handle_IPI+0x198/0x1ac)
[    0.276803] [<c010dc10>] (handle_IPI) from [<c01014a4>] (gic_handle_irq+0x88/0x8c)
[    0.284499] [<c01014a4>] (gic_handle_irq) from [<c010b90c>] (__irq_svc+0x6c/0xa8)
[    0.292104] Exception stack(0xcf859f98 to 0xcf859fe0)
[    0.297263] 9f80:                                                       00000001 00000000
[    0.305568] 9fa0: 000002d8 c0114620 cf858000 c1002fe4 c1003048 00000002 c100ba2e 413fc090
[    0.313874] 9fc0: 00000000 00000000 32dcd555 cf859fe8 c0108220 c0108224 60000013 ffffffff
[    0.322182] [<c010b90c>] (__irq_svc) from [<c0108224>] (arch_cpu_idle+0x38/0x3c)
[    0.329707] [<c0108224>] (arch_cpu_idle) from [<c0151f4c>] (cpu_startup_entry+0xcc/0x144)
[    0.338015] [<c0151f4c>] (cpu_startup_entry) from [<8010154c>] (0x8010154c)
[    0.345103] ---[ end Kernel panic - not syncing: FAKE PANIC


I suppose this is related to my DT description?

	chosen {
		stdout-path = "serial:115200n8";
	};

Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
console=ttyS0,115200 ?

I must be missing something.

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 16:42 ` Marc Gonzalez
@ 2017-03-03 16:55   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 16:55 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM

On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
> Hello,
> 
> I'm confused about early consoles and earlyprintk, and all that good stuff.
> When my kernel panics, I don't get the expected output.
> 
> Using "mem=256M ignore_loglevel earlyprintk"
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
> [    0.000000] debug: ignoring loglevel setting.
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] On node 0 totalpages: 65536
> [    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
> [    0.000000]   Normal zone: 512 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 65536 pages, LIFO batch:15
> [    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
> [    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
> [    0.000000] Kernel command line: mem=256M ignore_loglevel earlyprintk
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
> [    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
> [    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
> [    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000]  Build-time adjustment of leaf fanout to 32.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> [    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] L2C-310 enabling early BRESP for Cortex-A9
> [    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
> [    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
> [    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
> [    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
> [    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
> [    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
> [    0.007960] Switching to timer-based delay loop, resolution 37ns
> [    0.014325] Console: colour dummy device 80x30
> [    0.018885] console [tty0] enabled
> [    0.022396] bootconsole [earlycon0] disabled
> 
> And it hangs there.

tty0 is the kernel virtual terminal console, which is what appears on
VGA or framebuffers.  This is the default console if nothing else is
specified.

What happened here is that the virtual terminal console registered, was
detected to be the system console, so early console was shut down, and
the boot messages logged to the virtual terminal console instead.

> If I use an explicit console= configuration, I do see the panic.
> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"

The extra console= tells the kernel to use the serial port as the system
console, rather than the virtual terminal console.  The serial port
driver was not registered by the time your panic happened, so the
system console was never installed, and so the early console remained
in place.

Early console outputs the console messages until the system console has
been registered.

Note: "registered" does not necessarily mean "capable of producing
visible output".  Framebuffer initialisation happens after the VT
console has been registered.

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 16:55   ` Russell King - ARM Linux
  0 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 16:55 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
> Hello,
> 
> I'm confused about early consoles and earlyprintk, and all that good stuff.
> When my kernel panics, I don't get the expected output.
> 
> Using "mem=256M ignore_loglevel earlyprintk"
> 
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #153 SMP PREEMPT Fri Mar 3 17:31:37 CET 2017
> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
> [    0.000000] debug: ignoring loglevel setting.
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] On node 0 totalpages: 65536
> [    0.000000] free_area_init_node: node 0, pgdat c10234c0, node_mem_map cfdf9000
> [    0.000000]   Normal zone: 512 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 65536 pages, LIFO batch:15
> [    0.000000] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 u57344
> [    0.000000] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
> [    0.000000] Kernel command line: mem=256M ignore_loglevel earlyprintk
> [    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> [    0.000000] Memory: 243980K/262144K available (4096K kernel code, 146K rwdata, 876K rodata, 10240K init, 233K bss, 18164K reserved, 0K 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 : 0xd0800000 - 0xff800000   ( 752 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> [    0.000000]       .text : 0xc0008000 - 0xc0500000   (5088 kB)
> [    0.000000]       .init : 0xc0600000 - 0xc1000000   (10240 kB)
> [    0.000000]       .data : 0xc1000000 - 0xc1024860   ( 147 kB)
> [    0.000000]        .bss : 0xc1024860 - 0xc105ed40   ( 234 kB)
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000]  Build-time adjustment of leaf fanout to 32.
> [    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> [    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] L2C-310 enabling early BRESP for Cortex-A9
> [    0.000000] L2C-310 ID prefetch enabled, offset 4 lines
> [    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
> [    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
> [    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x72860401
> [    0.000000] clocksource: tango-xtal: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 70787423951 ns
> [    0.000004] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 79536431085ns
> [    0.007960] Switching to timer-based delay loop, resolution 37ns
> [    0.014325] Console: colour dummy device 80x30
> [    0.018885] console [tty0] enabled
> [    0.022396] bootconsole [earlycon0] disabled
> 
> And it hangs there.

tty0 is the kernel virtual terminal console, which is what appears on
VGA or framebuffers.  This is the default console if nothing else is
specified.

What happened here is that the virtual terminal console registered, was
detected to be the system console, so early console was shut down, and
the boot messages logged to the virtual terminal console instead.

> If I use an explicit console= configuration, I do see the panic.
> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"

The extra console= tells the kernel to use the serial port as the system
console, rather than the virtual terminal console.  The serial port
driver was not registered by the time your panic happened, so the
system console was never installed, and so the early console remained
in place.

Early console outputs the console messages until the system console has
been registered.

Note: "registered" does not necessarily mean "capable of producing
visible output".  Framebuffer initialisation happens after the VT
console has been registered.

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 16:42 ` Marc Gonzalez
@ 2017-03-03 16:59   ` Andreas Färber
  -1 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 16:59 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM

Hi,

Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
> I'm confused about early consoles and earlyprintk, and all that good stuff.
> When my kernel panics, I don't get the expected output.
> 
> Using "mem=256M ignore_loglevel earlyprintk"
[...]
> [    0.014325] Console: colour dummy device 80x30
> [    0.018885] console [tty0] enabled
> [    0.022396] bootconsole [earlycon0] disabled
> 
> And it hangs there.
> 
> 
> If I use an explicit console= configuration, I do see the panic.
> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"
[...]
> [    0.014325] Console: colour dummy device 80x30
> [    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[...]

I have reported a similar phenomenon for multiple new SoCs.

> I suppose this is related to my DT description?
> 
> 	chosen {
> 		stdout-path = "serial:115200n8";
> 	};
> 
> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
> console=ttyS0,115200 ?

First of all, that should probably be serial0, and it needs to be
defined as an alias. In my case that's a given.

And yes, AFAIU stdout-path = "serialX:115200n8" should lead to
ttyFOOX,115200n8 being used, in your case it may be ttyS0.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 16:59   ` Andreas Färber
  0 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 16:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
> I'm confused about early consoles and earlyprintk, and all that good stuff.
> When my kernel panics, I don't get the expected output.
> 
> Using "mem=256M ignore_loglevel earlyprintk"
[...]
> [    0.014325] Console: colour dummy device 80x30
> [    0.018885] console [tty0] enabled
> [    0.022396] bootconsole [earlycon0] disabled
> 
> And it hangs there.
> 
> 
> If I use an explicit console= configuration, I do see the panic.
> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"
[...]
> [    0.014325] Console: colour dummy device 80x30
> [    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
[...]

I have reported a similar phenomenon for multiple new SoCs.

> I suppose this is related to my DT description?
> 
> 	chosen {
> 		stdout-path = "serial:115200n8";
> 	};
> 
> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
> console=ttyS0,115200 ?

First of all, that should probably be serial0, and it needs to be
defined as an alias. In my case that's a given.

And yes, AFAIU stdout-path = "serialX:115200n8" should lead to
ttyFOOX,115200n8 being used, in your case it may be ttyS0.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 16:59   ` Andreas Färber
@ 2017-03-03 17:07     ` Marc Gonzalez
  -1 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-03-03 17:07 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM

On 03/03/2017 17:59, Andreas Färber wrote:

> Hi,
> 
> Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>> When my kernel panics, I don't get the expected output.
>>
>> Using "mem=256M ignore_loglevel earlyprintk"
> [...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018885] console [tty0] enabled
>> [    0.022396] bootconsole [earlycon0] disabled
>>
>> And it hangs there.
>>
>>
>> If I use an explicit console= configuration, I do see the panic.
>> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"
> [...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
> [...]
> 
> I have reported a similar phenomenon for multiple new SoCs.
> 
>> I suppose this is related to my DT description?
>>
>> 	chosen {
>> 		stdout-path = "serial:115200n8";
>> 	};
>>
>> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
>> console=ttyS0,115200 ?
> 
> First of all, that should probably be serial0, and it needs to be
> defined as an alias. In my case that's a given.

My DT root node contains

	aliases {
		serial = &uart;
		eth0 = &eth0;
	};

Should I be using serial0 everywhere?
(I thought I could call it "foo", if I wanted.)

> And yes, AFAIU stdout-path = "serialX:115200n8" should lead to
> ttyFOOX,115200n8 being used, in your case it may be ttyS0.

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 17:07     ` Marc Gonzalez
  0 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-03-03 17:07 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/03/2017 17:59, Andreas F?rber wrote:

> Hi,
> 
> Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>> When my kernel panics, I don't get the expected output.
>>
>> Using "mem=256M ignore_loglevel earlyprintk"
> [...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018885] console [tty0] enabled
>> [    0.022396] bootconsole [earlycon0] disabled
>>
>> And it hangs there.
>>
>>
>> If I use an explicit console= configuration, I do see the panic.
>> Using "mem=256M ignore_loglevel console=ttyS0,115200 earlyprintk"
> [...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018899] Calibrating delay loop (skipped), value calculated using timer frequency.. 54.25 BogoMIPS (lpj=90000)
> [...]
> 
> I have reported a similar phenomenon for multiple new SoCs.
> 
>> I suppose this is related to my DT description?
>>
>> 	chosen {
>> 		stdout-path = "serial:115200n8";
>> 	};
>>
>> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
>> console=ttyS0,115200 ?
> 
> First of all, that should probably be serial0, and it needs to be
> defined as an alias. In my case that's a given.

My DT root node contains

	aliases {
		serial = &uart;
		eth0 = &eth0;
	};

Should I be using serial0 everywhere?
(I thought I could call it "foo", if I wanted.)

> And yes, AFAIU stdout-path = "serialX:115200n8" should lead to
> ttyFOOX,115200n8 being used, in your case it may be ttyS0.

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 17:07     ` Marc Gonzalez
@ 2017-03-03 17:17       ` Andreas Färber
  -1 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 17:17 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM

Am 03.03.2017 um 18:07 schrieb Marc Gonzalez:
> On 03/03/2017 17:59, Andreas Färber wrote:
>> Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
>>> 	chosen {
>>> 		stdout-path = "serial:115200n8";
>>> 	};
>>>
>>> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
>>> console=ttyS0,115200 ?
>>
>> First of all, that should probably be serial0, and it needs to be
>> defined as an alias. In my case that's a given.
> 
> My DT root node contains
> 
> 	aliases {
> 		serial = &uart;
> 		eth0 = &eth0;
> 	};
> 
> Should I be using serial0 everywhere?
> (I thought I could call it "foo", if I wanted.)

Most serial drivers call of_alias_get_id() to retrieve the index - feel
free to add some debug output to see whether "serial" and "serial0"
behave the same, I haven't tested - literal "foo" will definitely behave
differently since the drivers check for "serial".

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 17:17       ` Andreas Färber
  0 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 17:17 UTC (permalink / raw)
  To: linux-arm-kernel

Am 03.03.2017 um 18:07 schrieb Marc Gonzalez:
> On 03/03/2017 17:59, Andreas F?rber wrote:
>> Am 03.03.2017 um 17:42 schrieb Marc Gonzalez:
>>> 	chosen {
>>> 		stdout-path = "serial:115200n8";
>>> 	};
>>>
>>> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
>>> console=ttyS0,115200 ?
>>
>> First of all, that should probably be serial0, and it needs to be
>> defined as an alias. In my case that's a given.
> 
> My DT root node contains
> 
> 	aliases {
> 		serial = &uart;
> 		eth0 = &eth0;
> 	};
> 
> Should I be using serial0 everywhere?
> (I thought I could call it "foo", if I wanted.)

Most serial drivers call of_alias_get_id() to retrieve the index - feel
free to add some debug output to see whether "serial" and "serial0"
behave the same, I haven't tested - literal "foo" will definitely behave
differently since the drivers check for "serial".

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 17:07     ` Marc Gonzalez
@ 2017-03-03 17:18       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 17:18 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Andreas Färber, Linux ARM

On Fri, Mar 03, 2017 at 06:07:39PM +0100, Marc Gonzalez wrote:
> On 03/03/2017 17:59, Andreas Färber wrote:
> >> I suppose this is related to my DT description?
> >>
> >> 	chosen {
> >> 		stdout-path = "serial:115200n8";
> >> 	};
> >>
> >> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
> >> console=ttyS0,115200 ?
> > 
> > First of all, that should probably be serial0, and it needs to be
> > defined as an alias. In my case that's a given.
> 
> My DT root node contains
> 
> 	aliases {
> 		serial = &uart;
> 		eth0 = &eth0;
> 	};
> 
> Should I be using serial0 everywhere?
> (I thought I could call it "foo", if I wanted.)

Correct, stdout-path contains the node name - please see
Documentation/devicetree/bindings/chosen.txt for the definitive
information.

Setting the early console has no effect on the eventual system
console that the kernel chooses.  See these files:

drivers/of/fdt.c
drivers/tty/serial/earlycon.c

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 17:18       ` Russell King - ARM Linux
  0 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 17:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 03, 2017 at 06:07:39PM +0100, Marc Gonzalez wrote:
> On 03/03/2017 17:59, Andreas F?rber wrote:
> >> I suppose this is related to my DT description?
> >>
> >> 	chosen {
> >> 		stdout-path = "serial:115200n8";
> >> 	};
> >>
> >> Isn't stdout-path = "serial:115200n8" supposed to be equivalent to
> >> console=ttyS0,115200 ?
> > 
> > First of all, that should probably be serial0, and it needs to be
> > defined as an alias. In my case that's a given.
> 
> My DT root node contains
> 
> 	aliases {
> 		serial = &uart;
> 		eth0 = &eth0;
> 	};
> 
> Should I be using serial0 everywhere?
> (I thought I could call it "foo", if I wanted.)

Correct, stdout-path contains the node name - please see
Documentation/devicetree/bindings/chosen.txt for the definitive
information.

Setting the early console has no effect on the eventual system
console that the kernel chooses.  See these files:

drivers/of/fdt.c
drivers/tty/serial/earlycon.c

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 16:55   ` Russell King - ARM Linux
@ 2017-03-03 17:26     ` Andreas Färber
  -1 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 17:26 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM, Marc Gonzalez

Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>> When my kernel panics, I don't get the expected output.
>>
>> Using "mem=256M ignore_loglevel earlyprintk"
>>
[...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018885] console [tty0] enabled
>> [    0.022396] bootconsole [earlycon0] disabled
>>
>> And it hangs there.
> 
> tty0 is the kernel virtual terminal console, which is what appears on
> VGA or framebuffers.  This is the default console if nothing else is
> specified.
> 
> What happened here is that the virtual terminal console registered, was
> detected to be the system console, so early console was shut down, and
> the boot messages logged to the virtual terminal console instead.

Why does passing console= make a difference though?

I expect stdout-path to have the same effect as the command line, and I
am pretty sure that that was previous behavior in, e.g., v4.4.

Note that I am using earlycon, as opposed to earlyprintk above.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 17:26     ` Andreas Färber
  0 siblings, 0 replies; 20+ messages in thread
From: Andreas Färber @ 2017-03-03 17:26 UTC (permalink / raw)
  To: linux-arm-kernel

Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>> When my kernel panics, I don't get the expected output.
>>
>> Using "mem=256M ignore_loglevel earlyprintk"
>>
[...]
>> [    0.014325] Console: colour dummy device 80x30
>> [    0.018885] console [tty0] enabled
>> [    0.022396] bootconsole [earlycon0] disabled
>>
>> And it hangs there.
> 
> tty0 is the kernel virtual terminal console, which is what appears on
> VGA or framebuffers.  This is the default console if nothing else is
> specified.
> 
> What happened here is that the virtual terminal console registered, was
> detected to be the system console, so early console was shut down, and
> the boot messages logged to the virtual terminal console instead.

Why does passing console= make a difference though?

I expect stdout-path to have the same effect as the command line, and I
am pretty sure that that was previous behavior in, e.g., v4.4.

Note that I am using earlycon, as opposed to earlyprintk above.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 17:26     ` Andreas Färber
@ 2017-03-03 17:46       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 17:46 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM, Marc Gonzalez

On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
> > On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
> >> I'm confused about early consoles and earlyprintk, and all that good stuff.
> >> When my kernel panics, I don't get the expected output.
> >>
> >> Using "mem=256M ignore_loglevel earlyprintk"
> >>
> [...]
> >> [    0.014325] Console: colour dummy device 80x30
> >> [    0.018885] console [tty0] enabled
> >> [    0.022396] bootconsole [earlycon0] disabled
> >>
> >> And it hangs there.
> > 
> > tty0 is the kernel virtual terminal console, which is what appears on
> > VGA or framebuffers.  This is the default console if nothing else is
> > specified.
> > 
> > What happened here is that the virtual terminal console registered, was
> > detected to be the system console, so early console was shut down, and
> > the boot messages logged to the virtual terminal console instead.
> 
> Why does passing console= make a difference though?
> 
> I expect stdout-path to have the same effect as the command line, and I
> am pretty sure that that was previous behavior in, e.g., v4.4.
> 
> Note that I am using earlycon, as opposed to earlyprintk above.

The property is:

	stdout-path = "dt-node-name:hw-parameters";

and this is parsed by the code in drivers/of/fdt.c,
early_init_dt_scan_chosen_stdout() (briefly):

        offset = fdt_path_offset(fdt, "/chosen");
        p = fdt_getprop(fdt, offset, "stdout-path", &l);

        q = strchrnul(p, ':');
        if (*q != '\0')
                options = q + 1;
        l = q - p;

        /* Get the node specified by stdout-path */
        offset = fdt_path_offset_namelen(fdt, p, l);
        if (offset < 0) {
                pr_warn("earlycon: stdout-path %.*s not found\n", l, p);

So here, offset points at the node named by "dt-node-name" above.

This function then tries to patch the specified node's compatible with
the drivers in the __earlycon_table:

        for (match = __earlycon_table; match < __earlycon_table_end; match++) {
                if (!match->compatible[0])
                        continue;

                if (fdt_node_check_compatible(fdt, offset, match->compatible))
                        continue;

and when a match is found, calls:

                of_setup_earlycon(match, offset, options);

Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
the standard properties (like "reg", etc) filling out a uart_port
before calling the early console's ->setup method.  If everything goes
to plan, register_console() is called to register the early console.

So there's nothing there which changes the default system console.

The next place is of_alias_scan() in drivers/of/base.c.  This records
the device_node and options in of_stdout and of_stdout_options
respectively - it, again, does not change the default system console.

When a serial console is initialised, of_console_check() gets called by
serial core to check whether the DT node for it is "of_stdout", and if
it matches, it modifies the preferred system console.

This all looks good, and one might expect that it has the desired
effect, but this code is fatally flawed in design: the point at which
of_console_check() gets called is _way_ after consoles like the virtual
terminal console get initialised.  What this means is that, at the point
in time that the virtual terminal is initialised, as far as the console
system is concerned, the preferred console is still the virtual terminal.
It knows nothing about the desire for a different console.

Given the current console handling, it's not easy to solve without
overhauling the way consoles are chosen - the root problem is that the
Linux console system works via Linux device driver names and indexes,
and there's no easy way to translate a DT stdout-path property to a
Linux device driver name and index without the driver having been
initialised.

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-03-03 17:46       ` Russell King - ARM Linux
  0 siblings, 0 replies; 20+ messages in thread
From: Russell King - ARM Linux @ 2017-03-03 17:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas F?rber wrote:
> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
> > On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
> >> I'm confused about early consoles and earlyprintk, and all that good stuff.
> >> When my kernel panics, I don't get the expected output.
> >>
> >> Using "mem=256M ignore_loglevel earlyprintk"
> >>
> [...]
> >> [    0.014325] Console: colour dummy device 80x30
> >> [    0.018885] console [tty0] enabled
> >> [    0.022396] bootconsole [earlycon0] disabled
> >>
> >> And it hangs there.
> > 
> > tty0 is the kernel virtual terminal console, which is what appears on
> > VGA or framebuffers.  This is the default console if nothing else is
> > specified.
> > 
> > What happened here is that the virtual terminal console registered, was
> > detected to be the system console, so early console was shut down, and
> > the boot messages logged to the virtual terminal console instead.
> 
> Why does passing console= make a difference though?
> 
> I expect stdout-path to have the same effect as the command line, and I
> am pretty sure that that was previous behavior in, e.g., v4.4.
> 
> Note that I am using earlycon, as opposed to earlyprintk above.

The property is:

	stdout-path = "dt-node-name:hw-parameters";

and this is parsed by the code in drivers/of/fdt.c,
early_init_dt_scan_chosen_stdout() (briefly):

        offset = fdt_path_offset(fdt, "/chosen");
        p = fdt_getprop(fdt, offset, "stdout-path", &l);

        q = strchrnul(p, ':');
        if (*q != '\0')
                options = q + 1;
        l = q - p;

        /* Get the node specified by stdout-path */
        offset = fdt_path_offset_namelen(fdt, p, l);
        if (offset < 0) {
                pr_warn("earlycon: stdout-path %.*s not found\n", l, p);

So here, offset points@the node named by "dt-node-name" above.

This function then tries to patch the specified node's compatible with
the drivers in the __earlycon_table:

        for (match = __earlycon_table; match < __earlycon_table_end; match++) {
                if (!match->compatible[0])
                        continue;

                if (fdt_node_check_compatible(fdt, offset, match->compatible))
                        continue;

and when a match is found, calls:

                of_setup_earlycon(match, offset, options);

Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
the standard properties (like "reg", etc) filling out a uart_port
before calling the early console's ->setup method.  If everything goes
to plan, register_console() is called to register the early console.

So there's nothing there which changes the default system console.

The next place is of_alias_scan() in drivers/of/base.c.  This records
the device_node and options in of_stdout and of_stdout_options
respectively - it, again, does not change the default system console.

When a serial console is initialised, of_console_check() gets called by
serial core to check whether the DT node for it is "of_stdout", and if
it matches, it modifies the preferred system console.

This all looks good, and one might expect that it has the desired
effect, but this code is fatally flawed in design: the point at which
of_console_check() gets called is _way_ after consoles like the virtual
terminal console get initialised.  What this means is that, at the point
in time that the virtual terminal is initialised, as far as the console
system is concerned, the preferred console is still the virtual terminal.
It knows nothing about the desire for a different console.

Given the current console handling, it's not easy to solve without
overhauling the way consoles are chosen - the root problem is that the
Linux console system works via Linux device driver names and indexes,
and there's no easy way to translate a DT stdout-path property to a
Linux device driver name and index without the driver having been
initialised.

-- 
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.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 17:46       ` Russell King - ARM Linux
@ 2017-04-05 14:02         ` Marc Gonzalez
  -1 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-04-05 14:02 UTC (permalink / raw)
  To: Russell King - ARM Linux, Andreas Farber
  Cc: Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman, Thibaud Cornic,
	linux-serial, Linux ARM

On 03/03/2017 18:46, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>> [...]
>>>> [    0.014325] Console: colour dummy device 80x30
>>>> [    0.018885] console [tty0] enabled
>>>> [    0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers.  This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
> 
> The property is:
> 
> 	stdout-path = "dt-node-name:hw-parameters";
> 
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
> 
>         offset = fdt_path_offset(fdt, "/chosen");
>         p = fdt_getprop(fdt, offset, "stdout-path", &l);
> 
>         q = strchrnul(p, ':');
>         if (*q != '\0')
>                 options = q + 1;
>         l = q - p;
> 
>         /* Get the node specified by stdout-path */
>         offset = fdt_path_offset_namelen(fdt, p, l);
>         if (offset < 0) {
>                 pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
> 
> So here, offset points at the node named by "dt-node-name" above.
> 
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
> 
>         for (match = __earlycon_table; match < __earlycon_table_end; match++) {
>                 if (!match->compatible[0])
>                         continue;
> 
>                 if (fdt_node_check_compatible(fdt, offset, match->compatible))
>                         continue;
> 
> and when a match is found, calls:
> 
>                 of_setup_earlycon(match, offset, options);
> 
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method.  If everything goes
> to plan, register_console() is called to register the early console.
> 
> So there's nothing there which changes the default system console.
> 
> The next place is of_alias_scan() in drivers/of/base.c.  This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
> 
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
> 
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised.  What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
> 
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.

One issue with earlyprintk is that one must hard-code the UART address
directly into the kernel binary. If I build one kernel for two different
boards that don't have the same UART address, I'm going to run into
problems, right?

Is early console a better solution for this use-case?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-04-05 14:02         ` Marc Gonzalez
  0 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-04-05 14:02 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/03/2017 18:46, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas F?rber wrote:
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>> [...]
>>>> [    0.014325] Console: colour dummy device 80x30
>>>> [    0.018885] console [tty0] enabled
>>>> [    0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers.  This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
> 
> The property is:
> 
> 	stdout-path = "dt-node-name:hw-parameters";
> 
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
> 
>         offset = fdt_path_offset(fdt, "/chosen");
>         p = fdt_getprop(fdt, offset, "stdout-path", &l);
> 
>         q = strchrnul(p, ':');
>         if (*q != '\0')
>                 options = q + 1;
>         l = q - p;
> 
>         /* Get the node specified by stdout-path */
>         offset = fdt_path_offset_namelen(fdt, p, l);
>         if (offset < 0) {
>                 pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
> 
> So here, offset points at the node named by "dt-node-name" above.
> 
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
> 
>         for (match = __earlycon_table; match < __earlycon_table_end; match++) {
>                 if (!match->compatible[0])
>                         continue;
> 
>                 if (fdt_node_check_compatible(fdt, offset, match->compatible))
>                         continue;
> 
> and when a match is found, calls:
> 
>                 of_setup_earlycon(match, offset, options);
> 
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method.  If everything goes
> to plan, register_console() is called to register the early console.
> 
> So there's nothing there which changes the default system console.
> 
> The next place is of_alias_scan() in drivers/of/base.c.  This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
> 
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
> 
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised.  What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
> 
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.

One issue with earlyprintk is that one must hard-code the UART address
directly into the kernel binary. If I build one kernel for two different
boards that don't have the same UART address, I'm going to run into
problems, right?

Is early console a better solution for this use-case?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* Re: No output on console despite ignore_loglevel earlyprintk
  2017-03-03 17:46       ` Russell King - ARM Linux
@ 2017-04-05 16:37         ` Marc Gonzalez
  -1 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-04-05 16:37 UTC (permalink / raw)
  To: Russell King - ARM Linux, Andreas Farber
  Cc: Rob Herring, Peter Hurley, Arnd Bergmann, Greg Kroah-Hartman,
	Thibaud Cornic, linux-serial, Linux ARM

On 03/03/2017 18:46, Russell King - ARM Linux wrote:

> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas Färber wrote:
>
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>>>> [    0.014325] Console: colour dummy device 80x30
>>>> [    0.018885] console [tty0] enabled
>>>> [    0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers.  This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
> 
> The property is:
> 
> 	stdout-path = "dt-node-name:hw-parameters";
> 
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
> 
>         offset = fdt_path_offset(fdt, "/chosen");
>         p = fdt_getprop(fdt, offset, "stdout-path", &l);
> 
>         q = strchrnul(p, ':');
>         if (*q != '\0')
>                 options = q + 1;
>         l = q - p;
> 
>         /* Get the node specified by stdout-path */
>         offset = fdt_path_offset_namelen(fdt, p, l);
>         if (offset < 0) {
>                 pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
> 
> So here, offset points at the node named by "dt-node-name" above.
> 
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
> 
>         for (match = __earlycon_table; match < __earlycon_table_end; match++) {
>                 if (!match->compatible[0])
>                         continue;
> 
>                 if (fdt_node_check_compatible(fdt, offset, match->compatible))
>                         continue;
> 
> and when a match is found, calls:
> 
>                 of_setup_earlycon(match, offset, options);
> 
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method.  If everything goes
> to plan, register_console() is called to register the early console.
> 
> So there's nothing there which changes the default system console.
> 
> The next place is of_alias_scan() in drivers/of/base.c.  This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
> 
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
> 
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised.  What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
> 
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.

Time for me to take another stab at this issue.


Relevant parts of my DT:

	aliases { serial = &uart; };

	chosen { stdout-path = "serial:115200n8"; };

		uart: serial@10700 {
			compatible = "ralink,rt2880-uart";
			reg = <0x10700 0x30>;
			interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
			clock-frequency = <7372800>;
			reg-shift = <2>;
		};


Relevant part of my kernel config:

CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_OF_EARLY_FLATTREE=y

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_FSL=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
CONFIG_SERIAL_8250_RT288X=y
# CONFIG_SERIAL_8250_MOXA is not set
CONFIG_SERIAL_OF_PLATFORM=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_BCM63XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_SERIAL_STM32 is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set

CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"


Booting with mem=256M console=ttyS0,115200

[    0.000213] Console: colour dummy device 80x30
[    0.418383] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.419837] console [ttyS0] disabled
[    0.419983] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.000504] console [ttyS0] enabled


Booting with mem=256M

[    0.000212] Console: colour dummy device 80x30
[    0.000547] console [tty0] enabled
[    0.427260] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.428970] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.007672] console [ttyS0] enabled


Booting with mem=256M earlycon

[    0.000000] ENTER param_setup_earlycon
[    0.000000] ENTER early_init_dt_scan_chosen_stdout
[    0.000000] early_init_dt_scan_chosen_stdout: scan __earlycon_table
[    0.000000] name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
[    0.000000] name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
[    0.000000] name=ns16550a compatible=ns16550a setup=early_serial8250_setup
[    0.000000] name=ns16550 compatible=ns16550 setup=early_serial8250_setup
[    0.000000] early_init_dt_scan_chosen_stdout: NO MATCH, return ENODEV
[    0.000000] Malformed early option 'earlycon'
[    0.000215] Console: colour dummy device 80x30
[    0.000583] console [tty0] enabled
[    0.420043] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.421945] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.014251] console [ttyS0] enabled


drivers/tty/serial/8250/8250_early.c

int __init early_serial8250_setup(struct earlycon_device *device, const char *options)

EARLYCON_DECLARE(uart8250, early_serial8250_setup);
EARLYCON_DECLARE(uart, early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550, "ns16550", early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550a, "ns16550a", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "nvidia,tegra20-uart", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "snps,dw-apb-uart", early_serial8250_setup);

I'm not matching anything, because my UART compatible string is:

		uart: serial@10700 {
			compatible = "ralink,rt2880-uart";

If I append "ns16550a" or "ns16550", the kernel hangs from the start:

Starting kernel ...

@


But if I add DEBUG_LL support with

CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_8250=y
CONFIG_DEBUG_UART_PHYS=0x10700
CONFIG_DEBUG_UART_VIRT=0xf0010700
CONFIG_DEBUG_UART_8250_WORD=y
CONFIG_DEBUG_UART_8250_PALMCHIP=y

and replace the implementation of vprintk_emit() with a very quick and dirty

	char buf[400];
	extern void printascii(const char *);
	text_len = vsnprintf(buf, sizeof buf, fmt, args);
	printascii(buf);
	return text_len;

then the kernel boots correctly, and I see the following relevant logs:

ENTER param_setup_earlycon
ENTER early_init_dt_scan_chosen_stdout
early_init_dt_scan_chosen_stdout: scan __earlycon_table
name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
name=ns16550a compatible=ns16550a setup=early_serial8250_setup
ENTER of_setup_earlycon
earlycon: ns16550a0 at MMIO 0x00010700 (options '115200n8')
bootconsole [ns16550a0] enabled
Kernel command line: mem=256M earlycon
Console: colour dummy device 80x30
console [tty0] enabled
bootconsole [ns16550a0] disabled
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
console [ttyS0] enabled


I think the problem is that my UART (Palmchip BK-3103) requires
custom accessors to read/write 16550 registers. And these accessors
are probably ignored this early in the boot.

drivers/tty/serial/8250/8250_port.c

#ifdef CONFIG_SERIAL_8250_RT288X

/* Au1x00/RT288x UART hardware has a weird register layout */
static const s8 au_io_in_map[8] = {
	 0,	/* UART_RX  */
	 2,	/* UART_IER */
	 3,	/* UART_IIR */
	 5,	/* UART_LCR */
	 6,	/* UART_MCR */
	 7,	/* UART_LSR */
	 8,	/* UART_MSR */
	-1,	/* UART_SCR (unmapped) */
};

It is likely that I need to register a specific OF_EARLYCON_DECLARE,
like OMAP did?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
* No output on console despite ignore_loglevel earlyprintk
@ 2017-04-05 16:37         ` Marc Gonzalez
  0 siblings, 0 replies; 20+ messages in thread
From: Marc Gonzalez @ 2017-04-05 16:37 UTC (permalink / raw)
  To: linux-arm-kernel

On 03/03/2017 18:46, Russell King - ARM Linux wrote:

> On Fri, Mar 03, 2017 at 06:26:28PM +0100, Andreas F?rber wrote:
>
>> Am 03.03.2017 um 17:55 schrieb Russell King - ARM Linux:
>>
>>> On Fri, Mar 03, 2017 at 05:42:02PM +0100, Marc Gonzalez wrote:
>>>
>>>> I'm confused about early consoles and earlyprintk, and all that good stuff.
>>>> When my kernel panics, I don't get the expected output.
>>>>
>>>> Using "mem=256M ignore_loglevel earlyprintk"
>>>>
>>>> [    0.014325] Console: colour dummy device 80x30
>>>> [    0.018885] console [tty0] enabled
>>>> [    0.022396] bootconsole [earlycon0] disabled
>>>>
>>>> And it hangs there.
>>>
>>> tty0 is the kernel virtual terminal console, which is what appears on
>>> VGA or framebuffers.  This is the default console if nothing else is
>>> specified.
>>>
>>> What happened here is that the virtual terminal console registered, was
>>> detected to be the system console, so early console was shut down, and
>>> the boot messages logged to the virtual terminal console instead.
>>
>> Why does passing console= make a difference though?
>>
>> I expect stdout-path to have the same effect as the command line, and I
>> am pretty sure that that was previous behavior in, e.g., v4.4.
>>
>> Note that I am using earlycon, as opposed to earlyprintk above.
> 
> The property is:
> 
> 	stdout-path = "dt-node-name:hw-parameters";
> 
> and this is parsed by the code in drivers/of/fdt.c,
> early_init_dt_scan_chosen_stdout() (briefly):
> 
>         offset = fdt_path_offset(fdt, "/chosen");
>         p = fdt_getprop(fdt, offset, "stdout-path", &l);
> 
>         q = strchrnul(p, ':');
>         if (*q != '\0')
>                 options = q + 1;
>         l = q - p;
> 
>         /* Get the node specified by stdout-path */
>         offset = fdt_path_offset_namelen(fdt, p, l);
>         if (offset < 0) {
>                 pr_warn("earlycon: stdout-path %.*s not found\n", l, p);
> 
> So here, offset points at the node named by "dt-node-name" above.
> 
> This function then tries to patch the specified node's compatible with
> the drivers in the __earlycon_table:
> 
>         for (match = __earlycon_table; match < __earlycon_table_end; match++) {
>                 if (!match->compatible[0])
>                         continue;
> 
>                 if (fdt_node_check_compatible(fdt, offset, match->compatible))
>                         continue;
> 
> and when a match is found, calls:
> 
>                 of_setup_earlycon(match, offset, options);
> 
> Here, we go into the code in drivers/tty/serial/earlycon.c, which reads
> the standard properties (like "reg", etc) filling out a uart_port
> before calling the early console's ->setup method.  If everything goes
> to plan, register_console() is called to register the early console.
> 
> So there's nothing there which changes the default system console.
> 
> The next place is of_alias_scan() in drivers/of/base.c.  This records
> the device_node and options in of_stdout and of_stdout_options
> respectively - it, again, does not change the default system console.
> 
> When a serial console is initialised, of_console_check() gets called by
> serial core to check whether the DT node for it is "of_stdout", and if
> it matches, it modifies the preferred system console.
> 
> This all looks good, and one might expect that it has the desired
> effect, but this code is fatally flawed in design: the point at which
> of_console_check() gets called is _way_ after consoles like the virtual
> terminal console get initialised.  What this means is that, at the point
> in time that the virtual terminal is initialised, as far as the console
> system is concerned, the preferred console is still the virtual terminal.
> It knows nothing about the desire for a different console.
> 
> Given the current console handling, it's not easy to solve without
> overhauling the way consoles are chosen - the root problem is that the
> Linux console system works via Linux device driver names and indexes,
> and there's no easy way to translate a DT stdout-path property to a
> Linux device driver name and index without the driver having been
> initialised.

Time for me to take another stab at this issue.


Relevant parts of my DT:

	aliases { serial = &uart; };

	chosen { stdout-path = "serial:115200n8"; };

		uart: serial at 10700 {
			compatible = "ralink,rt2880-uart";
			reg = <0x10700 0x30>;
			interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
			clock-frequency = <7372800>;
			reg-shift = <2>;
		};


Relevant part of my kernel config:

CONFIG_FIX_EARLYCON_MEM=y
CONFIG_GENERIC_EARLY_IOREMAP=y
CONFIG_OF_EARLY_FLATTREE=y

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_FSL=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set
CONFIG_SERIAL_8250_RT288X=y
# CONFIG_SERIAL_8250_MOXA is not set
CONFIG_SERIAL_OF_PLATFORM=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_BCM63XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_SERIAL_STM32 is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set

CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"


Booting with mem=256M console=ttyS0,115200

[    0.000213] Console: colour dummy device 80x30
[    0.418383] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.419837] console [ttyS0] disabled
[    0.419983] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.000504] console [ttyS0] enabled


Booting with mem=256M

[    0.000212] Console: colour dummy device 80x30
[    0.000547] console [tty0] enabled
[    0.427260] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.428970] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.007672] console [ttyS0] enabled


Booting with mem=256M earlycon

[    0.000000] ENTER param_setup_earlycon
[    0.000000] ENTER early_init_dt_scan_chosen_stdout
[    0.000000] early_init_dt_scan_chosen_stdout: scan __earlycon_table
[    0.000000] name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
[    0.000000] name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
[    0.000000] name=ns16550a compatible=ns16550a setup=early_serial8250_setup
[    0.000000] name=ns16550 compatible=ns16550 setup=early_serial8250_setup
[    0.000000] early_init_dt_scan_chosen_stdout: NO MATCH, return ENODEV
[    0.000000] Malformed early option 'earlycon'
[    0.000215] Console: colour dummy device 80x30
[    0.000583] console [tty0] enabled
[    0.420043] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.421945] 10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
[    1.014251] console [ttyS0] enabled


drivers/tty/serial/8250/8250_early.c

int __init early_serial8250_setup(struct earlycon_device *device, const char *options)

EARLYCON_DECLARE(uart8250, early_serial8250_setup);
EARLYCON_DECLARE(uart, early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550, "ns16550", early_serial8250_setup);
OF_EARLYCON_DECLARE(ns16550a, "ns16550a", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "nvidia,tegra20-uart", early_serial8250_setup);
OF_EARLYCON_DECLARE(uart, "snps,dw-apb-uart", early_serial8250_setup);

I'm not matching anything, because my UART compatible string is:

		uart: serial at 10700 {
			compatible = "ralink,rt2880-uart";

If I append "ns16550a" or "ns16550", the kernel hangs from the start:

Starting kernel ...

@


But if I add DEBUG_LL support with

CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_8250=y
CONFIG_DEBUG_UART_PHYS=0x10700
CONFIG_DEBUG_UART_VIRT=0xf0010700
CONFIG_DEBUG_UART_8250_WORD=y
CONFIG_DEBUG_UART_8250_PALMCHIP=y

and replace the implementation of vprintk_emit() with a very quick and dirty

	char buf[400];
	extern void printascii(const char *);
	text_len = vsnprintf(buf, sizeof buf, fmt, args);
	printascii(buf);
	return text_len;

then the kernel boots correctly, and I see the following relevant logs:

ENTER param_setup_earlycon
ENTER early_init_dt_scan_chosen_stdout
early_init_dt_scan_chosen_stdout: scan __earlycon_table
name=uart compatible=snps,dw-apb-uart setup=early_serial8250_setup
name=uart compatible=nvidia,tegra20-uart setup=early_serial8250_setup
name=ns16550a compatible=ns16550a setup=early_serial8250_setup
ENTER of_setup_earlycon
earlycon: ns16550a0 at MMIO 0x00010700 (options '115200n8')
bootconsole [ns16550a0] enabled
Kernel command line: mem=256M earlycon
Console: colour dummy device 80x30
console [tty0] enabled
bootconsole [ns16550a0] disabled
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10700.serial: ttyS0 at MMIO 0x10700 (irq = 20, base_baud = 460800) is a Palmchip BK-3103
console [ttyS0] enabled


I think the problem is that my UART (Palmchip BK-3103) requires
custom accessors to read/write 16550 registers. And these accessors
are probably ignored this early in the boot.

drivers/tty/serial/8250/8250_port.c

#ifdef CONFIG_SERIAL_8250_RT288X

/* Au1x00/RT288x UART hardware has a weird register layout */
static const s8 au_io_in_map[8] = {
	 0,	/* UART_RX  */
	 2,	/* UART_IER */
	 3,	/* UART_IIR */
	 5,	/* UART_LCR */
	 6,	/* UART_MCR */
	 7,	/* UART_LSR */
	 8,	/* UART_MSR */
	-1,	/* UART_SCR (unmapped) */
};

It is likely that I need to register a specific OF_EARLYCON_DECLARE,
like OMAP did?

Regards.

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-04-05 16:37 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-03 16:42 No output on console despite ignore_loglevel earlyprintk Marc Gonzalez
2017-03-03 16:42 ` Marc Gonzalez
2017-03-03 16:55 ` Russell King - ARM Linux
2017-03-03 16:55   ` Russell King - ARM Linux
2017-03-03 17:26   ` Andreas Färber
2017-03-03 17:26     ` Andreas Färber
2017-03-03 17:46     ` Russell King - ARM Linux
2017-03-03 17:46       ` Russell King - ARM Linux
2017-04-05 14:02       ` Marc Gonzalez
2017-04-05 14:02         ` Marc Gonzalez
2017-04-05 16:37       ` Marc Gonzalez
2017-04-05 16:37         ` Marc Gonzalez
2017-03-03 16:59 ` Andreas Färber
2017-03-03 16:59   ` Andreas Färber
2017-03-03 17:07   ` Marc Gonzalez
2017-03-03 17:07     ` Marc Gonzalez
2017-03-03 17:17     ` Andreas Färber
2017-03-03 17:17       ` Andreas Färber
2017-03-03 17:18     ` Russell King - ARM Linux
2017-03-03 17:18       ` Russell King - ARM Linux

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.