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

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

crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Apr 19, 2017 at 8:52 AM, Michael Clark <michaeljclark@mac.com> wrote:
> 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.

 ah!  missed that

> You also
> need the root kernel command line in Fabrice’s kernel config to set up
> Virtio.

 i discovered that

> 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).
> -
> https://github.com/michaeljclark/riscv-meta/blob/master/scripts/bootstrap-linux.sh
> - https://github.com/michaeljclark/riscv-meta/blob/master/doc/src/mmio.md
> - https://github.com/michaeljclark/riscv-meta/blob/master/doc/src/linux.md

 nice!  oh... but bbl-lite doesn't compile as-is (example) ... just
fyi (noted the bit about using a fork of bbl, this is running the
script as-is)

 gcc-6 -MMD -MP -Wall -Werror -D__NO_INLINE__ -mcmodel=medany -O2
-std=gnu99 -Wno-unused -Wno-attributes -fno-delete-null-pointer-checks
-I. -I../bbl -c ../bbl/string.c
gcc-6: error: unrecognized argument in option ‘-mcmodel=medany’
gcc-6: note: valid arguments to ‘-mcmodel=’ are: 32 kernel large medium small

errr..... err.... gcc-6... not riscv64-unknown-elf-gcc :)

ok so that's fixed with this, michael:

diff --git a/scripts/bootstrap-linux.sh b/scripts/bootstrap-linux.sh
index 5691d8a..26a0a45 100755
--- a/scripts/bootstrap-linux.sh
+++ b/scripts/bootstrap-linux.sh
@@ -155,7 +155,7 @@ if [ ! -d "${BBL_BUILD_DIR}/build" ]; then
                mkdir ${BBL_BUILD_DIR}/build
                cd ${BBL_BUILD_DIR}/build
-               ../configure --host=riscv64-unknown-elf
+               CC=riscv64-unknown-elf-gcc ../configure
--host=riscv64-unknown-elf --with-payload=${LINUX_BUILD_DIR}/vmlinux

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

 followed the riscv wiki, got that.  it's nice having a laptop with
16gb of 2400mhz DDR4 RAM, a 2500mb/sec NVMe drive and a quad-core i7,
everything's reaaally quick to compile :)

> 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


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

 that's pretty awesome.  *sigh* i remember the dec alpha team managing
to implement a JIT compiler that smoked x86... no wonder they got
bought out by intel...

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

 i hope so.

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

 the riscvemu published images off the website work fine.  i'm
wondering what/whether it's useful for me to recompile things (i'm not
a fan of doing things that aren't necessary) but... blegh: tap0
networking won't connect between the two, so i'll need to redo bbl.bin
and the kernel (at least).  currently i'm getting 100% cpu usage and
no console output with a recompiled kernel sooo... still

 so, your notes above are really appreciated.


Reply to: