Implement a minimal MMIO 8250 UART #53

Open
wants to merge 3 commits into
from

Conversation

Projects
None yet
6 participants
@neuschaefer
Contributor

neuschaefer commented Jun 10, 2016

See the commit message for more information.

@neuschaefer

This comment has been minimized.

Show comment
Hide comment
@neuschaefer

neuschaefer Jun 10, 2016

Contributor

The pupose of this is to have a console interface in spike that's easier to use in coreboot than the HTIF, since the HTIF requires special ELF symbols, and coreboot compiles to a "ROM image" and is only later turned back into an ELF that spike can load.

Contributor

neuschaefer commented Jun 10, 2016

The pupose of this is to have a console interface in spike that's easier to use in coreboot than the HTIF, since the HTIF requires special ELF symbols, and coreboot compiles to a "ROM image" and is only later turned back into an ELF that spike can load.

@aswaterman

This comment has been minimized.

Show comment
Hide comment
@aswaterman

aswaterman Jun 10, 2016

Member

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug port. The intent is that the debug module will expose serial ports. These will show up as devices in the memory map, and will be the standard way of generating debug console output during boot.

Your approach makes sense to me, but I would prefer to see the debug serial stuff through before deciding to add another console device. I'll try to minimize disruption so it's feasible to maintain this on a branch in the mean time.

Member

aswaterman commented Jun 10, 2016

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug port. The intent is that the debug module will expose serial ports. These will show up as devices in the memory map, and will be the standard way of generating debug console output during boot.

Your approach makes sense to me, but I would prefer to see the debug serial stuff through before deciding to add another console device. I'll try to minimize disruption so it's feasible to maintain this on a branch in the mean time.

@neuschaefer

This comment has been minimized.

Show comment
Hide comment
@neuschaefer

neuschaefer Jun 10, 2016

Contributor

That makes sense, thanks.

Contributor

neuschaefer commented Jun 10, 2016

That makes sense, thanks.

pgeorgi pushed a commit to coreboot/coreboot that referenced this pull request Jun 12, 2016

riscv-spike: Replace custom UART with a memory-mapped 8250
Since the HTIF is a non-standard interface, and coreboot already has a
8250 driver, I started implementing an 8250 core for spike[1].

[1]: riscv/riscv-isa-sim#53

Change-Id: I84adc1169474baa8cc5837358a8ad3d184cfa51b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15150
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
riscv/devices.cc
@@ -1,4 +1,5 @@
#include "devices.h"
+#include <stdio.h>

This comment has been minimized.

@neuschaefer

neuschaefer Jun 13, 2016

Contributor

Oops, this line shouldn't be in the commit.

@neuschaefer

neuschaefer Jun 13, 2016

Contributor

Oops, this line shouldn't be in the commit.

frantony added a commit to frantony/barebox that referenced this pull request Oct 13, 2016

add riscv support
This patch adds initial RISC-V architecture support for barebox.

At the moment only spike emulator is supported (see https://github.com/riscv/riscv-isa-sim
for details). Moreover barebox does not works with spike's emulated
serial port directly. Barebox runs on top of riscv proxy kernel
(pk, see https://github.com/riscv/riscv-pk). In many ways
RISC-V barebox modus operandi is very similar to sandbox barebox.

Current spike and qemu-riscv (https://github.com/riscv/riscv-isa-sim)
emulators support only HTIF (Host-Target InterFace) for serial console,
though adding 8250 UART port support for spike pull request
is exists (see riscv/riscv-isa-sim#53).

Running RISC-V barebox mini-HOWTO
=================================

Obtain RISC-V GCC/Newlib Toolchain and pk (proxy kernel);
see https://github.com/riscv/riscv-tools/blob/master/README.md
for details, the build.sh script from riscv-tools should
create toolchain, pk ELF image and the spike emulator.

Next compile barebox:

    $ git clone -b 20161013.riscv https://github.com/frantony/barebox
    $ cd barebox
    $ make pk_defconfig ARCH=riscv
    ...
    $ make ARCH=riscv CROSS_COMPILE=riscv64-unknown-elf-

Run barebox:

    $ spike pk barebox

    Board: riscv proxy kernel
    Warning: Using dummy clocksource
    malloc space: 0x00067640 -> 0x0046763f (size 4 MiB)
    running /env/bin/init...
    /env/bin/init not found
    barebox:/

TIP: riscv-tools buils.sh script installs pk ELF image into
${TOOLCHAIN_INSTALL_PATH}/riscv64-unknown-elf/bin directory.

Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>

frantony added a commit to frantony/barebox that referenced this pull request Oct 13, 2016

add riscv support
This patch adds initial RISC-V architecture support for barebox.

At the moment only spike emulator is supported (see https://github.com/riscv/riscv-isa-sim
for details). Moreover barebox does not works with spike's emulated
serial port directly. Barebox runs on top of riscv proxy kernel
(pk, see https://github.com/riscv/riscv-pk). In many ways
RISC-V barebox modus operandi is very similar to sandbox barebox.

Current spike and qemu-riscv (https://github.com/riscv/riscv-isa-sim)
emulators support only HTIF (Host-Target InterFace) for serial console,
though adding 8250 UART port support for spike pull request
is exists (see riscv/riscv-isa-sim#53).

Running RISC-V barebox mini-HOWTO
=================================

Obtain RISC-V GCC/Newlib Toolchain and pk (proxy kernel);
see https://github.com/riscv/riscv-tools/blob/master/README.md
for details, the build.sh script from riscv-tools should
create toolchain, pk ELF image and the spike emulator.

Next compile barebox:

    $ git clone -b 20161013.riscv https://github.com/frantony/barebox
    $ cd barebox
    $ make pk_defconfig ARCH=riscv
    ...
    $ make ARCH=riscv CROSS_COMPILE=riscv64-unknown-elf-

Run barebox:

    $ spike pk barebox

    Board: riscv proxy kernel
    Warning: Using dummy clocksource
    malloc space: 0x00067640 -> 0x0046763f (size 4 MiB)
    running /env/bin/init...
    /env/bin/init not found
    barebox:/

TIP: riscv-tools buils.sh script installs pk ELF image into
${TOOLCHAIN_INSTALL_PATH}/riscv64-unknown-elf/bin directory.

Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
@frantony

This comment has been minimized.

Show comment
Hide comment
@frantony

frantony Oct 31, 2016

@aswaterman

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug port. The intent is that the debug module will expose serial ports. These will show up as devices in the memory map, and will be the standard way of generating debug console output during boot.

At the moment HTIF is still only serial port for riscv-sim-isa.
I can't find exhaustive debug module serial port description. The document RISC-V External Debug Support Version 0.11 (sep 22 2016) has draft status (e.g. Serial Send 0 register's address is not defined).
Is anybody working on adding standard RISC-V Debug port support to riscv-sim-isa?

@aswaterman

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug port. The intent is that the debug module will expose serial ports. These will show up as devices in the memory map, and will be the standard way of generating debug console output during boot.

At the moment HTIF is still only serial port for riscv-sim-isa.
I can't find exhaustive debug module serial port description. The document RISC-V External Debug Support Version 0.11 (sep 22 2016) has draft status (e.g. Serial Send 0 register's address is not defined).
Is anybody working on adding standard RISC-V Debug port support to riscv-sim-isa?

@timsifive

This comment has been minimized.

Show comment
Hide comment
@timsifive

timsifive Oct 31, 2016

Contributor

On Sun, Oct 30, 2016 at 5:11 PM, Antony Pavlov notifications@github.com
wrote:

@aswaterman https://github.com/aswaterman

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug
port. The intent is that the debug module will expose serial ports. These
will show up as devices in the memory map, and will be the standard way of
generating debug console output during boot.

At the moment HTIF is still only serial port for riscv-sim-isa.
I can't find exhaustive debug module serial port description. The document RISC-V
External Debug Support Version 0.11 (sep 22 2016)
https://dev.sifive.com/documentation/risc-v-external-debug-support/ has
draft status (e.g. Serial Send 0 register's address is not defined).
Is anybody working on adding standard RISC-V Debug port support to
riscv-sim-isa?

There is a RISC-V Debug Task Group, and I am its chair. We haven't
officially met yet, but tentatively the group's goal is to decide on a
standard debug interface. That will probably include some serial support.
There's been some discussion on the mailing list (
https://groups.google.com/a/groups.riscv.org/forum/#!forum/debug), but
you're the first to express real interest in the serial support.

Tim

Contributor

timsifive commented Oct 31, 2016

On Sun, Oct 30, 2016 at 5:11 PM, Antony Pavlov notifications@github.com
wrote:

@aswaterman https://github.com/aswaterman

We're getting rid of the HTIF soon, in favor of the standard RISC-V Debug
port. The intent is that the debug module will expose serial ports. These
will show up as devices in the memory map, and will be the standard way of
generating debug console output during boot.

At the moment HTIF is still only serial port for riscv-sim-isa.
I can't find exhaustive debug module serial port description. The document RISC-V
External Debug Support Version 0.11 (sep 22 2016)
https://dev.sifive.com/documentation/risc-v-external-debug-support/ has
draft status (e.g. Serial Send 0 register's address is not defined).
Is anybody working on adding standard RISC-V Debug port support to
riscv-sim-isa?

There is a RISC-V Debug Task Group, and I am its chair. We haven't
officially met yet, but tentatively the group's goal is to decide on a
standard debug interface. That will probably include some serial support.
There's been some discussion on the mailing list (
https://groups.google.com/a/groups.riscv.org/forum/#!forum/debug), but
you're the first to express real interest in the serial support.

Tim

@neuschaefer

This comment has been minimized.

Show comment
Hide comment
@neuschaefer

neuschaefer Oct 31, 2016

Contributor

I, for one, don't care as much how the serial port works, but I do care that there is a serial port, which doesn't require complicated setup — i.e. it should be usable before DRAM is available, and shouldn't require any expensive extra hardware. A simple serial port can make low-level debugging a lot easier.

Contributor

neuschaefer commented Oct 31, 2016

I, for one, don't care as much how the serial port works, but I do care that there is a serial port, which doesn't require complicated setup — i.e. it should be usable before DRAM is available, and shouldn't require any expensive extra hardware. A simple serial port can make low-level debugging a lot easier.

@aswaterman

This comment has been minimized.

Show comment
Hide comment
@aswaterman

aswaterman Oct 31, 2016

Member

The plan is to make Spike accept hardware devices as plugins, rather than baking a specific character device into the simulator. When we do that, we'll also release a model of our platform UART (so the same software will also work on the FPGA models and ASIC implementations).

Member

aswaterman commented Oct 31, 2016

The plan is to make Spike accept hardware devices as plugins, rather than baking a specific character device into the simulator. When we do that, we'll also release a model of our platform UART (so the same software will also work on the FPGA models and ASIC implementations).

@sorear

This comment has been minimized.

Show comment
Hide comment
@sorear

sorear Nov 1, 2016

Contributor

@aswaterman You are referring to the part which sifive/riscv-pk#sifive uses for the SBI console? FYI I have a model for that in QEMU ( https://github.com/riscv/riscv-qemu/blob/master/hw/riscv/sifive_uart.c ) which is complete enough for BBL.

Contributor

sorear commented Nov 1, 2016

@aswaterman You are referring to the part which sifive/riscv-pk#sifive uses for the SBI console? FYI I have a model for that in QEMU ( https://github.com/riscv/riscv-qemu/blob/master/hw/riscv/sifive_uart.c ) which is complete enough for BBL.

@aswaterman

This comment has been minimized.

Show comment
Hide comment
@aswaterman

aswaterman Nov 1, 2016

Member

Yeah, that one, thanks. Of course, as it's a prototype, we're not certain
whether we'll keep that exact register interface.

On Mon, Oct 31, 2016 at 9:08 PM, sorear notifications@github.com wrote:

@aswaterman https://github.com/aswaterman You are referring to the part
which sifive/riscv-pk#sifive uses for the SBI console? FYI I have a model
for that in QEMU ( https://github.com/riscv/riscv-qemu/blob/master/hw/
riscv/sifive_uart.c ) which is complete enough for BBL.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wsRe8HXrhHEX3Y8jV2CwwYPbDVpQks5q5rs5gaJpZM4IzMpu
.

Member

aswaterman commented Nov 1, 2016

Yeah, that one, thanks. Of course, as it's a prototype, we're not certain
whether we'll keep that exact register interface.

On Mon, Oct 31, 2016 at 9:08 PM, sorear notifications@github.com wrote:

@aswaterman https://github.com/aswaterman You are referring to the part
which sifive/riscv-pk#sifive uses for the SBI console? FYI I have a model
for that in QEMU ( https://github.com/riscv/riscv-qemu/blob/master/hw/
riscv/sifive_uart.c ) which is complete enough for BBL.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wsRe8HXrhHEX3Y8jV2CwwYPbDVpQks5q5rs5gaJpZM4IzMpu
.

pgeorgi pushed a commit to coreboot/coreboot that referenced this pull request Jun 12, 2017

mb/emulation/spike-riscv: Update UART address
I updated my spike patch[1] to cleanly apply to current spike master.
As a side effect, the UART is now at 0x02100000.

[1]: riscv/riscv-isa-sim#53

Change-Id: I4cb09014619e230011486fa57636abe183baa4be
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/20126
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>

neuschaefer and others added some commits Sep 18, 2017

Implement a minimal MMIO 8250 UART
Using the HTIF in coreboot is inconvenent, because it requires
defining two special ELF symbols (tohost and fromhost), and coreboot
doesn't natively compile to an ELF file, but rather a raw ROM image.

I tested this patch against coreboot's driver for memory-mapped
8250-compatible UARTs, but most features are missing:

 - Any writes to other registers than the first one are silently
   discarded. This includes the scratch register and the
   interrupt-enable register.
 - Non-byte sized accesses are not supported.
 - The FIFO isn't emulated. Instead every written byte is immediately
   printed on stdout, and the line status register always indicates that
   new bytes can be sent.
 - Input doesn't work, either, but it's added in the following patch.
uart: Fix devicetree syntax for reg-shift
I got the devicetree syntax for integers wrong, and didn't properly test
it. Because of this spike failed with this cryptic error:

> Error: <stdin>:44.19-20 syntax error
> FATAL ERROR: Unable to parse input tree
> Child dtb process failed

This commit fixes it.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
uart: add uart input support
This lets you do in, as well as out.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment