Message ID | 20221229091828.1945072-1-bmeng@tinylab.org |
---|---|
Headers | show |
Series | hw/riscv: Improve Spike HTIF emulation fidelity | expand |
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(-) >
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
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