Re: [PATCH v2 2/2] hw/riscv: sifive_u: Provide a reliable way for bootloader to detect whether it is running in QEMU

[Alistair Francis]

On Thu, Jul 9, 2020 at 5:48 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Alistair,
>
> On Fri, Jul 10, 2020 at 6:19 AM Alistair Francis <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.
> >
>
> Can Oreboot be updated to remove the QEMU detection?

In general I think it should be.

Right now it's not critical to do. I think from a QEMU perspective we
have finished changing the "ROM" code so after this release we can
update Oreboot and then it should settle down again.

>
> > >
> > > 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.
> >
> > Besides Oreboot setting up the clocks are there any other users of this?
>
> I don't really have any specific reason, except for testing U-Boot SPL
> by relaxing the requirement of hardcoding the memory to 8G "-m 8G" as
> I indicated in the commit message below:

Yeah, I think that's just something we will have to deal with. If the
guest expects 8GB and doesn't check the device tree passed to it then
the user has to create 8GB of memory.

Alistair

>
> commit 3eaea6eb4e534f7b87c6eca808149bb671976800
> Author: Bin Meng <bin.meng@windriver.com>
> Date:   Mon Jun 15 17:50:41 2020 -0700
>
>     hw/riscv: sifive_u: Add a dummy DDR memory controller device
>
>     It is enough to simply map the SiFive FU540 DDR memory controller
>     into the MMIO space using create_unimplemented_device(), to make
>     the upstream U-Boot v2020.07 DDR memory initialization codes happy.
>
>     Note we do not generate device tree fragment for the DDR memory
>     controller. Since the controller data in device tree consumes a
>     very large space (see fu540-hifive-unleashed-a00-ddr.dtsi in the
>     U-Boot source), and it is only needed by U-Boot SPL but not any
>     operating system, we choose not to generate the fragment here.
>     This also means when testing with U-Boot SPL, the device tree has
>     to come from U-Boot SPL itself, but not the one generated by QEMU
>     on the fly. The memory has to be set to 8GiB to match the real
>     HiFive Unleashed board when invoking QEMU (-m 8G).
>
> Cc'ing Pragnesh and Sagar as they wanted to test U-Boot SPL with QEMU
> and talked to me the other day.
>
> Regards,
> Bin