Actually just realised that qemu does support integratorcp as one of
the supported-boards.
Unfortunately, when I use
qemu-system-arm -machine integratorcp -nographic -kernel helloer.bin
the shell just hangs :(
Following are the details when run through gdb :
##########################################################################
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from qemu-system-arm...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/qemu-system-arm -machine integratorcp
-nographic -kernel helloer.bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb388f290 (LWP 596)]
Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb388f290 (LWP 596)]
memset () at ../ports/sysdeps/arm/memset.S:50
50 ../ports/sysdeps/arm/memset.S: No such file or directory.
(gdb) bt
#0 memset () at ../ports/sysdeps/arm/memset.S:50
#1 0xb65e1c6c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
##########################################################################
On Wed, Apr 11, 2018 at 12:49 PM, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote:
Hi All.
Just wondering if there is something specific that needs to changed at
https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator
in order to get a hello-world app run on "virt" machine?
If so, I would request the rumprun-guys to kindly throw in some light,
on what needs to be done in order to have something run on a "virt"
machine in qemu-context.
Thanks and Regards,
Ajay
On Tue, Apr 10, 2018 at 3:49 PM, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote:
Thanks Peter .. my sincere gratitude.
You pin-pointed the real issue ..
On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.maydell@xxxxxxxxxx>
wrote:
On 10 April 2018 at 09:16, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote:
On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.maydell@xxxxxxxxxx>
wrote:
What hardware (what CPU, board, etc) is this "rumprun" software
expecting to run on?
Yep, just to ensure that there are no cross-compiling issues, I am
building rumprun on the pseudo-real hardware itself.
In our case, the pseudo-real hardware are :
a)
An ARM32 "virt" hardware/machine in a qemu environment
(https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/)
Once I start this machine, all environment is arm32, and I compile
rumprun within this environemnt without any cross-compiling.
b)
A beaglebone-green-wireless.
This is a arm32 machine bottoms-up, so no question of cross-compiling
whatsoever here :)
In both cases, I then use qemu-system-arm (on the "virt" machine, and
beaglebone-green-wireless itself).
That's telling me what setups you're trying to compile in,
which doesn't correspond necessarily to what the guest
OS is built to run on.
One query : It is apparent that there is nested qemu-virtualization in
step a), could that be an issue?
Why are you running this in a nested setup? I don't understand
the purpose of doing that. It would be simpler and faster to
just run the guest on a QEMU running in your native host system.
Assuming this is the source for the guest you're trying to run:
https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch
that suggests that the only Arm board it supports is "integrator"
(which is an absolutely ancient devboard with very little memory,
no PCI and no virtio support). You need to confirm what Arm hardware
this 'rumpkernel' is actually intended to run on, and then give QEMU
the right command line arguments to emulate that hardware. I can't
really help any further, I'm afraid -- you need somebody who knows
about this guest OS.
thanks
-- PMM
--
Regards,
Ajay
--
Regards,
Ajay
