AArch64
The AArch64 Port of OSv has been started, initially targeting the QEMU Mach-virt platform, running on the ARM Foundation Model v8.
The aarch64-next branch already can support the loader image and running of a simple "hello world" C application on top of OSv, as well as other test applications (default image contains the uush micro shell).
With mainline, the only thing required is to add manually the needed SOs to the bootfs manifest skeleton, since we build only the first stage OSv image.
The latest AArch64 work is happening in the PCI branch at:
https://github.com/hw-claudio/osv_aarch64 "pci"
https://github.com/hw-claudio/osv_aarch64/tree/pci
The PCI branch requires a fair amount of QEMU patches to be useful. The latest version of the patch series needed for getting PCI to work on AArch64 QEMU should be posted soon by Alvise Rigo on qemu-devel.
You can find a QEMU tree which includes all necessary patches at:
https://github.com/hw-claudio/qemu-aarch64-queue "pci-on-machvirt"
https://github.com/hw-claudio/qemu-aarch64-queue/tree/pci-on-machvirt
In order to build the final usr.img there are issues to solve: we need pci, virtio-blk and virtio-net, due to the fact that mkfs.py (for ZFS) and upload_manifest.py communicate with the OSv instance via virtio-net, and we need to have virtio-blk in order to put the ZFS somewhere. For that to happen we need a PCI in Mach-virt to be available and functional. In practice this is also not sufficient: the build system relies on the ACPI power management to "turn off" the VM. Also the python scripts in scripts/ which are called as part of the build are cross-compilation unfriendly as they check for features on the build host instead of the target, and include lots of X86-specific stuff.
A better solution would be to avoid the multi-stage build completely, and just perform the tasks that currently require running OSv in a user space process as part of the normal build. However there seem to be issues related to zfs to make this work.
These are some brief instructions about how to cross-compile OSv's loader.img (very incomplete still) on an X86-64 build host machine.
At the time of writing this, the available functionality is minimal: the loader image boots, gic is initialized, timers are initialized, etc, and a simple hello world application is started on top of OSv (in the case of aarch64-next), or you will get an abort with a backtrace in zfs (for master).
You can find a 32bit (needs multilib 😟) crosscompiler from Linaro, in particular the package
gcc-linaro-aarch64-linux-gnu-4.8-2013.12_linux, which is not distro-specific 😃, and includes all tools needed for building.
http://releases.linaro.org/13.12/components/toolchain/binaries
For the host root filesystem for AArch64, a good option is the Linaro LEG Image
linaro-image-leg-java-genericarmv8-20131215-598.rootfs.tar.gz
http://releases.linaro.org/13.12/openembedded/aarch64/
You can experiment with other images and compilers from Linaro, but those I am using right now.
For Ubuntu there are AArch64 crosscompilers available in the official repositories as well. Packages are named g++-4.8-aarch64-linux-gnu and gcc-4.8-aarch64-linux-gnu.
Ubuntu is also used over here, and works ok.
You will need to have or build an AArch64 linux kernel for the Host, which will be run on top of the Foundation v8 Model. In addition to that, you will need the bootwrapper, which you can get from:
http://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/boot-wrapper-aarch64.git
Use the foundation-v8.dts, and my suggestion is to use nfsroot to mount the root filesystem (the linaro LEG image). The boot wrapper takes as input the linux kernel Image and produces linux-system.axf, which will be the input for the Foundation Model.
Start the Foundation model:
./Foundation_v8 --image=linux-system.axf --cores=1 --network=nat --network-nat-ports=1234=1234
The latter option will expose the 1234 port on the host side to the same port number in the guest running inside the model. You can add additional mappings as desired/needed.
If you are skipping the user space initialization via something like init=/bin/sh for speedup (edit the bootwrapper Makefile), in Foundation model you might need to run:
/sbin/udhcpc eth0
Nothing to do anymore, since they are now part of the mainline tree.
In addition to the general requirements for building OSv (see README.md),
note that the simple build system recognizes the ARCH and CROSS_PREFIX environment variables, and looks for the following build tools:
CXX=$(CROSS_PREFIX)g++
CC=$(CROSS_PREFIX)gcc
LD=$(CROSS_PREFIX)ld
STRIP=$(CROSS_PREFIX)strip
OBJCOPY=$(CROSS_PREFIX)objcopy
HOST_CXX=g++
In order to build AArch64, countrary to the past when the target architecture was automatically detected by running the supplied compiler, you need to explicitly say make ARCH=aarch64, otherwise the build system will try to detect ARCH running uname on the host machine, and try to build x64.
At the beginning of the build process, look for this message:
build.mk:
build.mk: building arch=aarch64, override with ARCH env
build.mk:
If the message does not say arch=aarch64, the crosscompiler could not be found or run correctly. In this case, check the CROSS_PREFIX variable, or the compiler binary name if it's not canonical (do you need to add a symlink for example from g++-4.8.3 to g++ ?).
An example of command line for QEMU which works running on top of Foundation Model with kvm with an AArch64 qemu-system-aarch64 binary is:
$ qemu-system-aarch64 -nographic -M virt -enable-kvm \
-kernel ./loader.img -cpu host -m 1024M
An example of command line for QEMU running on system emulation on an x86_64 host with an x86_64 qemu-system-aarch64 binary is:
$ qemu-system-aarch64 -nographic -M virt \
-kernel ./loader.img -cpu cortex-a57 -m 1024M
Jani Kokkonen <[email protected]>
Claudio Fontana <[email protected]>