On Mon, Sep 14, 2015 at 10:07 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 13 September 2015 at 23:42, Peter Crosthwaite > <crosthwaitepe...@gmail.com> wrote: >> On Sun, Sep 13, 2015 at 1:47 PM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> On 13 September 2015 at 21:22, Peter Crosthwaite >>> <crosthwaitepe...@gmail.com> 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
