Hi Andrea, On Thu, May 25, 2023 at 01:43:28PM +0000, Andrea Bolognani wrote: > On Wed, May 24, 2023 at 11:03:52PM +0530, Sunil V L wrote: > > On Wed, May 24, 2023 at 03:50:34PM +0000, Andrea Bolognani wrote: > > > First off, the only RISC-V edk2 build readily accessible to me (from > > > the edk2-riscv64 Fedora package) is configured to work off a R/W > > > pflash1. You said that you have edk2 patches making R/O CODE pflash0 > > > and R/W VARS pflash1 ready. Any chance you could make either the > > > build output, or the patches and some hints on how to build edk2 > > > after applying them, somewhere? > > > > Please build EDK2 using the branch > > https://github.com/vlsunil/edk2/tree/separate_code_vars. > > > > The instructions to build is in > > https://github.com/vlsunil/riscv-uefi-edk2-docs/wiki/RISC-V-Qemu-Virt-support#build-edk2 > > > > However, now it will create two images for code and vars. > > Following your pointers, I was able to build suitable edk2 images and > verify that they work with a patched QEMU, so > > Tested-by: Andrea Bolognani <abolo...@redhat.com> > > Note, however, that said testing was limited to verifying that edk2 > would come up. > > I have also tried booting an openSUSE Tumbleweed "JeOS" image, since > that's the only distro I'm aware of that uses UEFI boot on RISC-V at > this point - though they use U-Boot's UEFI support rather than edk2. > > During that attempt, I ended up in the edk2 shell. Running > > fs0:\efi\boot\bootriscv64.efi > > brings up GRUB just fine, but selecting the default boot entry > results in > > Loading Linux 6.3.2-1-default ... > Loading initial ramdisk ... > EFI stub: Booting Linux Kernel... > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > EFI stub: Generating empty DTB > EFI stub: Exiting boot services... > > being printed, after which it's back to OpenSBI and from there to > edk2 again. > > I feel that this has probably more to do with the way the openSUSE > image has been built than edk2, but I thought I'd report my > experience nonetheless in case there's any useful information that > can be gathered from it :) > Thanks!. Please add -machine acpi=off in qemu command to boot the kernel.
> > > Going further and testing libvirt integration. After hacking around > > > other issues, I finally stumbled upon this error: > > > > > > qemu-system-riscv64: Property 'virt-machine.pflash0' not found > > > > Thanks!. This needs some investigation. Let me look into supporting > > this. > > Yes please! It's critical to libvirt integration. Feel free to CC me > when you post patches and I'll gladly test them. > Sure, I have the fix ready. I need to convert this into a patch series now. Will send it soon and thanks in advance for helping with testing. Thanks, Sunil