qemu-riscv
[Top][All Lists]
Advanced

[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


From: Bin Meng
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: Fri, 10 Jul 2020 08:48:42 +0800

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?

> >
> > 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:

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]