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

[Bin Meng]

Hi Alistair,

On Sun, Jul 12, 2020 at 12:03 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> 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.
>

Note there are two reasons that why "-m 8G" is used to test U-Boot SPL:

1. U-Boot DDR driver is hardcoding memory to 8G, which I had a fix
locally and will send U-Boot upstream soon.
2. U-Boot SPL has to use its own device tree because we don't want to
update QEMU to include all the DDR register settings in the device
tree which is very big.

Why I wanted to add this patch here is that I wanted to dynamically
patch U-Boot SPL DT to use the actual ram size that QEMU instantiates.
This way we can avoid editing U-Boot SPL DT to set the actual memory
size.

Regards,
Bin