Re: [Qemu-devel] [PATCH v2] hw/misc/zynq_slcr: Change CPU clock rate for Linux boots

[Nathan Rossi]

On Mon, Sep 14, 2015 at 10:07 PM, Peter Maydell
<address@hidden> wrote:
> On 13 September 2015 at 23:42, Peter Crosthwaite
> <address@hidden> wrote:
>> On Sun, Sep 13, 2015 at 1:47 PM, Peter Maydell <address@hidden> wrote:
>>> On 13 September 2015 at 21:22, Peter Crosthwaite
>>> <address@hidden> wrote:
>>>> There may be more changes worth making on is_linux. I don't have the
>>>> patch with the full list of FSBL-related SLCR changes handy and can't
>>>> seem to find it in any modern Yocto trees. Wondering if Yocto still
>>>> supports booting Zynq without FSBL (Nathan/Alistair may know more)?

I have been running QEMU without any patches for zynq in Yocto for
some time now. I have not experienced the bug mentioned, at least not
with the kernels I have been testing with. Is this something that is
more apparent in a 4.2 or newer kernel?

The only thing that was causing problems was the Ethernet kernel
driver demanding a valid 125mhz clock, that was solved by putting a
fixed clock in the device tree
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/conf/machine/boards/qemu/qemuzynq-base.dtsi#n12).

>>>
>>> I'd prefer us not to propagate lots of "only if Linux boot"
>>> changes into devices. The GIC *must* have these because the
>>> kernel can't configure it otherwise from non-secure mode.
>>> I'm not sure that applies here.
>>>
>>
>> At least this change is a must. I have had this discussion with kernel
>> people before and they insist that initing the PLLs and clocks to
>> desired values is the job of the bootloader and the kernel reads back
>> the values from this core. It is same philosophy at the GIC init,
>> which is at the end of the day, done by some pre-boot software. The
>> same bootloader (FSBL) makes other changes that kernels past present
>> and future may rely on and it would be good to have those.
>
> The thing is that if we go down this path we end up incorporating
> most of a boot firmware into QEMU, scattered across different
> devices (and what do we do if we find that two boards want a
> single device set up differently?). The current in-QEMU ARM
> bootloader basically assumes a traditional 32-bit ARM setup,
> where the kernel didn't really trust the firmware or bootloader
> and did a lot of hardware setup itself. This model is starting
> to break down as modern kernels assume more that the firmware
> has done certain setup, but it's what QEMU's design here is based
> on.
>
> The other approach would be to actually run some firmware
> blob at startup, and let that do the setup.

For reference newer u-boot versions (mainline, not Xilinx) have
definitions for some Zynq boards and with the complete ps7_init.c
register configuration setup. So building a u-boot-spl firmware to do
this seems like an alternate solution. Although I am not exactly sure
how booting this setup would work, and I assume a custom ps7_init.c
might need to be created for QEMU.

Regards,
Nathan