mbox series

[v2,00/12] hw/riscv: Improve Spike HTIF emulation fidelity

Message ID 20221229091828.1945072-1-bmeng@tinylab.org
Headers show
Series hw/riscv: Improve Spike HTIF emulation fidelity | expand

Message

Bin Meng Dec. 29, 2022, 9:18 a.m. UTC
At present the 32-bit OpenSBI generic firmware image does not boot on
Spike, only 64-bit image can. This is due to the HTIF emulation does
not implement the proxy syscall interface which is required for the
32-bit HTIF console output.

An OpenSBI bug fix [1] is also needed when booting the plain binary image.

With this series plus the above OpenSBI fix, both 32-bit OpenSBI BIN & ELF
images can boot on QEMU 'spike' machine.

[1] https://patchwork.ozlabs.org/project/opensbi/patch/20221226033603.1860569-1-bmeng@tinylab.org/

Changes in v2:
- fix 2 typos in the commit message
- initialize firmware_end_addr to memmap[SPIKE_DRAM].base
- rework the htif_custom_base detection logic

Bin Meng (10):
  hw/char: riscv_htif: Avoid using magic numbers
  hw/char: riscv_htif: Drop {to,from}host_size in HTIFState
  hw/char: riscv_htif: Drop useless assignment of memory region
  hw/char: riscv_htif: Use conventional 's' for HTIFState
  hw/char: riscv_htif: Move registers from CPUArchState to HTIFState
  hw/char: riscv_htif: Remove forward declarations for non-existent
    variables
  hw/char: riscv_htif: Support console output via proxy syscall
  hw/riscv: spike: Remove the out-of-date comments
  hw/riscv/boot.c: Introduce riscv_find_firmware()
  hw/riscv: spike: Decouple create_fdt() dependency to ELF loading

Daniel Henrique Barboza (2):
  hw/riscv/boot.c: make riscv_find_firmware() static
  hw/riscv/boot.c: introduce riscv_default_firmware_name()

 include/hw/char/riscv_htif.h |  19 +---
 include/hw/riscv/boot.h      |   4 +-
 target/riscv/cpu.h           |   4 -
 hw/char/riscv_htif.c         | 172 +++++++++++++++++++++--------------
 hw/riscv/boot.c              |  76 ++++++++++------
 hw/riscv/sifive_u.c          |  11 +--
 hw/riscv/spike.c             |  64 +++++++++----
 hw/riscv/virt.c              |  10 +-
 target/riscv/machine.c       |   6 +-
 9 files changed, 217 insertions(+), 149 deletions(-)

Comments

Daniel Henrique Barboza Dec. 29, 2022, 10:24 a.m. UTC | #1
Bin,

Not sure if it's a problem on my side but I can't find patch 12/12. I didn't
received in my mailbox. I tried patchwork but didn't find in there:

https://patchwork.ozlabs.org/project/qemu-devel/list/?series=334352


And it's not in the ML archives as well:

https://mail.gnu.org/archive/html/qemu-devel/2022-12/msg04581.html


Thanks,


Daniel


On 12/29/22 06:18, Bin Meng wrote:
> At present the 32-bit OpenSBI generic firmware image does not boot on
> Spike, only 64-bit image can. This is due to the HTIF emulation does
> not implement the proxy syscall interface which is required for the
> 32-bit HTIF console output.
>
> An OpenSBI bug fix [1] is also needed when booting the plain binary image.
>
> With this series plus the above OpenSBI fix, both 32-bit OpenSBI BIN & ELF
> images can boot on QEMU 'spike' machine.
>
> [1]https://patchwork.ozlabs.org/project/opensbi/patch/20221226033603.1860569-1-bmeng@tinylab.org/
>
> Changes in v2:
> - fix 2 typos in the commit message
> - initialize firmware_end_addr to memmap[SPIKE_DRAM].base
> - rework the htif_custom_base detection logic
>
> Bin Meng (10):
>    hw/char: riscv_htif: Avoid using magic numbers
>    hw/char: riscv_htif: Drop {to,from}host_size in HTIFState
>    hw/char: riscv_htif: Drop useless assignment of memory region
>    hw/char: riscv_htif: Use conventional 's' for HTIFState
>    hw/char: riscv_htif: Move registers from CPUArchState to HTIFState
>    hw/char: riscv_htif: Remove forward declarations for non-existent
>      variables
>    hw/char: riscv_htif: Support console output via proxy syscall
>    hw/riscv: spike: Remove the out-of-date comments
>    hw/riscv/boot.c: Introduce riscv_find_firmware()
>    hw/riscv: spike: Decouple create_fdt() dependency to ELF loading
>
> Daniel Henrique Barboza (2):
>    hw/riscv/boot.c: make riscv_find_firmware() static
>    hw/riscv/boot.c: introduce riscv_default_firmware_name()
>
>   include/hw/char/riscv_htif.h |  19 +---
>   include/hw/riscv/boot.h      |   4 +-
>   target/riscv/cpu.h           |   4 -
>   hw/char/riscv_htif.c         | 172 +++++++++++++++++++++--------------
>   hw/riscv/boot.c              |  76 ++++++++++------
>   hw/riscv/sifive_u.c          |  11 +--
>   hw/riscv/spike.c             |  64 +++++++++----
>   hw/riscv/virt.c              |  10 +-
>   target/riscv/machine.c       |   6 +-
>   9 files changed, 217 insertions(+), 149 deletions(-)
>
Bin Meng Dec. 29, 2022, 10:38 a.m. UTC | #2
Hi Daniel,

On Thu, Dec 29, 2022 at 6:25 PM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
> Bin,
>
> Not sure if it's a problem on my side but I can't find patch 12/12. I didn't
> received in my mailbox. I tried patchwork but didn't find in there:
>
> https://patchwork.ozlabs.org/project/qemu-devel/list/?series=334352
>
>
> And it's not in the ML archives as well:
>
> https://mail.gnu.org/archive/html/qemu-devel/2022-12/msg04581.html
>

Thanks for reporting this!

I just examined the "git send-email" log, and indeed the "git
send-email" aborted at the last patch for some unknown reason.

I just resent the 12th patch using "git send-email" using the correct
Message-Id, and hopefully it will be correctly chained into the v2
patch thread.

Regards,
Bin
Daniel Henrique Barboza Dec. 29, 2022, 10:58 a.m. UTC | #3
On 12/29/22 07:38, Bin Meng wrote:
> Hi Daniel,
>
> On Thu, Dec 29, 2022 at 6:25 PM Daniel Henrique Barboza
> <dbarboza@ventanamicro.com> wrote:
>> Bin,
>>
>> Not sure if it's a problem on my side but I can't find patch 12/12. I didn't
>> received in my mailbox. I tried patchwork but didn't find in there:
>>
>> https://patchwork.ozlabs.org/project/qemu-devel/list/?series=334352
>>
>>
>> And it's not in the ML archives as well:
>>
>> https://mail.gnu.org/archive/html/qemu-devel/2022-12/msg04581.html
>>
> Thanks for reporting this!
>
> I just examined the "git send-email" log, and indeed the "git
> send-email" aborted at the last patch for some unknown reason.
>
> I just resent the 12th patch using "git send-email" using the correct
> Message-Id, and hopefully it will be correctly chained into the v2
> patch thread.

That worked for me!

Good to know that there's a workaround to send missing patches in a
series - historically I would just resend the series all over again when
that happens,


Daniel

>
> Regards,
> Bin