Is "integratorcp" the same board that rumprun is being built for (https://github.com/rumpkernel/rumprun/tree/master/platform/hw/arch/arm/integrator)?
On Thu, Apr 12, 2018 at 9:56 AM, Ajay Garg <ajaygargn...@gmail.com> wrote: > 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 <ajaygargn...@gmail.com> 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 <ajaygargn...@gmail.com> wrote: >>> Thanks Peter .. my sincere gratitude. >>> You pin-pointed the real issue .. >>> >>> >>> >>> On Tue, Apr 10, 2018 at 2:50 PM, Peter Maydell <peter.mayd...@linaro.org> >>> wrote: >>>> On 10 April 2018 at 09:16, Ajay Garg <ajaygargn...@gmail.com> wrote: >>>>> On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.mayd...@linaro.org> >>>>> 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 > > > > -- > Regards, > Ajay -- Regards, Ajay