Re: aarch64 qemu workaround
On 06/05/2016 09:43 AM, Mike wrote:
> https://gmplib.org/~tege/qemu.html
>
> Scrolling down to the aarch64 section describes the situation.
Is what is describe there for aarch64 actually that bad? Having to
modify /etc/initramfs-tools/modules seems to be not too bad of a
thing to me... You could probably even preseed the installer with
a custom command, see [1] for details.
On the other hand - what do you want to use emulated aarch64 for?
Do you really need to have a full emulated system, to test the
kernel etc.? Or would a chroot be sufficient?
Because what works _really_ well with aarch64 is qemu-user, i.e.
running aarch64 binaries directly on your local system. There's a
nice tool called qemu-debootstrap with which you can automatically
create a chroot with a different architecture. Some are supported
better than others [2], but for aarch64 I've only had good
experiences with it. For example,
qemu-debootstrap --arch=arm64 sid aarch64-chroot
works out of the box. (jessie as well as sid.)
You can the just chroot into that,
chroot aarch64-chroot /bin/bash
and install stuff you like (just like any other regular chroot).
(Probably want to edit /etc/apt/sources.list first and copy
/etc/resolv.conf from your host system though.) The same caveats
that apply for normal chroots also apply here - and as with
regular chroots, I'd recommend using schroot to manage them once
they're set up. (Or use them as basis for pbuilder, if you want
to build Debian packages. Or both.)
Obviously anything that is related to hardware access won't work
in there (because no full system is emulated), but it's great
for e.g. compiling software - and it's a bit faster than using
the system emulator, because it just emulates the program's CPU
instructions and translates syscalls, it still uses your host's
kernel.
Regards,
Christian
[1] https://www.debian.org/releases/stable/arm64/apbs05.html.en#preseed-hooks
[2] Regarding only official ports: for ppc64el, you need to
export QEMU_CPU=POWER8; on powerpc (32bit) some floating
point instructions aren't properly emulated (it causes
trouble with software compiled with -mpowerpc-gpopt); and
the posix_fadvise() syscall is not mapped correctly on
some 32bit platforms (armel, armhf, powerpc and mips; on
mipsel it works though, funnily enough), but the aarch64
qemu-user port is in very good shape, from my experience.
Reply to: