[meta-xilinx] [PATCH v3 12/12] zcu102-zynqmp: Setup runqemu to boot from an SD image

[Alistair Francis]

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

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