[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] hw/riscv: sifive_u: Provide a reliable way for bootlo
Re: [PATCH v2 2/2] hw/riscv: sifive_u: Provide a reliable way for bootloader to detect whether it is running in QEMU
Fri, 10 Jul 2020 08:50:30 +0800
On Fri, Jul 10, 2020 at 8:45 AM Palmer Dabbelt <email@example.com> wrote:
> On Thu, 09 Jul 2020 15:09:18 PDT (-0700), firstname.lastname@example.org wrote:
> > On Thu, Jul 9, 2020 at 3:07 AM Bin Meng <email@example.com> wrote:
> >> From: Bin Meng <firstname.lastname@example.org>
> >> 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
> 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.
Re: [PATCH v2 1/2] hw/riscv: Modify MROM size to end at 0x10000, Alistair Francis, 2020/07/09