Closed xnox closed 3 years ago
We typically set console=ttySIF0,115200 earlycon=sbi
in meta-sifive, but both are enabled as you said.
I don't really expect hvc0
to be used. I do recall that we couldn't avoid it many years ago while running on Spike (before QEMU) IIRC.
On Fedora/RISCV side hvc0
is still there, but it masked as disk creation time. Also remember that this serial driver depends on SBI v0.1 legacy extension and there is no "modern" extension in SBI for console. Legacy extensions are optional for SBI implementation. Thus in some implementations CONFIG_HVC_RISCV_SBI
and CONFIG_SERIAL_EARLYCON_RISCV_SBI
wouldn't work. These drivers depend on CONFIG_RISCV_SBI_V01
(aka legacy stuff, aka SBI v0.1 which mainly documented existing behavior before specification started). To finish RISCV_SBI_V01
(and SBI v0.1) will be deprecated.
See the original upstreaming comment:
commit afa6b1ccfad5e72918b79461a97fe21d1c2292da
Author: Palmer Dabbelt <palmer@sifive.com>
Date: Thu Mar 8 14:27:34 2018 -0800
tty: New RISC-V SBI console driver
The RISC-V ISA defines a simple console that is availiable via SBI calls
on all systems. The SBI console is designed to be availiable at all
times, so while it's most natural to use this as an early printk target
it's also possible to use this as the system console when there isn't a
better one availiable.
This patch adds support for the RISC-V SBI console via the HVC
infastructure. It's entirely independent from our early printk support,
which results in early boot messages appearing twice over the SBI
console. As far as I can tell that's the fault of our early printk
support (we should support earlycon) as opposed to this driver.
There is one checkpatch.pl warning here: to check the MAINTAINERS file.
They're all matched by the "K: riscv" line.
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I wonder which consoles are available in qemu then. And if there is virtio one, or something else.
I wonder if instead of masking hvc0 in all the places, we should change kernel default config to build with CONFIG_HVC_RISCV_SBI=n ?
We can also change systemd upstream generator to stop generating hvc0 console by default on riscv64.
Also, I feel like 115200
should become the default baud rate in the kernel upstream. Because it's 2021.
I have ~170 QEMU instances running Fedora/RISCV and hcv0
is masked in all of them. Thinking about it I most likely will disable all legacy based stuff once SBI v0.3 happens (soon). All QEMU VMs are created via libvirt.
I really feel like building kernel with CONFIG_HVC_RISCV_SBI=n / not set then. That way one will need not to mask hvc0 either.
I did a quick test and disable those options:
+# CONFIG_RISCV_SBI_V01 is not set
+# CONFIG_SERIAL_EARLYCON_RISCV_SBI is not set
+# CONFIG_HVC_RISCV_SBI is not set
Then removed console=ttySIF0,115200 earlycon=sbi"
and didn't observe any major difference.
Then I added earlycon
to the bootargs and the kernel used DT to find the right UART node:
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] earlycon: sifive0 at MMIO 0x0000000010010000 (options '')
[ 0.000000] printk: bootconsole [sifive0] enabled
[ 0.000000] efi: UEFI not found.
Before (the current default):
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[ 0.000000] printk: bootconsole [sbi0] enabled
[ 0.000000] efi: UEFI not found
It seems that there is early SBI based console. That there is hvc0 (virtual console) provided by sbi? which is the same as ttySIF0?
However it seems that hvc0 & ttySIF0 are the same. And systemd starts serial-getty on both. Hence if one doesn't specify any options, one ends up with two consoles at the same time.
Also whilst there is ttySIF1 console, getty is not started there by default.
I am wondering what would be the best kernel cmdline option that would be universal and work in Qemu, SiFive and non-SiFive boards.
something like
console=hvc0 earlycon=sbi
?