riscv-qemu & 16550 serial

[Richard W.M. Jones]

I've compiled riscv-linux (riscv-next branch) with the suggested
config options:

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y

after adding the extra file arch/riscv/include/asm/serial.h.

But using the latest riscv-qemu (master branch) I get no output at all.

The command line I'm using is:

./riscv64-softmmu/qemu-system-riscv64 -m 4G -kernel /home/rjones/tmp/riscv-tools/riscv64-unknown-elf/bin/bbl -append /home/rjones/d/riscv-linux/vmlinux -serial stdio

Do you have a command line that works, or any suggestions what might
be wrong?

[This brings me back to a rant I have about ARM. Wouldn't it be great
if every single RISC-V had a simple, standard UART at a fixed address?
No exceptions. It should be written into the privspec as a
non-optional feature.]

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Bruce Hoult]

Yes, it would be.

The only publicly buyable hardware at present, the E310-G000, has UART0 at 0x10013000 (in a 4K window) with txdata at offset 0 and rxdata, txctrl, rxctrl, ie, ip, div at successive word-addresses. See:

https://www.sifive.com/documentation/chips/freedom-e310-g000-manual/

Maybe it would be good to retrofit Spike and qemu to support that.

I see ARM often likes to put GPIO 0 that that address.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20171218150342.GE6044%40redhat.com.

[Tommy Murphy]

Having a UART should definitely NOT be mandatory.

Otherwise the claim that RISC-V can serve all domains from tiny deeply embedded bare metal platforms upwards is undermined.

In some cases even having a UART is a luxury.

[Richard W.M. Jones]

On Mon, Dec 18, 2017 at 03:03:42PM +0000, Richard W.M. Jones wrote:
> ./riscv64-softmmu/qemu-system-riscv64 -m 4G -kernel /home/rjones/tmp/riscv-tools/riscv64-unknown-elf/bin/bbl -append /home/rjones/d/riscv-linux/vmlinux -serial stdio

Sorry I cut and pasted the wrong command there. The actual command
I'm using is:

$ ./riscv64-softmmu/qemu-system-riscv64 -m 2G -kernel /home/rjones/tmp/riscv-tools/riscv64-unknown-elf/bin/bbl -append console=/dev/ttyS0

(with or without -serial stdio).

This bbl has the Linux kernel with 16550 support as a payload, but I
did just now wonder if bbl itself supports the 16550 UART. I guess
not. Are there ways to enable that?

[Richard W.M. Jones]

I now found the documentation for -M virt and read the sources
which helps a lot:

https://github.com/riscv/riscv-qemu/commit/3446cee04256753a29c45b033d643fcdea24fc72

I wonder why bbl is still needed in this scenario? Wouldn't it be
possible to just boot Linux directly?

[Michael Clark]

> On 19/12/2017, at 4:57 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
>
>
> I now found the documentation for -M virt and read the sources
> which helps a lot:
>
> https://github.com/riscv/riscv-qemu/commit/3446cee04256753a29c45b033d643fcdea24fc72
>
> I wonder why bbl is still needed in this scenario? Wouldn't it be
> possible to just boot Linux directly?

Possibly, although currently the monitor is used to handle instruction emulation and M mode interrupts.

BTW current top-of-tree BBL will detect the 16550a UART in device-tree and the SBI interfaces will output to the UART vs HTIF, and there are also boards in QEMU with the SiFive UART. e.g. the sifive_e300 and sifive_u500 boards.

Some more details will come soon… We are working on a blog post…

[Richard W.M. Jones]

Back to the topic of consoles, I'm almost there but it looks as if
there's been a recent upstream patch which disables the early console
aggressively. I see:

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 1, base_baud = 230400) is a 16550A
loop: module loaded
bootconsole [early0] uses init memory and must be disabled even before the real one is ready
bootconsole [early0] disabled

... and of course after that, nothing more.

Is only ‘console=/dev/console’ needed on the kernel command line? It
seems to find the UART fine but it's not creating the real console ...

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Richard W.M. Jones]

Ignore this.

I have now read your other email, and I got it working, thanks!

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com

virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top