User:Idella4/Xen arm howto

Recent history
Support for the arm arch in xen began with the 4.3.0 release mid 2013. It was provisional support for only 2 of the arm boards. The arm boards are single control boards (SCB) and represent the first expansion from the x86 and x86_64 arches. At the time of writing, the development of xen support of arm is still under heavy active development and will remain so in the medium to long term. Formal support will be in place with the release of xen-4.4.

Introduction
This HowTo outlines the requirements to boot into dom0 in one selected sample arm SCB, the cubieboard2, a new generation 'light weight' model released also around mid 2013. This guide provides a working model of an effective setup that boots a dom0. By their nature, specs of the various arm boards differ. While config settings of some elements are common, those of the kernel build require board specific config data.

Key constituents that require custom configurations to yield xen capbility on arm include:


 * 1) Kernel support
 * 2) Device tree file
 * 3) Bootloader package u-boot
 * 4) Serial console

Key differences
The traditional boot into dom0 in x86(_64) arch(es) takes place via a single kernel image, the standard bzImage or vmlinuz kernel image + the xen kernelxen.gz. file. The boot is invoked via the cmds linux & multiboot in a menu entry of grub.cfg of grub2.

Under arch arm, the kernel image saved to /boot is a zImage coupled with a device tree file generated in company of the build from the kernel source. A 'xenless' boot process loads both files. A boot of dom0 loads both these + the xen kernel, similarly saved to /boot.

Booting takes place via the booloader u-boot, likewise under heavy development. u-boot supplies optional ways of booting; by setting a 'boot script' file, or alternatively, directly from a shell. More on u-boot later.

System setup
In gentoo style, the partioning of the selected drive will have a booting partition for parition one. The prepatory code might resemble;


 * parted /dev/${card} --script -- mkpart primary fat32 2048s 264191s
 * parted /dev/${card} --script -- mkpart primary ext4 264192s 100%
 * mkfs.vfat /dev/${card}p1;mkfs.ext4 /dev/${card}p2

While vfat is often favoured for /boot, testing found that it had issue in reading an essential file for booting, therfore it's recommended to select an ext fs for /boot. The drive itself in the above code is a match for an SD card, the file being /dev/mmcblk0, + the pn suffix. The cubieboard2 boots most reliably with a micro SD card fitted into the slot on or in the board,

This is fine for an inital system, however the better option is to utilise a sata drive for whichg the kernel will make /dev/sdn. While the cubieboard2 provides for connecting 1 sata drive of large storage capacity, the setup requirements are far more demanding. The kernel must provide SATA support AND the drive needs proper powering up.

The cable that comes with the cb2 is limited to a usb rate of 5V and is best 'put aside' and alternate std. connector cables used. Some SATA drives demand a 12V power source which demands powering the drive by separate means. A drive requiring a 12V supply cam be powered by connecting to a host computer's ATX power supply while plugged into the cb2 board.

D'load this script to prepare and install a neophyte gentoo on a micro SD card. The cb2 provides a slot only for the micro card. This code snippet:


 * mount /dev/${card}p2 /mnt/gemtoo/
 * mkdir /mnt/kernel/boot
 * mount /dev/${card}p1 /mnt/gentoo/boot

taken from the script effectively mounts the boot partition gentoo style. The script above acquires a stage/sunxi-3.4 branch kernel, however this is unusable with xen.

The Kernel
To achieve bootup of an arm arch board, linux-sunxi developed an androidish kernel-3.4, however it lacks adequate xen support. While the initial xen support code was added at 2.6.38, futher watershed development took place around 3.7.

The support of arm arch in mainline kernels @ kernel.org is already a long standing work in progress. linux-sunxi have 2 branches dedicated to mainline development; next and devel. At the time of writing, patching of the mmc card support has only just been added to the devel branch, making the setup of booting a dom0 viable. Use git to clone the devel branch @ https://github.com/linux-sunxi/linux-sunxi. The settings needed for MMC/SD support and sata support are:


 * CONFIG_MMC_BLOCK
 * CONFIG_MMC_SUNXI
 * CONFIG_SATA_AHCI_PLATFORM

A wiki at xenproject.org also provides a guide on configuring and building the kernel. See http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner.

At this point it is recommended to initially build a xenless kernel and boot the zImage and device tree before attempting to boot the xen binary hypervisor. Having acquired a 'xen capable' kernel, a build via 'make zImage modules' yields a zImage. A build of "make dtbs" yields a full set of all arm board device tree files.

Device tree file
The file for the cubieboartd2 is sun7i-a20-cubieboard2.dtb. The make and copy of sun7i-a20-cubieboard2.dtb are detailed in the 'gentoo system install script here. Each make and model of an arm board has a corresponding  file that compiles the matching  file.

Descrition of technical aspects of device tree files is beyond the scope of this HowTo document. An outline of such a description with pertinenet links can be found in Xen_ARM_with_Virtualization_Extension of http://wiki.xenproject.org here. Some of the links cite files present in the Documentation folder of the kernel.

Build, emerge xen
At the time of writing, the xen ebuilds are yet to be being keyworded to ~arm. The major cause for delay stems from a fundamental change yielding the xen.gz file unusable in arm. Booting a dom0 requires a xen binary executable, a zImage file in the style built by a kernel. This change was set in the xen-4.4.0-rc branch at xenproject.org, making it the minimal required version of xen. The ebuilds to build xen and xen-tools version 4.4.0_rc6 are currently stored in my dev space here and here.

Boot to dom0 currently requires a serial console from a host source subsequent to the necessaty code still absent in the mainline kernel or @ kernel.org. [See sub-heading "Serial console"] The build requires setting early_printk (as a configure option) in order to to yield full view of output to the serial console.

Booting the xen binary requires an environment set to non secure hyper mode. The mode is set in the build of the bootloader u-boot.

Bootloader u-boot
An outline of this bootloader at the xenproject wiki can be found here To elaborate briefly, the mainline support of u-boot @ linux-sunxi builds in secure mode. At this point in time, the branch by jwrdegoede is the required tree and is entitled the `sunxi-next`. Attempts to set the "NS' mode in this tree fail. The `sunxi-next` branch has the settings required for 'NS' mode set as default.

Anatomy of u-boot methods
Here are 3 main methods or modes


 * u-boot shell
 * uEnv.txt
 * script.bin & boot.scr

On boot, there is the option to enter any key to halt autoload. This 'places' the user in a shell where, like grub or bash, cmds are entered directly. --help options are made available. The bootloader seeks a script file to read. uEnv.txt is a text file of u-boot script cmds. The alternate script file is named boot.scr and requires the presence of script.bin in the boot partition / folder. The boot.scr is generated from a text file, by convention normally named boot.cmd, by the executable mkimage. The naming of the file is quite arbitrary and in this case is aptly named boot.xen.

From the system-install.txt, this line demonstrates mkinage making the boot.scr:


 * mkimage -A arm -T script -C none -d /mnt/gentoo/boot/boot.xen /mnt/gentoo/boot/boot.scr

Install u-boot, boot
The u-boot loader is installed to the start of the drive or card like grub. The install cmd (by dd) is found in the 'gentoo system install script @ my dev space here To boot in secure hyper mode via u-boot requires a re-install of a build of u-boot by a mainline branch @ linux-sunxi, also listed found in the system-install.txt. The boot sripts both implement use of the boot.scr. The boot.xen is here.

In this example, the dev file is /dev/mmcblk0. All required files are copied to the 1st. partition of the SD card, root on the 2nd. partition. The effective boot firstly loads the xen binary file, then the device tree file and the kernel zImage. Note from the boot.xen, the console at login is the xen style hvco. To observe bootup however, the final element is currently an essential, the serial console.

Serial console
While the kernel-3.4 supports a tty console, keyboard and output to vga monitors, the mainline kernel falls far short of these functionalities. To observe bootup and to login, a serial console is mandatory. The host computer displaying the serial console, in my case, was a tower with an x86_64 cpu. The packaged cubieboard2 (cb2) includes a usb adpator cable to service a serial console for the cb2. (Images and specs. of the board's 4 pins are to be found at cubieboard related websites)

Only the TX and RX pins on the cb2's board are essential for connnecting by this cable. The usb plug predictably connects to the host computer. To effect the console, emerge minicom, a terminal emulator that supplies a VT102 window or screen.

Minicom
The host will need configuring of both its kernel and the installed minicom to achieve a working serial console. For the host kernel's config., set


 *   USB Prolific 2303 Single Port Serial Driver

This will supply the driver pl2303. Add the driver to /etc/conf.d/modules for auto loading at boot. This will create a /dev/ttyUSB0.

Minicom requires settings to match the physical specs of the cb2. To configure minicom, under Serial port setup, set


 * Serial Device     : /dev/ttyUSB0
 * Bps/Par/Bits      : 115200 8N1
 * Hardware Flow Control : No
 * Software Flow Control : No

and save. Next, edit the section "# SERIAL CONSOLES" in /etc/inittab of the system of the cb2 to;


 * 0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100
 * s1:12345:respawn:/sbin/agetty -L 115200 hvc0 vt100

The ttyS0 yields a serial console from booting a straight kernel image while the hvc0 yields a console for the 'full xen boot'. At this point, all should be in preapred to boot into dom0 in the cb2 with view via the serial console in the host computer.

Summary
The development of xen support for arm arch, although young, is now established. The key element on which it is most dependant is the development of mainline kernel support headed by linux-sunxi which is and will be a long term work in progress. The rc version of xen used for this guide is 4.4.0-rc6. The release of 4.4.0 has just taken place. It is the first release tha provides 'official' support of the arm arch. The booting of xen domU systems logically requires access to large staorage sata drives to store and manage guest systems. Acknowledgements to the developers @ the xenproject and lunux-sunxi for their co-operation and technical support that made both the booting of a dom0 in the arm arch viable and the making of this HowTo possble.