Not found bblvmlinuxinitramfs_v1.10

[hoangt]

According README, we can download bblvmlinuxinitramfs_v1.9 and bblvmlinuxinitramfs_v1.9.1 but I could not get bblvmlinuxinitramfs_v1.10.

Is there any source to generate specific versions of bblvmlinuxinitramfs ?

Thanks !

[sorear]

The driver logic has moved to freedom-u-sdk. Try something like:

git clone --recursive https://github.com/sifive/freedom-u-sdk
cd freedom-u-sdk
make all
make qemu

[michaeljclark]

@palmer-dabbelt we probably want to bump riscv-qemu in freedom-u-sdk. It's currently pointing to a version based on 27-Sep-2016 upstream qemu.

The current riscv-next points to 22-Dec-2017 rebase based on the v1 patchset with various backports.

However https://github.com/riscv/riscv-qemu/tree/qemu-upstream-v5 is based on 7-Feb-2018 rebase and has MTTCG for SMP thanks to @sorear. It would be nice it we could get some more extensive testing on this branch. e.g. glibc test suite on an SMP kernel.

I'm going to spin a v6 and rebase against upstream this week as the changelog has grown a bit.

[sorear]

@michaeljclark @rwmjones has run about 1000 Fedora package builds with f2cc209d in -smp 4 mode over the past few days, FYI.

[michaeljclark]

@sorear okay cool. I've archived the old riscv-next branch as qemu-20180110 (the rebase date) and will promote qemu-upstream-v5 to riscv-next

[michaeljclark]

@sorear @rwmjones @palmer-dabbelt OKay, as of just now, the default riscv-next branch points to the tip of the v5 patchset plus recent changes (also tested on i386), which is based on the 7-Feb-2018 rebase with upstream qemu.

BTW QEMU is going into soft-freeze on 13-Mar-2018 for the 2.12 release:

https://wiki.qemu.org/Planning/2.12

All of the core cpu patches including target/riscv and linux-user have been reviewed, but the devices and machines in hw/riscv have not yet had review.

We could submit a pull request for the core, which would effectively just enable linux-user. In any case, I will rebase and submit a v6 patch series this week. We need a QEMU maintainer to review hw/riscv. Most of the code in hw/riscv is relatively okay. I removed a big chunk of endian unsafe ELF code used by HTIF and made the machines use a new load_elf_ram_sym interface added to elf-ops.h that has a symbol callback function. HTIF exposes htif_symbol_callback to find the HTIF variables. The HTIF code still has more stuff that we can rip out given we are only using it for the console function and poweroff in the spike machines.

[michaeljclark]

The patch series will probably be this Wednesday or Thursday given the public holiday, barring any major difficulties (i.e. difficult rebase conflicts if any core APIs have changed).

We now have a couple of core code changes required. One adds IEEE-754 minimumNumber/maximumNumber to qemu softfloat and another adds a symbol callback interface to the ELF loader. They both need review and softfloat is currently under change.

We now have only one failing test in riscv-tests. Non-canonical NaN-boxed single as an argument to single FP ops must be interpreted as a NaN. i.e. performing a single-precision op on a FP register containing a double-precision value. It's going to be nasty to conform to this, because all single-precision FP ops will need to test that the upper 32-bits are all 1s, and if not, return canonical NaN.

[michaeljclark]

I'm closing this issue because bootstrap, bbl and linux kernel build is pretty much all documented on the wiki here: https://github.com/riscv/riscv-qemu/wiki