[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: no networking in riscv-qemu... use pppd?

On 19 Apr 2017, at 4:34 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

On Wed, Apr 19, 2017 at 3:27 AM, Michael Clark <michaeljclark@mac.com> wrote:

The user-mode ABI is pretty much frozen so any user space packages built for
RV32IMAFDC or RV64IMAFDC should be to a stable ABI.

ah good, so a debian port can proceed (and be published) without
having to be completely redone?

I believe so. The base ISA is frozen. RV32IMAFDC and RV64IMAFDC have not changed in the last year. The userspace ABI is stable.

I believe the compiler has now been configured to output RVC compression by default, which means the target depends on the RVC extension.

There is the whole question of whether to target a sub architecture. e.g. RV32IMAC with soft float.

Note the ISA strings are passed lowercase to the toolchain and ABI defaults to hard float e.g.

This is 64-bit hard float ABI with compression (-mabi flag here is the default):

-march=rv64gc -mabi=lp64d

This is 32-bit soft float ABI with compression:

-march=rv3imac -mabi=ilp32
The privileged spec is in flux, however this only affects kernel mode code.

RISCVEMU has Virtio Block, Net and Console. It’s an interpreter so not as
fast as QEMU.

doesn't matter at all.  "working slowly" easily trumps "not working
very very quickly" :)

- http://bellard.org/riscvemu/

In any case it includes a kernel config in the patches directory that can be
used to build a RISC-V VirtIO kernel:

excellent - i have the bbl.bin and root.bin examples on the page
confirmed as working.  i note, interestingly, that the root.bin (from
yocto) includes a native compiler.

i'll try compiling the kernel from that... no instructions found
anywhere to build "bbl.bin" so far... and i'm getting the usual "This
is bbl's dummy_payload.  To boot a real kernel, reconfigure bbl with
the flag --with-payload=PATH, then rebuild bbl." and after doing so
get, "This is bbl's dummy_payload.  To boot a real kernel, reconfigure
bbl with the flag --with-payload=PATH, then rebuild bbl."

hints welcomed

You’ll find the kernel config and HTIF console IO patch for bbl in the RISCVEMU patches directory. NOTE: RISCVEMU needs bbl to be patched. You also need the root kernel command line in Fabrice’s kernel config to set up Virtio.

There is a kernel and bbl build script below that I believe uses a similar VirtIO config and the branch tips are from the same December/January time frame that RISCVEMU was released. It puts busybox in the initramfs. You can point it at a fork of bbl repo with Fabrice’s config and the HTIF console IO patch applied (from the RISCVEMU patches directory).

Of course you need the linux toolchain from riscv-gnu-toolchain

export RISCV=/opt/riscv
./configure --prefix=$RISCV
make linux

You’ll need to change my bbl build scripts repo URLs because the bbl branch pointed to in the script uses UART for console which is not supported by RISCVEMU. I actually tested the boot.bin from RISCVEMU against my RISC-V interpreter, as I also implement the same HTIF console IO device, just the interpreter I am working on lacks VirtIO. Nevertheless you should be able to use my script and modify it to use upstream bbl with the HTIF console IO patch:

Eventually I’ll finishes adding JIT and VirtIO to the full system emulator I am working on so there will be a (potentially faster) alternative to QEMU. The RV64 -> x86_64 JIT engine I am working on operates at about 4-5 BIPS vs 100-200 MIPs for the interpreters. About 1/3rd native speed.

There is also a fedora image linked from the page which includes a
self-hosted compiler.

my primary interest is in seeing the debian port up and running.

RV64GC ?

That is the architecture the bbl.bin and root.bin are built for.

Reply to: