Hi Peter. Thanks for the reply.
On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <[email protected]> wrote: > On 10 April 2018 at 05:14, Ajay Garg <[email protected]> wrote: >> Thanks Alex for the reply .. >> >>> >>> Can you run under -s -S and gdb step the *guest* and see where it ends >>> up. The above error is usually indicative of the guest going off into >>> the weeds somewhere because the hardware isn't what it expects. >>> >> >> So, after your reply that it might be because of the >> hardware-mismatch, I kinda took a detour, and installed a arm32 "virt" >> machine on qemu on a x86_64 host, as per the steps at >> https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ >> >> All went fine, and then I compiled rumprun on this "virt" guest. > > The host system hardware doesn't matter (except that if you're > running suitable matching host and guest hardware you might be > able to use hardware acceleration with KVM, but for the moment > I would recommend concentrating on getting it working). What > matters is that the guest software you run must match the > hardware that you are asking QEMU to emulate. (I guess if > rumprun automatically configures itself based on the system > you're compiling it on then you're running a different binary, > but surely it has a setup for manually configuring it when you're > cross-compiling it?) > > 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). One query : It is apparent that there is nested qemu-virtualization in step a), could that be an issue? > > (The "Trying to execute code outside RAM or ROM at 0x00100000" > symptoms very frequently mean "guest binary was not built > to run on this emulated hardware".) > > thanks > -- PMM -- Regards, Ajay
