Hi Peter.

Thanks for the reply.

On Tue, Apr 10, 2018 at 1:08 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 10 April 2018 at 05:14, Ajay Garg <ajaygargn...@gmail.com> 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

Reply via email to