On 22 November 2017 at 09:01, Manjukumar Harthikote Matha
<manjukumar.harthikote-ma...@xilinx.com> wrote:
>
>
> On 11/21/2017 02:43 PM, Alistair Francis wrote:
>>
>> On Tue, Nov 14, 2017 at 5:15 AM, Nathan Rossi <nat...@nathanrossi.com>
>> 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 <nat...@nathanrossi.com>
>>> ---
>>> 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)

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.

Regards,
Nathan
-- 
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Reply via email to