Re: QNX VM hang on Qemu

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Maydell <peter.maydell@linaro.org> writes:

(adding the other ZyncMP maintainers to the CC)

> On Wed, 21 Feb 2024 at 18:20, Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>>
>>
>>>
>>> This is also useful information. I would suggest you look
>>> at what the difference is between the image that boots and
>>> the one that doesn't: is it the same format (and what format
>>> is that)? is the way it is loaded on the real hardware the
>>> same, or different?
>>
>>
>> I am not able to distinguish between the images as they are in binary form,
>> I noticed that the smaller size image can boot in Qemu.
>> I normally put the image into an SD card of the real hardware to boot.
>> so it is quite difficult for me now to distinguish.
>>
>>
>>> From the debug info from gdb you provided, the file clearly
>>> is not a raw binary file -- the initial bytes seem to be
>>> largely ASCII text. So it might be that this image is in
>>> a file format that whatever the real-hardware loader
>>> recognizes, but QEMU doesn't, whereas the images you have
>>> that work are really raw binaries. In that case you'd want
>>> to convert the image somehow to a format QEMU can understand
>>> (eg ELF, or raw-binary).
>>
>>
>> ahh, that also makes sense, ok now let me try to convert the images, and let's see.
>> Does Qemu provide such a tool or do you know any?
>
> We don't know what format these images are in, so hard
> to say, but I would expect not (mostly QEMU's image
> conversion handling is for filesystems, not guest
> binaries). You'll probably do best to look on the QNX
> and/or Xilinx side -- Xilinx should document what
> file formats it is that their boot process accepts.
> Your third-party vendor presumably also knows what
> format it is that they're generating the image in.

I did have a brief look through the Xilinx wiki pages to see if I could
cobble together a test case for their PetaLinux images. A bunch of pages
led to login walls which I assume are customer only. I did find:

  https://github.com/Xilinx/soc-prebuilt-firmware/tree/xlnx_rel_v2023.1/zcu102-zynqmp

which has a number of the components for the firmware but there was no
clear way to combine them into a single image. I did try just feeding
the ELF's to the command line but there was a clash between zynqmp_fsbl
and the bl31 (which I think is the normal ATF image).

  ./qemu-system-aarch64 -M xlnx-zcu102 -audio none -smp 4 -serial mon:stdio -display none -s -S -device loader,file=/home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/zynqmp_fsbl.elf -device loader,file=/home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/bl31.elf,cpu-num=0 -device loader,file=/home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/system.dtb,addr=0x00100000 -device loader,file=/home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/u-boot.elf  -dtb /home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/system.dtb
  qemu-system-aarch64: Some ROM regions are overlapping
  These ROM regions might have been loaded by direct user request or by default.
  They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
  Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.

  The following two regions overlap (in the cpu-memory-0 address space):
    /home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/zynqmp_fsbl.elf ELF program header segment 0 (addresses 0x00000000fffc0000 - 0x00000000fffe6058)
    /home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/bl31.elf ELF program header segment 0 (addresses 0x00000000fffe0000 - 0x00000000ffffe000)

  The following two regions overlap (in the cpu-memory-0 address space):
    /home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/bl31.elf ELF program header segment 0 (addresses 0x00000000fffe0000 - 0x00000000ffffe000)
    /home/alex/lsrc/tests/testcases/zcu102-zyncmp-prebuilds/zynqmp_fsbl.elf ELF program header segment 1 (addresses 0x00000000fffe9e00 - 0x00000000fffe9e88)

Most of the use cases on the Xilinx pages are hidden behind their launch
scripts for their downstream fork. It would be nice if we could get at
least one image published somewhere that we could add an avocado test
for and hopefully an entry in the Arm system emulator pages (we have
fairly complete docs for xlnx-versal-virt).

>
> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro