So as far as my understanding, we provide these binaries using Qemu command as depicted in the example you provided and there is no way I found to put them into a single image. Regarding the overlapping space, I don't have much idea but I think we could provide a starting address separately to these images something like addr=0x00100000.
So as per your suggestion, I compared my images and I found that the image does not show a virtual disk, and other commands like mkdir, do not have these binaries. So these binaries are not included at the time of image creation and I don't exactly know that how can we add these binaries into the QNX image. The Image that is currently installed in real hardware does not have a debugging symbol, so I can't use GDB to debug that. Now I am looking for a way to create the correct QNX OS image for Qemu. Any lead in this regard will be really helpful :) BR! Faiq On Thu, Feb 22, 2024 at 11:55 AM Alex Bennée <alex.ben...@linaro.org> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: > > (adding the other ZyncMP maintainers to the CC) > > > On Wed, 21 Feb 2024 at 18:20, Faiq Ali Sayed <faiqueali....@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 > -- Kind Regard- Faiq Ali Sayed
