On Wed, Nov 22, 2017 at 4:05 AM, Nathan Rossi <[email protected]> wrote: > On 22 November 2017 at 09:01, Manjukumar Harthikote Matha > <[email protected]> wrote: >> >> >> On 11/21/2017 02:43 PM, Alistair Francis wrote: >>> >>> On Tue, Nov 14, 2017 at 5:15 AM, Nathan Rossi <[email protected]> >>> wrote: >>>> >>>> This sets up the zcu102-zynqmp machine to by default generate a padded >>>> SD card image for which runqemu can use to boot from. This image >>>> includes all the components that are expected from to boot and mirrors >>>> the same requirements that the real board has. >>>> >>>> The QEMU args are changed to default to the SD boot mode and only U-Boot >>>> SPL is passed in as a ROM image to boot the QEMU instance. >>>> >>>> This setup mimics the boot flow of the physical target where the Boot >>>> ROM loads U-Boot SPL and the PMU Firmware from the boot.bin. >>>> >>>> Signed-off-by: Nathan Rossi <[email protected]> >>>> --- >>>> Changes in v3: >>>> * NEW >>>> --- >>>> conf/machine/zcu102-zynqmp.conf | 27 ++++++++++++++++----------- >>>> 1 file changed, 16 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/conf/machine/zcu102-zynqmp.conf >>>> b/conf/machine/zcu102-zynqmp.conf >>>> index 41e9e11952..80b6d6f37f 100644 >>>> --- a/conf/machine/zcu102-zynqmp.conf >>>> +++ b/conf/machine/zcu102-zynqmp.conf >>>> @@ -13,6 +13,11 @@ MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost" >>>> UBOOT_MACHINE = "xilinx_zynqmp_zcu102_rev1_0_defconfig" >>>> SPL_BINARY = "spl/boot.bin" >>>> >>>> +# Default SD image build onfiguration, use qemu-sd to pad >>>> +IMAGE_CLASSES += "image-types-xilinx-qemu" >>>> +IMAGE_FSTYPES += "wic.qemu-sd" >>>> +WKS_FILES ?= "sdimage-bootpart.wks" >>>> + >>>> SERIAL_CONSOLE = "115200 ttyPS0" >>>> SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}" >>>> >>>> @@ -23,11 +28,14 @@ PREFERRED_PROVIDER_virtual/bootloader ?= >>>> "u-boot-xlnx" >>>> PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware" >>>> >>>> EXTRA_IMAGEDEPENDS += " \ >>>> + u-boot-zynq-uenv \ >>>> arm-trusted-firmware \ >>>> qemu-devicetrees \ >>>> virtual/pmu-firmware \ >>>> " >>>> >>>> +IMAGE_BOOT_FILES += "uEnv.txt atf-uboot.ub >>>> ${KERNEL_IMAGETYPE}-zynqmp-zcu102-rev1.0.dtb" >>>> + >>>> # This machine has a QEMU model, runqemu setup: >>>> IMAGE_CLASSES += "qemuboot-xilinx" >>>> QB_MACHINE = "-machine xlnx-zcu102" >>>> @@ -41,23 +49,19 @@ PREFERRED_PROVIDER_qemu-helper-native = >>>> "qemu-xilinx-helper-native" >>>> # Use the multiarch script instead of launching QEMU directly >>>> QB_SYSTEM_NAME_append = "-multiarch" >>>> >>>> -# Setup hw-dtb, unhalt, atf and u-boot loading >>>> +# Replicate BootROM like behaviour, having loaded SPL and PMU(ROM+FW) >>>> QB_OPT_APPEND_append_qemuboot-xilinx = " \ >>>> -hw-dtb >>>> ${DEPLOY_DIR_IMAGE}/qemu-hw-devicetrees/multiarch/zcu102-arm.dtb \ >>>> ${@qemu_zynqmp_unhalt(d, True)} \ >>>> - -device >>>> loader,file=${DEPLOY_DIR_IMAGE}/arm-trusted-firmware.elf,cpu-num=0 \ >>>> - -device loader,file=${DEPLOY_DIR_IMAGE}/u-boot.elf \ >>>> + -device >>>> loader,addr=0xfffc0000,file=${DEPLOY_DIR_IMAGE}/u-boot-spl.bin,cpu-num=0 \ >>> >>> >>> I only just got around to looking at this. >>> >>> What is the reason to use u-boot SPL instead of ATF and u-boot? We >>> don't need FSBL/SPL on QEMU so this shouldn't be required and we don't >>> test u-boot-spl internally so we won't catch breakages here. >>> >> >> It would be good to support both : ATF/u-boot like before and current >> u-boot-spl.bin. We can use some sort of switch based on SPL_BINARY >> > > Booting ATF+U-Boot & PMU directly is fine too, as would be FSBL & PMU? > (if desired)
With a patch to ATF we can run ATF and u-boot instead of u-boot-spl. I have sent patches internally, so hopefully in the future we can use that. > > Maybe this is an additional case (on top of mainline conf) for > generating multiple qemuboot.conf variants? And adding support to > runqemu to be able to load them. Yeah, I like that. I would like more flexibility in runqemu, just need to figure out how to :) Alistair > > Regards, > Nathan -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
