Message ID | 20210219005235.17387-1-ashe@kivikakk.ee |
---|---|
Headers | show |
Series | Add preliminary support for QFW on Arm | expand |
On 2/19/21 1:52 AM, Asherah Connor wrote: > This patch adds preliminary support for the QEMU firmware interface > (aka. QEMU fw_cfg) on the Arm platform. I'm sending this to see if > there's interest in accepting this support; ultimately, I'd like to get > the QEMU "ramfb" display working, which requires the use of fw_cfg to > configure. > > Please note this is my first attempt at adding functionality to U-Boot > and there are likely to be many mistakes. Among others: > > * I've added this to arch_early_init_r, mimicking the existing support > in arch/x86/cpu/qemu/qemu.c. Let me know if this is incorrect. > > * I am unsure about the Kconfig changes. These make > qemu_arm64_defconfig work out of the box. It can still be disabled > and build correctly. I've implied only "QFW" because the command > wouldn't be necessary for e.g. future ramfb support. We may want to > give the option a description in that case---it is currently > considered "hidden" and only selected when "CMD_QFW" is. > > * I would be happy to maintain this going forward. Let me know if I > should submit a patch for MAINTAINTERS. Hello Asherah, thank you for addressing the missing GPU support when running under QEMU ARM. virtio-gpu is an alternative to ramfb. Why are you targeting ramfb and not virtio-gpu? Which impact does it have on the guest OS? Best regards Heinrich > > > Asherah Connor (1): > arm: qemu: support qfw > > arch/arm/Kconfig | 1 + > arch/arm/Makefile | 1 + > arch/arm/mach-qemu/Kconfig | 2 + > arch/arm/mach-qemu/Makefile | 1 + > arch/arm/mach-qemu/qemu.c | 109 ++++++++++++++++++++++++++++++++++++ > 5 files changed, 114 insertions(+) > create mode 100644 arch/arm/mach-qemu/Makefile > create mode 100644 arch/arm/mach-qemu/qemu.c >
Hello Heinrich, On 21/02/19 06:02:p, Heinrich Schuchardt wrote: > virtio-gpu is an alternative to ramfb. Why are you targeting ramfb and > not virtio-gpu? Which impact does it have on the guest OS? It happens to be what I'm already using, and the interface appears quite simple. I am hacking on an Arm OS, and using U-Boot's UEFI support to provide a framebuffer to the booted target. This works very well on hardware (a ROCKPro64 in my case). I've been using EDK2 in QEMU until now, but am experimenting with using U-Boot in QEMU instead to minimise differences between the hardware target and virtualised one. virtio-gpu could work just as well, but in either case there is no U-Boot support. I figure keeping it very simple maximises my chance of success here. Best, Asherah