From: Sunil V L <sunilvl@ventanamicro.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: qemu-riscv@nongnu.org, qemu-devel@nongnu.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
Weiwei Li <liweiwei@iscas.ac.cn>,
Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH v3] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none"
Date: Thu, 25 May 2023 20:32:46 +0530 [thread overview]
Message-ID: <ZG94lvAYggnRBfLQ@sunil-laptop> (raw)
In-Reply-To: <CABJz62NHXrBKkc3Gux0TXOjUCO4up-OunwJ6UO94ts+rTgVsAg@mail.gmail.com>
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 <abologna@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
next prev parent reply other threads:[~2023-05-25 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 10:28 [PATCH v3] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none" Sunil V L
2023-05-24 15:50 ` Andrea Bolognani
2023-05-24 17:33 ` Sunil V L
2023-05-25 13:43 ` Andrea Bolognani
2023-05-25 15:02 ` Sunil V L [this message]
2023-05-25 16:19 ` Andrea Bolognani
2023-05-25 16:54 ` Sunil V L
2023-05-26 3:37 ` Alistair Francis
2023-05-26 6:47 ` Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZG94lvAYggnRBfLQ@sunil-laptop \
--to=sunilvl@ventanamicro.com \
--cc=abologna@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=dbarboza@ventanamicro.com \
--cc=liweiwei@iscas.ac.cn \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=xypron.glpk@gmx.de \
--cc=zhiwei_liu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).