Qemu doesn't run builds from FreedomStudio, hifive1b

Archive General
1

Hi!
I am trying to run qemu on elf files build with the Freedomstudio 2019.3. for the Hifive1b board.
I tried things discussed in this thread. But it couldn’t help me.

When I start qemu like this, it seems to freeze (gives no response and takes lot of cpu).

 $ qemu-system-riscv32 -nographic -machine sifive_e -kernel ~/wsFreedomStudio/hello/src/debug/hello.elf

I verified that qemu works on several riscv-probe examples with the same command as above.

When I try to attach gdb to qemu with -s -S or the -gdb command, I get a Segmentation fault:

$ riscv32-unknown-elf-gdb 

(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Segmentation fault

Adding the -cpu sifive-e31 argument doesn’t make any difference.

I don’t have a lot of experience with qemu/gdb, maybe I’m just doing something simple wrong.

2

If you have a recent enough qemu and gdb then they will talk to each other. You need a gdb with the riscv target description (aka xml) support which was added in November. This has not appeared in an official gdb release yet, but will be in the pending gdb-8.3 release, and is in the 8.3 prerelease versions used in the SiFive toolchain. You also need a qemu with the gdbstub support which just went in a few weeks ago, and will be in the pending qemu-4.0 release. A qemu-4.0 release candidate should work.

The HiFive1 RevB is not completely compatible with the HiFive1. Hence the existing qemu support for the HiFive1 will not work as is for HiFive1 RevB binaries. One notable difference is that the flash address has changed, and is now 0x20010000 instead of 0x20400000. Hence you need a qemu patch to change the entry address. This seems to work for me. At least I see the hello world message echoed to my screen.

diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c
index e0f8ab8c73..af53c97258 100644
--- a/hw/riscv/sifive_e.c
+++ b/hw/riscv/sifive_e.c
@@ -129,7 +129,7 @@ static void riscv_sifive_e_generic_init(MachineState *machine, bool has_clic)
 
     /* Mask ROM reset vector */
     uint32_t reset_vec[2] = {
-        0x204002b7,        /* 0x1000: lui     t0,0x20400 */
+        0x200102b7,        /* 0x1000: lui     t0,0x20010 */
         0x00028067,        /* 0x1004: jr      t0 */
     };

There are a few other minor changes I believe, and none of the new devices are present in the HiFive1 qemu support of course, so you may run into other problems.

Our focus so far has been getting the code running on the hardware, but qemu support would be nice too, and I will raise an internal issue to see if we can get someone assigned to work on that.