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.
awesome.
> 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
-DBBL_PAYLOAD=\"/home/lkcl/src/riscv/riscv-meta/build/linux-4.6.2/vmlinux\"
-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
--with-payload=${LINUX_BUILD_DIR}/vmlinux
+ CC=riscv64-unknown-elf-gcc ../configure
--host=riscv64-unknown-elf --with-payload=${LINUX_BUILD_DIR}/vmlinux
)
fi
> 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
> RISCVEMU.
ok.
> 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.
nice!
> 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
investigating.
so, your notes above are really appreciated.
l.
Reply to: