From: Alistair Francis <alistair23@gmail.com>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: Palmer Dabbelt <palmerdabbelt@google.com>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
Sagar Karandikar <sagark@eecs.berkeley.edu>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Bin Meng <bin.meng@windriver.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Alistair Francis <Alistair.Francis@wdc.com>
Subject: Re: [PATCH v2 2/2] hw/riscv: sifive_u: Provide a reliable way for bootloader to detect whether it is running in QEMU
Date: Mon, 13 Jul 2020 17:42:58 -0700 [thread overview]
Message-ID: <CAKmqyKMos-ujKL8X3AZY0_UX0ht6UUJuDEs1yu6NCi=-75LabA@mail.gmail.com> (raw)
In-Reply-To: <CAEUhbmXUa-bSMXcHZyV=FybP9gxYsHFhbUPm15tw70+hNQfNEA@mail.gmail.com>
On Sun, Jul 12, 2020 at 6:16 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Sun, Jul 12, 2020 at 12:04 AM Alistair Francis <alistair23@gmail.com> wrote:
> >
> > On Thu, Jul 9, 2020 at 5:50 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Palmer,
> > >
> > > On Fri, Jul 10, 2020 at 8:45 AM Palmer Dabbelt <palmerdabbelt@google.com> wrote:
> > > >
> > > > On Thu, 09 Jul 2020 15:09:18 PDT (-0700), alistair23@gmail.com wrote:
> > > > > On Thu, Jul 9, 2020 at 3:07 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >>
> > > > >> From: Bin Meng <bin.meng@windriver.com>
> > > > >>
> > > > >> The reset vector codes are subject to change, e.g.: with recent
> > > > >> fw_dynamic type image support, it breaks oreboot again.
> > > > >
> > > > > This is a recurring problem, I have another patch for Oreboot to fix
> > > > > the latest breakage.
> > > > >
> > > > >>
> > > > >> Add a subregion in the MROM, with the size of machine RAM stored,
> > > > >> so that we can provide a reliable way for bootloader to detect
> > > > >> whether it is running in QEMU.
> > > > >
> > > > > I don't really like this though. I would prefer that we don't
> > > > > encourage guest software to behave differently on QEMU. I don't think
> > > > > other upstream boards do this.
> > > >
> > > > I agree. If you want an explicitly virtual board, use the virt board. Users
> > > > of sifive_u are presumably trying to do their best to test against what the
> > > > hardware does without actually using the hardware. Otherwise there should be
> > > > no reason to use the sifive_u board, as it's just sticking a layer of
> > > > complexity in the middle of everything.
> > >
> > > Understood. Then let's drop this patch.
> > >
> > > >
> > > > > Besides Oreboot setting up the clocks are there any other users of this?
> > > >
> > > > IIRC we have a scheme for handling the clock setup in QEMU where we accept
> > > > pretty much any control write and then just return reads that say the PLLs have
> > > > locked. I'd be in favor of improving the scheme to improve compatibility with
> > > > the actual hardware, but adding some way for programs to skip the clocks
> > > > because they know they're in QEMU seems like the wrong way to go.
> > > >
> > >
> > > Yep, that's my question to Oreboot too.
> > >
> > > U-Boot SPL can boot with QEMU and no problem was seen with clock
> > > settings in PRCI model in QEMU.
> >
> > I don't think it's an unsolvable problem. There is just little work on
> > Oreboot to run on QEMU. I can dig into it a bit and see if I can find
> > a better fix on the Oreboot side.
> >
>
> Can we remove the QEMU detect logic completely in Oreboot? Except the
> QSPI controller QEMU should be able to run Oreboot since it runs
> U-Boot SPL.
That is the eventual goal.
Alistair
>
> Regards,
> Bin
next prev parent reply other threads:[~2020-07-14 0:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 10:05 [PATCH v2 1/2] hw/riscv: Modify MROM size to end at 0x10000 Bin Meng
2020-07-09 10:05 ` [PATCH v2 2/2] hw/riscv: sifive_u: Provide a reliable way for bootloader to detect whether it is running in QEMU Bin Meng
2020-07-09 22:09 ` Alistair Francis
2020-07-10 0:45 ` Palmer Dabbelt
2020-07-10 0:50 ` Bin Meng
2020-07-11 15:54 ` Alistair Francis
2020-07-13 1:16 ` Bin Meng
2020-07-14 0:42 ` Alistair Francis [this message]
2020-07-10 0:48 ` Bin Meng
2020-07-11 15:53 ` Alistair Francis
2020-07-13 1:14 ` Bin Meng
2020-07-09 17:19 ` [PATCH v2 1/2] hw/riscv: Modify MROM size to end at 0x10000 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='CAKmqyKMos-ujKL8X3AZY0_UX0ht6UUJuDEs1yu6NCi=-75LabA@mail.gmail.com' \
--to=alistair23@gmail.com \
--cc=Alistair.Francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=bmeng.cn@gmail.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=palmerdabbelt@google.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sagark@eecs.berkeley.edu \
/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).