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 <chi...@adacore.com> wrote: > On Fri, Mar 1, 2024 at 6:48 PM Faiq Ali Sayed <faiqueali....@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 <chi...@adacore.com> > wrote: > >> > >> Hi Faiq, > >> > >> On Fri, Feb 23, 2024 at 3:55 PM Faiq Ali Sayed <faiqueali....@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
