QNX VM hang on Qemu

QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

Hi everyone,
I am facing an issue during booting QNX VM using Qemu,
I have an image to Boot the VM. and when I trigger a Qemu command to create
a VM it is stuck.
I also used a debugger to investigate but I can not see any result by GDB.

Here is the output of first windows

qemu-system-aarch64 -M xlnx-zcu102 -m 16G -serial mon:stdio -display none
-device loader,file=QNX-IFS,addr=0x00100000,cpu-num=0 -drive
file=/home/faiq/Downloads/install/BootSD/qemu-boot_sd.img,if=sd,format=raw,index=1
-boot mode=5 -net nic,model=cadence_gem -net nic,model=cadence_gem -net
nic,model=cadence_gem -net nic,model=cadence_gem,netdev=xzynq0 -netdev
user,id=xzynq0,tftp=/tftpboot  -nographic -global
xlnx,zynqmp-boot.cpu-num=0 -global 'xlnx,zynqmp-boot.use-pmufw=true' -s -S

qemu-system-aarch64: warning: hub 0 is not connected to host network

on the other hand, here is the output of GDB:

(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000100000 in ?? ()
(gdb) c
Continuing.

-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 2165 bytes --]

Re: QNX VM hang on Qemu

[Alex Bennée]

Faiq Ali Sayed <faiqueali.109@gmail.com> writes:

> Hi everyone, 
> I am facing an issue during booting QNX VM using Qemu,
> I have an image to Boot the VM. and when I trigger a Qemu command to create a VM it is stuck.
> I also used a debugger to investigate but I can not see any result by GDB.
>
> Here is the output of first windows
>
> qemu-system-aarch64 -M xlnx-zcu102 -m 16G -serial mon:stdio -display none -device
> loader,file=QNX-IFS,addr=0x00100000,cpu-num=0 -drive
> file=/home/faiq/Downloads/install/BootSD/qemu-boot_sd.img,if=sd,format=raw,index=1 -boot mode=5 -net
> nic,model=cadence_gem -net nic,model=cadence_gem -net nic,model=cadence_gem -net
> nic,model=cadence_gem,netdev=xzynq0 -netdev user,id=xzynq0,tftp=/tftpboot  -nographic -global
> xlnx,zynqmp-boot.cpu-num=0 -global 'xlnx,zynqmp-boot.use-pmufw=true' -s -S
>
> qemu-system-aarch64: warning: hub 0 is not connected to host network

Is this QNX VM image built for the xlnx-zcu102 board?

> on the other hand, here is the output of GDB:
>
> (gdb) target remote :1234
> Remote debugging using :1234
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> 0x0000000000100000 in ?? ()
> (gdb) c
> Continuing.

You'll either want the debug symbols for your image or tell GDB what the
target arch is. Check you are somewhere sane by doing:

  x/10i $pc

and step through the instructions and see where it goes. If you hit
Ctrl-C are you executing nonsense instructions or in a tight loop
hanging?


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

Alex thanks for the reply,

I don't know what the debug symbol is, but my target system is QNX aarch64
below are the configuration of GDB,

(gdb) show configuration
This GDB was configured as follows:
   configure --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-nto-qnx7.1.0
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --without-expat
             --with-gdb-datadir=/opt/qnx710/host/linux/x86_64/usr/share/gdb
(relocatable)

 --with-jit-reader-dir=/opt/qnx710/host/linux/x86_64/usr/lib/gdb
(relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
             --without-intel-pt
             --disable-libmcheck
             --without-mpfr
             --with-python=/opt/qnx710/host/linux/x86_64/usr (relocatable)
             --without-guile

 --with-separate-debug-dir=/opt/qnx710/host/linux/x86_64/usr/lib/debug
(relocatable)
             --with-sysroot=/opt/qnx710/target/qnx7/aarch64

while I got the below result, after executing the x/10i $pc

(gdb) x/10i $pc
=> 0x100000: .inst 0x5371242b ; undefined
   0x100004: fcmla v21.8h, v3.8h, v16.h[1], #270
   0x100008: .inst 0x64657472 ; undefined
   0x10000c: ldnp d26, d27, [x9, #-176]
   0x100010: .inst 0x72706974 ; undefined
   0x100014: .inst 0x7365636f ; undefined
   0x100018: .inst 0x733b2b73 ; undefined
   0x10001c: fnmls z23.h, p0/m, z19.h, z18.h
   0x100020: .inst 0x3b2b6b61 ; undefined
   0x100024: .inst 0x72627768 ; undefined

Can you please let me know how I can step in ?
When I press c it does not execute further and hangs..


Faiq

On Tue, Feb 20, 2024 at 3:41 PM Alex Bennée <alex.bennee@linaro.org> wrote:

> Faiq Ali Sayed <faiqueali.109@gmail.com> writes:
>
> > Hi everyone,
> > I am facing an issue during booting QNX VM using Qemu,
> > I have an image to Boot the VM. and when I trigger a Qemu command to
> create a VM it is stuck.
> > I also used a debugger to investigate but I can not see any result by
> GDB.
> >
> > Here is the output of first windows
> >
> > qemu-system-aarch64 -M xlnx-zcu102 -m 16G -serial mon:stdio -display
> none -device
> > loader,file=QNX-IFS,addr=0x00100000,cpu-num=0 -drive
> >
> file=/home/faiq/Downloads/install/BootSD/qemu-boot_sd.img,if=sd,format=raw,index=1
> -boot mode=5 -net
> > nic,model=cadence_gem -net nic,model=cadence_gem -net
> nic,model=cadence_gem -net
> > nic,model=cadence_gem,netdev=xzynq0 -netdev
> user,id=xzynq0,tftp=/tftpboot  -nographic -global
> > xlnx,zynqmp-boot.cpu-num=0 -global 'xlnx,zynqmp-boot.use-pmufw=true' -s
> -S
> >
> > qemu-system-aarch64: warning: hub 0 is not connected to host network
>
> Is this QNX VM image built for the xlnx-zcu102 board?
>
> > on the other hand, here is the output of GDB:
> >
> > (gdb) target remote :1234
> > Remote debugging using :1234
> > warning: No executable has been specified and target does not support
> > determining executable automatically.  Try using the "file" command.
> > 0x0000000000100000 in ?? ()
> > (gdb) c
> > Continuing.
>
> You'll either want the debug symbols for your image or tell GDB what the
> target arch is. Check you are somewhere sane by doing:
>
>   x/10i $pc
>
> and step through the instructions and see where it goes. If you hit
> Ctrl-C are you executing nonsense instructions or in a tight loop
> hanging?
>
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 5235 bytes --]

Re: QNX VM hang on Qemu

[Alex Bennée]

Faiq Ali Sayed <faiqueali.109@gmail.com> writes:

> Alex thanks for the reply,
>
> I don't know what the debug symbol is, but my target system is QNX aarch64 
> below are the configuration of GDB,
>
> (gdb) show configuration
> This GDB was configured as follows:
>    configure --host=x86_64-pc-linux-gnu --target=aarch64-unknown-nto-qnx7.1.0
>              --with-auto-load-dir=$debugdir:$datadir/auto-load
>              --with-auto-load-safe-path=$debugdir:$datadir/auto-load
>              --without-expat
>              --with-gdb-datadir=/opt/qnx710/host/linux/x86_64/usr/share/gdb (relocatable)
>              --with-jit-reader-dir=/opt/qnx710/host/linux/x86_64/usr/lib/gdb (relocatable)
>              --without-libunwind-ia64
>              --without-lzma
>              --without-babeltrace
>              --without-intel-pt
>              --disable-libmcheck
>              --without-mpfr
>              --with-python=/opt/qnx710/host/linux/x86_64/usr (relocatable)
>              --without-guile
>              --with-separate-debug-dir=/opt/qnx710/host/linux/x86_64/usr/lib/debug (relocatable)
>              --with-sysroot=/opt/qnx710/target/qnx7/aarch64
>
> while I got the below result, after executing the x/10i $pc 
>
> (gdb) x/10i $pc
> => 0x100000: .inst 0x5371242b ; undefined
>    0x100004: fcmla v21.8h, v3.8h, v16.h[1], #270
>    0x100008: .inst 0x64657472 ; undefined
>    0x10000c: ldnp d26, d27, [x9, #-176]
>    0x100010: .inst 0x72706974 ; undefined
>    0x100014: .inst 0x7365636f ; undefined
>    0x100018: .inst 0x733b2b73 ; undefined
>    0x10001c: fnmls z23.h, p0/m, z19.h, z18.h
>    0x100020: .inst 0x3b2b6b61 ; undefined
>    0x100024: .inst 0x72627768 ; undefined
>
> Can you please let me know how I can step in ?

step-instruction in gdb, however...

It very much looks like the image you have built doesn't have any
instructions in the correct starting place. It's unsurprising that it
hangs running random undefined instructions. 

> When I press c it does not execute further and hangs..
>
> Faiq
>
> On Tue, Feb 20, 2024 at 3:41 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  Faiq Ali Sayed <faiqueali.109@gmail.com> writes:
>
>  > Hi everyone, 
>  > I am facing an issue during booting QNX VM using Qemu,
>  > I have an image to Boot the VM. and when I trigger a Qemu command to create a VM it is stuck.
>  > I also used a debugger to investigate but I can not see any result by GDB.
>  >
>  > Here is the output of first windows
>  >
>  > qemu-system-aarch64 -M xlnx-zcu102 -m 16G -serial mon:stdio -display none -device
>  > loader,file=QNX-IFS,addr=0x00100000,cpu-num=0 -drive
>  > file=/home/faiq/Downloads/install/BootSD/qemu-boot_sd.img,if=sd,format=raw,index=1 -boot mode=5 -net
>  > nic,model=cadence_gem -net nic,model=cadence_gem -net nic,model=cadence_gem -net
>  > nic,model=cadence_gem,netdev=xzynq0 -netdev user,id=xzynq0,tftp=/tftpboot  -nographic -global
>  > xlnx,zynqmp-boot.cpu-num=0 -global 'xlnx,zynqmp-boot.use-pmufw=true' -s -S
>  >
>  > qemu-system-aarch64: warning: hub 0 is not connected to host network
>
>  Is this QNX VM image built for the xlnx-zcu102 board?
>
>  > on the other hand, here is the output of GDB:
>  >
>  > (gdb) target remote :1234
>  > Remote debugging using :1234
>  > warning: No executable has been specified and target does not support
>  > determining executable automatically.  Try using the "file" command.
>  > 0x0000000000100000 in ?? ()
>  > (gdb) c
>  > Continuing.
>
>  You'll either want the debug symbols for your image or tell GDB what the
>  target arch is. Check you are somewhere sane by doing:
>
>    x/10i $pc
>
>  and step through the instructions and see where it goes. If you hit
>  Ctrl-C are you executing nonsense instructions or in a tight loop
>  hanging?
>
>  -- 
>  Alex Bennée
>  Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

The image I am using is currently in use for real hardware, and I
received it from a third party/vendor.
Could you please suggest to me what I can do now?


br!
Faiq


On Tue, Feb 20, 2024 at 6:14 PM Alex Bennée <alex.bennee@linaro.org> wrote:

> Faiq Ali Sayed <faiqueali.109@gmail.com> writes:
>
> > Alex thanks for the reply,
> >
> > I don't know what the debug symbol is, but my target system is QNX
> aarch64
> > below are the configuration of GDB,
> >
> > (gdb) show configuration
> > This GDB was configured as follows:
> >    configure --host=x86_64-pc-linux-gnu
> --target=aarch64-unknown-nto-qnx7.1.0
> >              --with-auto-load-dir=$debugdir:$datadir/auto-load
> >              --with-auto-load-safe-path=$debugdir:$datadir/auto-load
> >              --without-expat
> >
> --with-gdb-datadir=/opt/qnx710/host/linux/x86_64/usr/share/gdb (relocatable)
> >
> --with-jit-reader-dir=/opt/qnx710/host/linux/x86_64/usr/lib/gdb
> (relocatable)
> >              --without-libunwind-ia64
> >              --without-lzma
> >              --without-babeltrace
> >              --without-intel-pt
> >              --disable-libmcheck
> >              --without-mpfr
> >              --with-python=/opt/qnx710/host/linux/x86_64/usr
> (relocatable)
> >              --without-guile
> >
> --with-separate-debug-dir=/opt/qnx710/host/linux/x86_64/usr/lib/debug
> (relocatable)
> >              --with-sysroot=/opt/qnx710/target/qnx7/aarch64
> >
> > while I got the below result, after executing the x/10i $pc
> >
> > (gdb) x/10i $pc
> > => 0x100000: .inst 0x5371242b ; undefined
> >    0x100004: fcmla v21.8h, v3.8h, v16.h[1], #270
> >    0x100008: .inst 0x64657472 ; undefined
> >    0x10000c: ldnp d26, d27, [x9, #-176]
> >    0x100010: .inst 0x72706974 ; undefined
> >    0x100014: .inst 0x7365636f ; undefined
> >    0x100018: .inst 0x733b2b73 ; undefined
> >    0x10001c: fnmls z23.h, p0/m, z19.h, z18.h
> >    0x100020: .inst 0x3b2b6b61 ; undefined
> >    0x100024: .inst 0x72627768 ; undefined
> >
> > Can you please let me know how I can step in ?
>
> step-instruction in gdb, however...
>
> It very much looks like the image you have built doesn't have any
> instructions in the correct starting place. It's unsurprising that it
> hangs running random undefined instructions.
>
> > When I press c it does not execute further and hangs..
> >
> > Faiq
> >
> > On Tue, Feb 20, 2024 at 3:41 PM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> >  Faiq Ali Sayed <faiqueali.109@gmail.com> writes:
> >
> >  > Hi everyone,
> >  > I am facing an issue during booting QNX VM using Qemu,
> >  > I have an image to Boot the VM. and when I trigger a Qemu command to
> create a VM it is stuck.
> >  > I also used a debugger to investigate but I can not see any result by
> GDB.
> >  >
> >  > Here is the output of first windows
> >  >
> >  > qemu-system-aarch64 -M xlnx-zcu102 -m 16G -serial mon:stdio -display
> none -device
> >  > loader,file=QNX-IFS,addr=0x00100000,cpu-num=0 -drive
> >  >
> file=/home/faiq/Downloads/install/BootSD/qemu-boot_sd.img,if=sd,format=raw,index=1
> -boot mode=5 -net
> >  > nic,model=cadence_gem -net nic,model=cadence_gem -net
> nic,model=cadence_gem -net
> >  > nic,model=cadence_gem,netdev=xzynq0 -netdev
> user,id=xzynq0,tftp=/tftpboot  -nographic -global
> >  > xlnx,zynqmp-boot.cpu-num=0 -global 'xlnx,zynqmp-boot.use-pmufw=true'
> -s -S
> >  >
> >  > qemu-system-aarch64: warning: hub 0 is not connected to host network
> >
> >  Is this QNX VM image built for the xlnx-zcu102 board?
> >
> >  > on the other hand, here is the output of GDB:
> >  >
> >  > (gdb) target remote :1234
> >  > Remote debugging using :1234
> >  > warning: No executable has been specified and target does not support
> >  > determining executable automatically.  Try using the "file" command.
> >  > 0x0000000000100000 in ?? ()
> >  > (gdb) c
> >  > Continuing.
> >
> >  You'll either want the debug symbols for your image or tell GDB what the
> >  target arch is. Check you are somewhere sane by doing:
> >
> >    x/10i $pc
> >
> >  and step through the instructions and see where it goes. If you hit
> >  Ctrl-C are you executing nonsense instructions or in a tight loop
> >  hanging?
> >
> >  --
> >  Alex Bennée
> >  Virtualisation Tech Lead @ Linaro
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 6224 bytes --]

Re: QNX VM hang on Qemu

[Peter Maydell]

On Tue, 20 Feb 2024 at 20:56, Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>
> The image I am using is currently in use for real hardware, and
> I received it from a third party/vendor.

OK, so what exactly is the real hardware it's for?

> Could you please suggest to me what I can do now?

If QEMU has a model of the hardware the image is for:
 - use that QEMU machine type (and issues with getting it running
   will be related to making sure you're loading it at the right
   address and starting it the way it wants to be started)
If QEMU does not have a model of the hardware the image is for:
 - ask your vendor for a build that targets some machine QEMU
   does have a model of

Unfortunately in general in the Arm world guest OSes are
not "runs on anything", but only "runs on the hardware
they were built to run on". This remains true under emulation.

thanks
-- PMM

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

The real hardware ( xlnx-zcu102 ) is being used for our software. The
software is in the development phase, and for that, I need to create a VM
for simulation purposes.
Qemu has a machine type (-M xlnx-zcu102) which is supported with the
board/hardware.

I have two more images for the same hardware and I can create a VM using
these two images, but in the VM some basic binaries are missing like mkdir
and virtual disk etc.

Now, the image for which I want to create a VM is currently working on
board and everything is working fine on real hardware.
I am not sure whether I can use this image for Qemu because this is created
particularly for hardware.
and giving a try to create a VM.

Your valuable suggestions in this regard will be appreciated and mean a lot
to me :)


br!
Faiq



On Tue, Feb 20, 2024 at 10:24 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Tue, 20 Feb 2024 at 20:56, Faiq Ali Sayed <faiqueali.109@gmail.com>
> wrote:
> >
> > The image I am using is currently in use for real hardware, and
> > I received it from a third party/vendor.
>
> OK, so what exactly is the real hardware it's for?
>
> > Could you please suggest to me what I can do now?
>
> If QEMU has a model of the hardware the image is for:
>  - use that QEMU machine type (and issues with getting it running
>    will be related to making sure you're loading it at the right
>    address and starting it the way it wants to be started)
> If QEMU does not have a model of the hardware the image is for:
>  - ask your vendor for a build that targets some machine QEMU
>    does have a model of
>
> Unfortunately in general in the Arm world guest OSes are
> not "runs on anything", but only "runs on the hardware
> they were built to run on". This remains true under emulation.
>
> thanks
> -- PMM
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 2937 bytes --]

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 3510 bytes --]

Hi Alex,
I have created a new QNX image, particularly for Qemu, and still, both the
prompts are hanging without any further details.
Please have a look at the results of both terminals below


qemu-system-aarch64.exe -M xlnx-zcu102 -m 16G -serial mon:stdio -display
none -device loader,file="C:ifs.bin",addr=0x00100000,cpu-num=0 -drive
file=qemu-raw-img,format=raw,index=1,if=sd -net nic,model=cadence_gem -net
nic,model=cadence_gem -net nic,model=cadence_gem -net
nic,model=cadence_gem,netdev=xzynq0 -netdev user,id=xzynq0,tftp=/tftpboot
 -nographic -global xlnx,zynqmp-boot.cpu-num=0 -global
'xlnx,zynqmp-boot.use-pmufw=true' -s -S
qemu-system-aarch64.exe: warning: hub 0 is not connected to host network
qemu-system-aarch64.exe: warning: global xlnx,zynqmp-boot.cpu-num has
invalid class name
qemu-system-aarch64.exe: warning: global 'xlnx,zynqmp-boot.use-pmufw has
invalid class name
QEMU: Terminated


GDB
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
C:\Users\sayedf\qnx710\image-with-drivers\output\ifs.bin...(no debugging
symbols found)...done.
(gdb) target remote :1234
Remote debugging using :1234
warning: Can not parse XML target description; XML support was disabled at
compile time
0x0000000080000800 in ?? ()
(gdb) c
Continuing.
[Inferior 1 (process 1) exited normally]

Please have a look :)

On Tue, Feb 20, 2024 at 11:22 PM Faiq Ali Sayed <faiqueali.109@gmail.com>
wrote:

> The real hardware ( xlnx-zcu102 ) is being used for our software. The
> software is in the development phase, and for that, I need to create a VM
> for simulation purposes.
> Qemu has a machine type (-M xlnx-zcu102) which is supported with the
> board/hardware.
>
> I have two more images for the same hardware and I can create a VM using
> these two images, but in the VM some basic binaries are missing like mkdir
> and virtual disk etc.
>
> Now, the image for which I want to create a VM is currently working on
> board and everything is working fine on real hardware.
> I am not sure whether I can use this image for Qemu because this is
> created particularly for hardware.
> and giving a try to create a VM.
>
> Your valuable suggestions in this regard will be appreciated and mean a
> lot to me :)
>
>
> br!
> Faiq
>
>
>
> On Tue, Feb 20, 2024 at 10:24 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
>
>> On Tue, 20 Feb 2024 at 20:56, Faiq Ali Sayed <faiqueali.109@gmail.com>
>> wrote:
>> >
>> > The image I am using is currently in use for real hardware, and
>> > I received it from a third party/vendor.
>>
>> OK, so what exactly is the real hardware it's for?
>>
>> > Could you please suggest to me what I can do now?
>>
>> If QEMU has a model of the hardware the image is for:
>>  - use that QEMU machine type (and issues with getting it running
>>    will be related to making sure you're loading it at the right
>>    address and starting it the way it wants to be started)
>> If QEMU does not have a model of the hardware the image is for:
>>  - ask your vendor for a build that targets some machine QEMU
>>    does have a model of
>>
>> Unfortunately in general in the Arm world guest OSes are
>> not "runs on anything", but only "runs on the hardware
>> they were built to run on". This remains true under emulation.
>>
>> thanks
>> -- PMM
>>
>
>
> --
> Kind Regard-
> Faiq Ali Sayed
>
>
>

-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 5518 bytes --]

Re: QNX VM hang on Qemu

[Peter Maydell]

On Tue, 20 Feb 2024 at 22:22, Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>
> The real hardware ( xlnx-zcu102 ) is being used for our software. The software is in the development phase, and for that, I need to create a VM for simulation purposes.
> Qemu has a machine type (-M xlnx-zcu102) which is supported with the board/hardware.

Cool. So in principle this should work and there's likely some
fixable issue with how you're loading the image.

> I have two more images for the same hardware and I can create a VM using these two images, but in the VM some basic binaries are missing like mkdir and virtual disk etc.

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?

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).

thanks
-- PMM

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

> 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?



br!
Faiq


On Wed, Feb 21, 2024 at 5:02 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Tue, 20 Feb 2024 at 22:22, Faiq Ali Sayed <faiqueali.109@gmail.com>
> wrote:
> >
> > The real hardware ( xlnx-zcu102 ) is being used for our software. The
> software is in the development phase, and for that, I need to create a VM
> for simulation purposes.
> > Qemu has a machine type (-M xlnx-zcu102) which is supported with the
> board/hardware.
>
> Cool. So in principle this should work and there's likely some
> fixable issue with how you're loading the image.
>
> > I have two more images for the same hardware and I can create a VM using
> these two images, but in the VM some basic binaries are missing like mkdir
> and virtual disk etc.
>
> 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?
>
> 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).
>
> thanks
> -- PMM
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 4377 bytes --]

Re: QNX VM hang on Qemu

[Peter Maydell]

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.

-- PMM

Re: QNX VM hang on Qemu

[Alex Bennée]

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

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 5759 bytes --]

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.bennee@linaro.org> wrote:

> 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
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 7306 bytes --]

Re: QNX VM hang on Qemu

[Clément Chigot]

Hi Faiq,

On Fri, Feb 23, 2024 at 3:55 PM Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>
> 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.

Where is this 0x00100000 address coming from ? Could you confirm with
"readelf -h" that this is the entry point of your image ?

Alternatively and that's what we used locally, qemu is able to guess
the entry point of an image, when passed from -kernel. Therefore, our
command simply looks like:
  |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
-kernel qnx.img

I'm not the one having built the qnx.img we're using. But it looks
pretty standard at the first look, made with "mkifs" and the kernel
specs from zcu102 evaluation kit.

Hope it helps,
Clément

> 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 :)
>

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

Hi Clément,

So the output of the command
|  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
-kernel qnx.img
is

$ pulseaudio: set_sink_input_volume() failed
$ pulseaudio: Reason: Invalid argument
$ pulseaudio: set_sink_input_mute() failed
$ pulseaudio: Reason: Invalid argument

I am not using the "mkifs" rather I am using the command below..

$ mkqnximage --type=qemu --arch=aarch64le --build  --ssh-ident=none

if I use the --run option with the command it creates a VM which is working
fine.
but when I use this image, with qemu command terminal is getting stuck.


BR!
Faiq



On Fri, Mar 1, 2024 at 4:29 PM Clément Chigot <chigot@adacore.com> wrote:

> Hi Faiq,
>
> On Fri, Feb 23, 2024 at 3:55 PM Faiq Ali Sayed <faiqueali.109@gmail.com>
> wrote:
> >
> > 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.
>
> Where is this 0x00100000 address coming from ? Could you confirm with
> "readelf -h" that this is the entry point of your image ?
>
> Alternatively and that's what we used locally, qemu is able to guess
> the entry point of an image, when passed from -kernel. Therefore, our
> command simply looks like:
>   |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
> -kernel qnx.img
>
> I'm not the one having built the qnx.img we're using. But it looks
> pretty standard at the first look, made with "mkifs" and the kernel
> specs from zcu102 evaluation kit.
>
> Hope it helps,
> Clément
>
> > 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 :)
> >
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 3687 bytes --]

Re: QNX VM hang on Qemu

[Clément Chigot]

On Fri, Mar 1, 2024 at 6:48 PM Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>
> Hi Clément,
>
> So the output of the command
> |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
> -kernel qnx.img
> is
>
> $ pulseaudio: set_sink_input_volume() failed
> $ pulseaudio: Reason: Invalid argument
> $ pulseaudio: set_sink_input_mute() failed
> $ pulseaudio: Reason: Invalid argument
>
> I am not using the "mkifs" rather I am using the command below..

I guess we disabled some options when we built our kernels to allow a
simple command line. However, I don't know which ones.

> $ mkqnximage --type=qemu --arch=aarch64le --build  --ssh-ident=none
>
> if I use the --run option with the command it creates a VM which is working fine.
> but when I use this image, with qemu command terminal is getting stuck.

I wasn't aware that such a command exists. However, the --run option
seems to call the script "runimage". You might want to take a look at
the options being set or maybe simply retrieve the qemu command line
created by it (if that's not how you created your first command line).

Sorry to not be more helpful.

Clément

> BR!
> Faiq
>
>
>
> On Fri, Mar 1, 2024 at 4:29 PM Clément Chigot <chigot@adacore.com> wrote:
>>
>> Hi Faiq,
>>
>> On Fri, Feb 23, 2024 at 3:55 PM Faiq Ali Sayed <faiqueali.109@gmail.com> wrote:
>> >
>> > 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.
>>
>> Where is this 0x00100000 address coming from ? Could you confirm with
>> "readelf -h" that this is the entry point of your image ?
>>
>> Alternatively and that's what we used locally, qemu is able to guess
>> the entry point of an image, when passed from -kernel. Therefore, our
>> command simply looks like:
>>   |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
>> -kernel qnx.img
>>
>> I'm not the one having built the qnx.img we're using. But it looks
>> pretty standard at the first look, made with "mkifs" and the kernel
>> specs from zcu102 evaluation kit.
>>
>> Hope it helps,
>> Clément
>>
>> > 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 :)
>> >
>
>
>
> --
> Kind Regard-
> Faiq Ali Sayed
>
>

Re: QNX VM hang on Qemu

[Faiq Ali Sayed]

[-- Attachment #1: Type: text/plain, Size: 3903 bytes --]

Hi,

>I wasn't aware that such a command exists. However, the --run option
>seems to call the script "runimage". You might want to take a look at
>the options being set or maybe simply retrieve the qemu command line
>created by it (if that's not how you created your first command line).

>Sorry to not be more helpful.

This is actually the main concern, how can I get the internal command of
QNX, how do I know how QNX calls Qemu.
let me investigate it more and yes thanks for your time and support.
Thanks :)

BR!
Faiq

On Mon, Mar 4, 2024 at 10:37 AM Clément Chigot <chigot@adacore.com> wrote:

> On Fri, Mar 1, 2024 at 6:48 PM Faiq Ali Sayed <faiqueali.109@gmail.com>
> wrote:
> >
> > Hi Clément,
> >
> > So the output of the command
> > |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
> > -kernel qnx.img
> > is
> >
> > $ pulseaudio: set_sink_input_volume() failed
> > $ pulseaudio: Reason: Invalid argument
> > $ pulseaudio: set_sink_input_mute() failed
> > $ pulseaudio: Reason: Invalid argument
> >
> > I am not using the "mkifs" rather I am using the command below..
>
> I guess we disabled some options when we built our kernels to allow a
> simple command line. However, I don't know which ones.
>
> > $ mkqnximage --type=qemu --arch=aarch64le --build  --ssh-ident=none
> >
> > if I use the --run option with the command it creates a VM which is
> working fine.
> > but when I use this image, with qemu command terminal is getting stuck.
>
> I wasn't aware that such a command exists. However, the --run option
> seems to call the script "runimage". You might want to take a look at
> the options being set or maybe simply retrieve the qemu command line
> created by it (if that's not how you created your first command line).
>
> Sorry to not be more helpful.
>
> Clément
>
> > BR!
> > Faiq
> >
> >
> >
> > On Fri, Mar 1, 2024 at 4:29 PM Clément Chigot <chigot@adacore.com>
> wrote:
> >>
> >> Hi Faiq,
> >>
> >> On Fri, Feb 23, 2024 at 3:55 PM Faiq Ali Sayed <faiqueali.109@gmail.com>
> wrote:
> >> >
> >> > 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.
> >>
> >> Where is this 0x00100000 address coming from ? Could you confirm with
> >> "readelf -h" that this is the entry point of your image ?
> >>
> >> Alternatively and that's what we used locally, qemu is able to guess
> >> the entry point of an image, when passed from -kernel. Therefore, our
> >> command simply looks like:
> >>   |  $ qemu-system-aarch64 -M xlnx-zcu102 -m 4G -no-reboot -nographic
> >> -kernel qnx.img
> >>
> >> I'm not the one having built the qnx.img we're using. But it looks
> >> pretty standard at the first look, made with "mkifs" and the kernel
> >> specs from zcu102 evaluation kit.
> >>
> >> Hope it helps,
> >> Clément
> >>
> >> > 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 :)
> >> >
> >
> >
> >
> > --
> > Kind Regard-
> > Faiq Ali Sayed
> >
> >
>


-- 
Kind Regard-
Faiq Ali Sayed

[-- Attachment #2: Type: text/html, Size: 5692 bytes --]