pages tagged armijc's bloghttp://www.hellion.org.uk/blog/tags/arm/ijc's blogikiwiki2014-07-29T19:36:50ZDebian Installer ARM64 Dailieshttp://www.hellion.org.uk/blog/posts/debian-installer-arm64-dailies/2014-07-29T19:36:50Z2014-07-29T19:36:50Z
<p>It's taken a while but all of the pieces are finally in place to run
successfully through <a href="https://www.debian.org/devel/debian-installer/">Debian
Installer</a> on ARM64 using the
<a href="https://wiki.debian.org/Arm64Port">Debian ARM64 port</a>.</p>
<p>So I'm now running nightly builds locally and uploading them to
<a href="http://www.hellion.org.uk/debian/didaily/arm64/">http://www.hellion.org.uk/debian/didaily/arm64/</a>.</p>
<p>If you have <a href="http://www.cacert.org/">CACert</a> in your CA roots then you
might prefer the <a href="https://www.hellion.org.uk/debian/didaily/arm64/">slightly more secure
version</a>.</p>
<p>Hopefully before too long I can arrange to have them building on one
of the project machines and uploaded to somewhere a little more formal
like people.d.o or even the <a href="http://d-i.debian.org/daily-images/">regular Debian Installer dailies
site</a>. This will have to do for
now though.</p>
<h2>Warning</h2>
<p>The arm64 port is currently hosted on <a href="http://www.debian-ports.org/">Debian
Ports</a> which only supports the <a href="https://www.debian.org/releases/sid/">unstable
"sid"</a> distribution. This means
that installation can be a bit of a moving target and sometimes fails
to download various installer components or installation
packages. Mostly it's just a case of waiting for the
<a href="http://buildd.debian-ports.org/status/architecture.php?a=arm64&suite=sid">buildd</a>
and/or archive to catch up. You have been warned!</p>
<h2>Installing in a Xen guest</h2>
<p>If you are lucky enough to have access to some 64-bit ARM hardware
(such as the <a href="http://www.apm.com/products/data-center/x-gene-family/x-gene/">APM
X-Gene</a>,
see
<a href="http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/APMXGeneMustang">wiki.xen.org</a>
for setup instructions) then installing Debian as a guest is pretty
straightforward.</p>
<p>I suppose if you had lots of time (and I do mean lots) you could also
install under Xen running on the <a href="http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/FastModels">Foundation or Fast
Model</a>. I
wouldn't recommend it though.</p>
<p>First download the installer
<a href="http://www.hellion.org.uk/debian/didaily/arm64/daily/netboot/vmlinuz">kernel</a>
and
<a href="http://www.hellion.org.uk/debian/didaily/arm64/daily/netboot/initrd.gz">ramdisk</a>
onto your dom0 filesystem (e.g. to <code>/root/didaily/arm64</code>).</p>
<p>Second create a suitable guest config file such as:</p>
<pre><code>name = "debian-installer"
disk = ["phy:/dev/LVM/debian,xvda,rw"]
vif = [ '' ]
memory = 512
kernel = "/root/didaily/arm64/vmlinuz"
ramdisk= "/root/didaily/arm64/initrd.gz"
extra = "console=hvc0 -- "
</code></pre>
<p>In this example I'm installing to a raw logical volume
<code>/dev/LVM/debian</code>. You might also want to use
<a href="http://www.hellion.org.uk/cgi-bin/randmac.pl">randmac</a> to generate a
permanent MAC address for the Ethernet device (specified as
<code>vif = ['mac=xx:xx:xx:xx:xx:xx']</code>).</p>
<p>Once that is done you can start the guest with:</p>
<pre><code>xl create -c cfg
</code></pre>
<p>From here you'll be in the installer and things carry on as
usual. You'll need to manually point it to <code>ftp.debian-ports.org</code> as
the mirror, or you can preseed by appending to the <code>extra</code> line in the
cfg like so:</p>
<pre><code>mirror/country=manual mirror/http/hostname=ftp.debian-ports.org mirror/http/directory=/debian
</code></pre>
<p>Apart from that there will be a warning about not knowing how to setup
the bootloader but that is normal for now.</p>
<h2>Installing in Qemu</h2>
<p>To do this you will need a version of <a href="http://www.hellion.org.uk/blog/tags/arm/Qemu">http://www.qemu.org</a>
which supports <code>qemu-system-aarch64</code>. The latest release doesn't yet
so I've been using
<a href="http://git.qemu.org/?p=qemu.git;a=commit;h=f368c33d5ab09dd5656924185cd975b11838cd25">v2.1.0-rc3</a>
(it seems upstream are now up to -rc5). Once qemu is built and
installed and the installer
<a href="http://www.hellion.org.uk/debian/didaily/arm64/daily/netboot/vmlinuz">kernel</a>
and
<a href="http://www.hellion.org.uk/debian/didaily/arm64/daily/netboot/initrd.gz">ramdisk</a>
have been downloaded to <code>$DI</code> you can start with:</p>
<pre><code>qemu-system-aarch64 -M virt -cpu cortex-a57 \
-kernel $DI/vmlinuz -initrd $DI/initrd.gz \
-append "console=ttyAMA0 -- " \
-serial stdio -nographic --monitor none \
-drive file=rootfs.qcow2,if=none,id=blk,format=qcow2 -device virtio-blk-device,drive=blk \
-net user,vlan=0 -device virtio-net-device,vlan=0
</code></pre>
<p>That's using a qcow2 image for the rootfs, I think I created it with
something like:</p>
<pre><code>qemu-img create -f qcow2 rootfs.qcow2 4G
</code></pre>
<p>Once started installation proceeds much like normal. As with Xen you
will need to either point it at the debian-ports archive by hand or
preseed by adding to the <code>-append</code> line and the warning about no
bootloader configuration is expected.</p>
<h2>Installing on real hardware</h2>
<p>Someone should probably try this ;-).</p>
sunxi-tools now available in Debianhttp://www.hellion.org.uk/blog/posts/sunxi-tools-in-debian/2014-07-21T18:10:23Z2014-07-21T18:10:23Z
<p>I've recently packaged the <a href="http://linux-sunxi.org/Sunxi-tools">sunxi
tools</a> for Debian. These are a set
of tools produce by the <a href="http://linux-sunxi.org/Main_Page">Linux Sunxi
project</a> for working with the
<a href="http://allwinner.com/">Allwinner</a> "sunxi" family of processors. See
the <a href="http://packages.debian.org/sunxi%2Dtools">package page</a> for details. Thanks to
Steve McIntyre for sponsoring the initial upload.</p>
<p>The most interesting component of the package are the tools for
working with the Allwinner processors' <a href="http://linux-sunxi.org/FEL">FEL
mode</a>. This is a low-level processor mode
which implements a simple USB protocol allowing for initial
programming of the device and recovery which can be entered on boot
(usually be pressing a special 'FEL button' somewhere on the
device). It is thanks to FEL mode that most sunxi based devices are
pretty much unbrickable.</p>
<p>The most common use of FEL is to <a href="http://linux-sunxi.org/FEL/USBBoot">boot over
USB</a>. In the Debian package the
<code>fel</code> and <code>usb-boot</code> tools are named <code>sunxi-fel</code> and <code>sunxi-usb-boot</code>
respectively but otherwise can be used in the normal way described on
the sunxi wiki pages.</p>
<p>One enhancement I made to the Debian version of <code>usb-boot</code> is to
integrate with the <a href="http://packages.debian.org/u%2Dboot">u-boot</a> packages to allow you to easily
FEL boot any sunxi platform supported by the Debian packaged version
of u-boot (currently only Cubietruck, more to come I hope). To make
this work we take advantage of <a href="https://wiki.debian.org/Multiarch">Multiarch</a> to install the
<a href="https://wiki.debian.org/ArmHardFloatPort">armhf</a> version of u-boot (unless
your host is already armhf of course, in which case just install the
u-boot package):</p>
<pre><code># dpkg --add-architecture armhf
# apt-get update
# apt-get install u-boot:armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
u-boot:armhf
0 upgraded, 1 newly installed, 0 to remove and 1960 not upgraded.
Need to get 0 B/546 kB of archives.
After this operation, 8,676 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package u-boot:armhf.
(Reading database ... 309234 files and directories currently installed.)
Preparing to unpack .../u-boot_2014.04+dfsg1-1_armhf.deb ...
Unpacking u-boot:armhf (2014.04+dfsg1-1) ...
Setting up u-boot:armhf (2014.04+dfsg1-1) ...
</code></pre>
<p>With that done FEL booting a cubietruck is as simple as starting the
board in FEL mode (by holding down the FEL button when powering on)
and then:</p>
<pre><code># sunxi-usb-boot Cubietruck -
fel write 0x2000 /usr/lib/u-boot/Cubietruck_FEL/u-boot-spl.bin
fel exe 0x2000
fel write 0x4a000000 /usr/lib/u-boot/Cubietruck_FEL/u-boot.bin
fel write 0x41000000 /usr/share/sunxi-tools//ramboot.scr
fel exe 0x4a000000
</code></pre>
<p>Which should result in something like this on the Cubietruck's serial
console:</p>
<pre><code>U-Boot SPL 2014.04 (Jun 16 2014 - 05:31:24)
DRAM: 2048 MiB
U-Boot 2014.04 (Jun 16 2014 - 05:30:47) Allwinner Technology
CPU: Allwinner A20 (SUN7I)
DRAM: 2 GiB
MMC: SUNXI SD/MMC: 0
In: serial
Out: serial
Err: serial
SCSI: SUNXI SCSI INIT
Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net: dwmac.1c50000
Hit any key to stop autoboot: 0
sun7i#
</code></pre>
<p>As more platforms become supported by the u-boot packages you should
be able to find them in <code>/usr/lib/u-boot/*_FEL</code>.</p>
<p>There is one minor inconvenience which is the need to run
<code>sunxi-usb-boot</code> as root in order to access the FEL USB device. This
is easily resolved by creating <code>/etc/udev/rules.d/sunxi-fel.rules</code>
containing either:</p>
<pre><code>SUBSYSTEMS=="usb", ATTR{idVendor}=="1f3a", ATTR{idProduct}=="efe8", OWNER="myuser"
</code></pre>
<p>or</p>
<pre><code>SUBSYSTEMS=="usb", ATTR{idVendor}=="1f3a", ATTR{idProduct}=="efe8", GROUP="mygroup"
</code></pre>
<p>To enable access for <code>myuser</code> or <code>mygroup</code> respectively. Once you have
created the rules file then to enable:</p>
<pre><code># udevadm control --reload-rules
</code></pre>
<p>As well as the FEL mode tools the packages also contain a
<a href="http://linux-sunxi.org/Fex_Guide">FEX</a> (de)compiler. FEX is
Allwinner's own hardware description language and is used with their
Android SDK kernels and the <a href="http://linux-sunxi.org/Linux_Kernel">fork of that
kernel</a> maintained by the
linux-sunxi project. Debian's kernels follow mainline and therefore
use <a href="http://www.devicetree.org/Main_Page">Device Tree</a>.</p>
Running ARM Grub on U-boot on Qemuhttp://www.hellion.org.uk/blog/posts/grub-on-uboot-on-qemu/2013-12-26T13:20:51Z2013-12-26T13:20:51Z
<p>At the <a href="https://wiki.debconf.org/wiki/Miniconf-UK/2013">Mini-debconf</a>
in Cambridge back in November there was an ARM Sprint (which Hector
wrote up as a <a href="http://lists.debian.org/debian-arm/2013/12/msg00002.html">Bits from ARM
porters</a>
mail). During this there a brief discussion about using
<a href="http://www.gnu.org/software/grub/">GRUB</a> as a standard bootloader,
particularly for ARM server devices. This has the advantage of
providing a more "normal" (which in practice means "x86 server-like")
as well as flexible solution compared with the existing <a href="http://packages.debian.org/flash%2Dkernel">flash-kernel</a> tool which is often used on ARM.</p>
<p>On ARMv7 devices this will more than likely involve chain loading from
the <a href="http://www.denx.de/wiki/U-Boot">U-Boot</a> supplied by the
manufacturer. For test and development it would be useful to be able
to set up a similar configuration using
<a href="http://wiki.qemu.org/Main_Page">Qemu</a>.</p>
<h2>Cross-compilers</h2>
<p>Although this can be built and run on an ARM system I am using a cross
compiler here. I'm using
<code>gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux</code> from
<a href="http://www.linaro.org/">Linaro</a>, which can be downloaded from the
<a href="https://launchpad.net/linaro-toolchain-binaries">linaro-toolchain-binaries</a>
page on Launchpad. (It looks like 2013.10 is the latest available
right now, I can't see any reason why that wouldn't be fine).</p>
<p>Once the cross-compiler has been downloaded unpack it somewhere, I
will refer to the resulting
<code>gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux</code> directory as
<code>$CROSSROOT</code>.</p>
<p>Make sure <code>$CROSSROOT/bin</code> (which contains <code>arm-linux-gnueabihf-gcc</code>
etc) is in your <code>$PATH</code>.</p>
<h2>Qemu</h2>
<p>I'm using the version packaged in Jessie, which is 1.7.0+dfsg-2. We
need both <a href="http://packages.debian.org/qemu%2Dsystem%2Darm">qemu-system-arm</a> for running the final system and
<a href="http://packages.debian.org/qemu%2Duser">qemu-user</a> to run some of the tools. I'd previously tried
an older version of qemu (1.6.x?) and had some troubles, although they
may have been of my own making...</p>
<h2>Das U-boot for Qemu</h2>
<p>First thing to do is to build a suitable u-boot for use in the qemu
emulated environment. Since we need to make some configuration changes
we need to build from scratch.</p>
<p>Start by cloning the upstream <a href="http://git-scm.com/">git</a> tree:</p>
<pre><code>$ git clone git://git.denx.de/u-boot.git
$ cd u-boot
</code></pre>
<p>I am working on top of <code>e03c76c30342</code> "powerpc/mpc85xx: Update
CONFIG_SYS_FSL_TBCLK_DIV for T1040" dated Wed Dec 11 12:49:13 2013
+0530.</p>
<p>We are going to use the Versatile Express Cortex-A9 u-boot but first we
need to enable some additional configuration options:</p>
<ul>
<li><code>CONFIG_API</code> -- This enables the u-boot API which Grub uses to
access the lowlevel services provided by u-boot. This means that
grub doesn't need to contains dozens of platform specific flash,
mmc, nand, network, console drivers etc and can be completely
platform agnostic.</li>
<li><code>CONFIG_SYS_MMC_MAX_DEVICE</code> -- Setting <code>CONFIG_API</code> needs this.</li>
<li><code>CONFIG_CMD_EXT2</code> -- Useful for accessing EXT2 formatted
filesystems. In this example I use a VFAT <code>/boot</code> for convenience
but in a real system we would want to use EXT2 (or even something
more modern)).</li>
<li><code>CONFIG_CMD_ECHO</code> -- Just useful.</li>
</ul>
<p>You can add all these to <code>include/configs/vexpress_common.h</code>:</p>
<pre><code>#define CONFIG_API
#define CONFIG_SYS_MMC_MAX_DEVICE 1
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_ECHO
</code></pre>
<p>Or you can apply the <a href="http://patchwork.ozlabs.org/patch/304786/">patch which I sent upstream</a>:</p>
<pre><code>$ wget -O - http://patchwork.ozlabs.org/patch/304786/raw | git apply --index
$ git commit -m "Additional options for grub-on-uboot"
</code></pre>
<p>Finally we can build u-boot:</p>
<pre><code>$ make CROSS_COMPILE=arm-linux-gnueabihf- vexpress_ca9x4_config
$ make CROSS_COMPILE=arm-linux-gnueabihf-
</code></pre>
<p>The result is a <code>u-boot</code> binary which we can load with qemu.</p>
<h2>GRUB for ARM</h2>
<p>Next we can build grub. Start by cloning the upstream git tree:</p>
<pre><code>$ git clone git://git.sv.gnu.org/grub.git
$ cd grub
</code></pre>
<p>By default grub is built for systems which have RAM at address
<code>0x00000000</code>. However the Versatile Express platform which we are
targeting has RAM starting from <code>0x60000000</code> so we need to make a
couple of modifications. First in <code>grub-core/Makefile.core.def</code> we
need to change <code>arm_uboot_ldflags</code>, from:</p>
<pre><code>-Wl,-Ttext=0x08000000
</code></pre>
<p>to</p>
<pre><code>-Wl,-Ttext=0x68000000
</code></pre>
<p>and second we need make a similar change to <code>include/grub/offsets.h</code> changing
<code>GRUB_KERNEL_ARM_UBOOT_LINK_ADDR</code> from <code>0x08000000</code> to <code>0x68000000</code>.</p>
<p>Now we are ready to build grub:</p>
<pre><code>$ ./autogen.sh
$ ./configure --host arm-linux-gnueabihf
$ make
</code></pre>
<p>Now we need to build the final grub "kernel" image, normally this
would be taken care of by <code>grub-install</code> but because we are cross
building grub we cannot use this and have to use <code>grub-mkimage</code>
directly. However the version we have just built is for the ARM target
and not for host we are building things on. I've not yet figured out
how to build grub for ARM while building the tools for the host system
(I'm sure it is possible somehow...). Luckily we can use qemu to run
the ARM binary:</p>
<pre><code>$ cat load.cfg
set prefix=(hd0)
$ qemu-arm -r 3.11 -L $CROSSROOT/arm-linux-gnueabihf/libc \
./grub-mkimage -c load.cfg -O arm-uboot -o core.img -d grub-core/ \
fat ext2 probe terminal scsi ls linux elf msdospart normal help echo
</code></pre>
<p>Here we create <code>load.cfg</code> which is the setup script which will be
built into the grub kernel, our version just sets the root device so
that grub can find the rest of its configuration.</p>
<p>Then we use <code>qemu-arm-static</code> to invoke <code>grub-mkimage</code>. The "<code>-r 3.11</code>"
option tells qemu to pretend to be a 3.11 kernel (which is required by
the libc used by our cross compiler, without this you will get a
<code>fatal: kernel too old</code> message) and "<code>-L $CROSSROOT/...</code>" tells it
where to find the basic libraries, such as the dynamic linker (luckily
<code>grub-mkimage</code> doesn't need much in the way of libraries so we don't
need a full cross library environment.</p>
<p>The <code>grub-mkimage</code> command passes in the <code>load.cfg</code> and requests an
output kernel targeting <code>arm-uboot</code>, <code>core.img</code> is the output file
and the modules are in <code>grub-core</code> (because we didn't actually install
grub in the target system, normally these would be found in
/boot/grub). Lastly we pass in a list of default modules to build into
the kernel, including filesystem drivers (<code>fat</code>, <code>ext2</code>), disk drivers
(<code>scsi</code>), partition handling (<code>msdos</code>), loaders (<code>linux</code>, <code>elf</code>), the
menu system (<code>normal</code>) and various other bits and bobs.</p>
<p>So after all the we now have our grub kernel in <code>core.img</code>.</p>
<h2>Putting it all together</h2>
<p>Before we can launch qemu we need to create various disk images.</p>
<p>Firstly we need some images for the 2 64M flash devices:</p>
<pre><code>$ dd if=/dev/zero of=pflash0.img bs=1M count=64
$ dd if=/dev/zero of=pflash1.img bs=1M count=64
</code></pre>
<p>We will initialise these later from the u-boot command line.</p>
<p>Secondly we need an image for the root filesystem on an MMC
device. I'm using a FAT formatted image here simply for the
convenience of using <a href="http://packages.debian.org/mtools">mtools</a> to update the images during
development.</p>
<pre><code>$ dd if=/dev/zero of=mmc.img bs=1M count=16
$ /sbin/mkfs.vfat mmc.img
</code></pre>
<p>Thirdly we need a kernel, device tree and grub configuration on our
root filesystem. For the first two I extracted them from the standard
<code>armmp</code> kernel flavour package. I used the
<a href="http://backports.org">backports.org</a> version
<a href="http://snapshot.debian.org/package/linux/3.11.8-1~bpo70%2B1/#linux-image-3.11-0.bpo.2-armmp_3.11.8-1:7e:bpo70:2b:1">3.11-0.bpo.2-armmp</a>
version and extracted <code>/boot/vmlinuz-3.11-0.bpo.2-armmp</code> as <code>vmlinuz</code>
and <code>/usr/lib/linux-image-3.11-0.bpo.2-armmp/vexpress-v2p-ca9.dtb</code> as
<code>dtb</code>. Then I hand coded a simple <code>grub.cfg</code>:</p>
<pre><code>menuentry 'Linux' {
echo "Loading vmlinuz"
set root='hd0'
linux /vmlinuz console=ttyAMA0 ro debug
devicetree /dtb
}
</code></pre>
<p>In a real system the kernel and dtb would be provided by the kernel
packages and <code>grub.cfg</code> would be generated by <code>update-grub</code>.</p>
<p>Now that we have all the bits we need copy them into the root of
<code>mmc.img</code>. Since we are using a FAT formatted image we can use
<code>mcopy</code> from the <a href="http://packages.debian.org/mtools">mtools</a> package.</p>
<pre><code>$ mcopy -v -o -n -i mmc.img core.img dtb vmlinuz grub.cfg ::
</code></pre>
<p>Finally after all that we can run qemu passing it our u-boot binary
and the mmc and flash images and requesting a Cortex-A9 based
Versatile Express system with 1GB of RAM:</p>
<pre><code>$ qemu-system-arm -M vexpress-a9 -kernel u-boot -m 1024m -sd mmc.img \
-nographic -pflash pflash0.img -pflash pflash1.img
</code></pre>
<p>Then at the <code>VExpress#</code> prompt we can configure the default <code>bootcmd</code>
to load grub and save the environment to the flash images. The
backslash escapes (<code>\$</code> and <code>\;</code>) should be included as written here
so that e.g. the variables are only evaluated when <code>bootcmd</code> is
evaluated and not immediately when setting <code>bootcmd</code> and the <code>bootm</code>
is set as part of <code>bootcmd</code> instead of executed immediately:</p>
<pre><code>VExpress# setenv bootcmd fatload mmc 0:0 \${loadaddr} core.img \; bootm \${loadaddr}
VExpress# saveenv
</code></pre>
<p>Now whenever we boot the system it will automatically load boot grub
from the mmc and launch it. Grub in turn will load the Linux binary
and DTB and launch those. I haven't actually configure Linux with a
root filesystem here so it will eventually panic after failing to
find root.</p>
<h2>Future work</h2>
<p>The most pressing issue is the hard coded load address built in to the
grub kernel image. This is something which needs to be discussed with
the upstream grub maintainers as well as the Debian package
maintainers.</p>
<p>Now that the ARM packages have hit Debian (in experimental in the
2.02~beta2-1 package) I also plan to start looking at <a href="http://packages.debian.org/debian%2Dinstaller">debian-installer</a> integration as well as updating <a href="http://packages.debian.org/flash%2Dkernel">flash-kernel</a> to setup the chain load of grub instead of loading a
kernel directly.</p>
Linaro Connect Asia 2013http://www.hellion.org.uk/blog/posts/linaro-connect-asia-2013-post/2013-03-13T14:19:19Z2013-03-13T14:19:19Z
<p>I've just got back from <a href="http://www.linaro.org/connect">Linaro Connect Asia
2013</a> in Hong Kong. This was my first
time back in Hong Kong since 1995 when I left after living there for
10 years. It was really interesting to see how much the place had
changed, as well as how much it hadn't!</p>
<p>I started the week by giving a talk together with Stefano Stabellini
<em><a href="http://lca-13.zerista.com/event/member/72664">Introducing Xen on
ARM</a></em> to a full
house. The slides can be found on the event page or <a href="https://docs.google.com/presentation/d/1YtCPADZmGcMpNvIwIm2a7AUsM-khkzhyYW_pbbWAqQM/pub?start=false&loop=false&delayms=60000#slide=id.p">google
docs</a>.
There is a <a href="http://www.youtube.com/watch?v=D0mTOKhAm6Y">video on
youtube</a> but due to the
cameras being setup for a fish-bowl style panel it is unfortunately
mostly of my backside. The reception was excellent and the talk seeded
a large number of hallway track conversations with all the many folks
who are interested in Xen on the ARM platform.</p>
<p>The day after our talk Lars Kurth (Xen.org community manager) and Mark
Heath (VP of XenServer Engineering, and my boss) gave a
<a href="http://lca-13.zerista.com/event/member/72404">keynote</a>
(<a href="http://www.youtube.com/watch?v=Nt3tiaEbUD4">video</a>) announced
Citrix's intention to join the <a href="http://www.linaro.org/linux-on-arm/meet-the-team/linaro-enterprise-group-leg">Linaro Enterprise
Group</a>
(AKA "LEG") on the 1st of April. This is pretty exciting for me since
it means I'll get to work much more closely with the Linaro and ARM
communities and spend even more of my time hacking on Xen on ARM!</p>
<p>At some point Stefano and myself were also video interviewed by
Charbax of <a href="http://armdevices.net/">http://armdevices.net/</a> but it
doesn't appear to have gone online
yet. <a href="http://www.youtube.com/watch?v=bUxoABBzo_U">Lars</a> and
<a href="http://armdevices.net/2013/03/06/citrix-mark-heath-vp-of-xenserver-at-linaro-connect-2013/">Mark</a>
also gave interviews which are online already.</p>
<p>One nice thing about Connect is that the afternoons are left free of
talks so I managed to find time in the hackrooms to implement <a href="http://lists.xen.org/archives/html/xen-devel/2013-03/msg00414.html">SMP
host
support</a>
and <a href="http://lists.xen.org/archives/html/xen-devel/2013-03/msg00924.html">64-bit domain 0
support</a>
for Xen on ARM as well as getting multiarch cross building working for
upstream Xen with Wookey's kind assistance (no patches for this yet
since I still need to clean them up). It was also useful to catch up
with the ARM kernel developers and KVM guys to see what they are up
to and share ideas etc.</p>
<p>Finally right at the end Stefano and myself showed Xen on ARM at <a href="http://www.linaro.org/connect/demo-friday">Demo
Friday</a>. We had Xen running
on the <a href="http://www.arndaleboard.org/wiki/index.php/Main_Page">Arndale
Board</a>, <a href="http://www.google.com/intl/en/chrome/devices/samsung-chromebook.html#ss-cb">ARM
Chromebook</a>
and 64-bit ARMv8 using the emulators (no hardware being available
yet).</p>
<p>All in all I had an excellent (if tiring) week, there was loads of
interest in Xen on ARM and in Citrix joining LEG and everyone was very
welcoming. I'm really looking forward to the next Connect in Dublin.</p>
<p>Outside of Connect I managed to find time to visit <a href="http://en.wikipedia.org/wiki/Sham_Shui_Po">Sham Shui
Po</a> at look at all the
gadgets but managed to resist buying anything (Stefano got a Thinkpad
X230, which was enough retail therapy for both of us!). I caught up
with my sister (who lives there again), her boyfriend and my parents
(who happened to be visiting her that week). I also managed have some
drinks with some old school friends, most of whom I've not seen for
nearly twenty years, but it was just like old times ;-).</p>
<p>I'm off again to Hong Kong next week with my family to visit my sister
(yes, there was some bad planning involved here...). This time I plan
to do all the toursity type stuff that I never did while I lived
there. I've also got tickets for the <a href="http://www.hksevens.com/eng/home.php">Hong Kong Rubgy
Sevens</a> and hopefully I'll
manage catch up with some more old friends. I probably won't be able
to resist buying gadgets this time around though.</p>
LinaroConnect 2013, Talks and Demoshttp://www.hellion.org.uk/blog/posts/linaroconnect-2013/2013-02-26T15:58:32Z2013-02-26T15:58:32Z
<p>My colleague Stefano Stabellini and I are in the process of putting
the finishing touches to our presentation which we are giving at
<a href="http://www.linaro.org/connect">Linaro Connect</a> next week in Hong
Kong. If you are there come and see <a href="http://lca-13.zerista.com/event/member/72664">Introducing XEN on
ARM</a> on Monday at 1100,
we'll be running through some of the basics of Xen as well as the
specifics of how this translates into use on the ARM virtualised
platform and talking about our status and roadmap going forward.</p>
<p>As well as that we will also be demoing Xen on ARM, both on v7
hardware platforms and on v8 software models, at <a href="http://www.linaro.org/connect/demo-friday">Demo
Friday</a>. I've been mostly
working on the 64-bit port recently and the initial set of 45(!)
patches was committed at the end of last week --- just in time!</p>
<p>The other main Xen on ARM event at this years Connect is a
<a href="http://lca-13.zerista.com/event/member/72404">keynote</a> on the Tuesday
morning given by Lars Kurth (Xen.org Community Manager) and Mark Heath
(XenServer VP of Engineering, and also my boss).</p>
<p>Other than that my schedule seems to be running over with other
interesting sounding talks and there are certainly going to be plenty
of people to catch up with, but hopefully I'll have enough time to put
the finishing touches onto ARMv8 64-bit guest support in the hackrooms
like I'm planning...</p>
<p>Looking forward to seeing some of you there!</p>
Foreign Chroots with schroot and qemuhttp://www.hellion.org.uk/blog/posts/foreign-chroots-with-schroot-and-qemu/2012-12-17T13:46:54Z2012-12-17T13:46:54Z
<p>Since I've been working on <a href="http://packages.debian.org/qcontrol">qcontrol</a> I've had need of a way
to build packages in an ARM environment. Since all my native ARM
hardware is "production" (at least so far as something can be
production in a home environment) I prefer to avoid installing
development tools on them. When I started looking into this all my ARM
systems ran from relatively small flash devices which also ruled out
the possibility of a development chroot. After search the web a bit I
discovered that it is possible to use <a href="http://packages.debian.org/qemu%2Duser%2Dstatic">qemu-user-static</a>
together with [[!binfmt-support ]] to create cross architecture chroots
which can be entered mostly transparently. It is also possible to
combine this with <a href="http://packages.debian.org/schroot">schroot</a> and <a href="http://packages.debian.org/sbuild">sbuild</a> which
makes the day to day use pretty much the same as a native or biarch
chroot.</p>
<p>Since I've now had to rediscover how to do this twice (once for Sid
and then again when I realized I also needed a Wheezy environment) I
thought I should write it down for the benefit of my future self.</p>
<p>First things first lets install the various packages which we need. As
well as <a href="http://packages.debian.org/debootstrap">debootstrap</a> to create the chroot we need
<code>qemu-user-static</code> and <code>binfmt-support</code> to allow us to run ARM
binaries:</p>
<pre><code>$ sudo apt-get install debootstrap qemu-user-static binfmt-support
</code></pre>
<p>I'm using <code>schroot</code>'s lvm-snapshot mode so we need an LVM volume,
formatted with a filesystem and mounted in a temporary location:</p>
<pre><code>$ sudo lvcreate -L8G -n sbuild-wheezy-armel /dev/VG
$ sudo mkfs.ext3 /dev/VG/sbuild-wheezy-armel
$ sudo mount /dev/VG/sbuild-wheezy-armel /mnt/
</code></pre>
<p>Next we need to create the chroot. For this we use <code>debootstrap</code> in
foreign mode which does a 2 stage setup, firstly by using the
<code>--foreign</code> option:</p>
<pre><code>$ sudo debootstrap --variant=buildd --include=fakeroot,build-essential \
--arch=armel --foreign \
wheezy /mnt http://<DEBIAN-MIRROR>/debian/
</code></pre>
<p>Now we (temporarily) copy the <code>qemu-arm-static</code> binary into the chroot
(at the place where <code>binfmt-support</code> expects it), change into the
chroot and run <code>debootstrap</code>'s second stage to finish the basic chroot
setup:</p>
<pre><code>$ sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/
$ sudo chroot /mnt
(chroot)# ./debootstrap/debootstrap --second-stage
(chroot)# exit
</code></pre>
<p>Now that we have a basic chroot in place it needs a little bit of
tailoring. I've found the easiest way to do this is to use
<code>sbuild-createchroot</code> and then tweak the result:</p>
<pre><code>$ sudo sbuild-createchroot --arch=armel --foreign --setup-only \
wheezy /mnt http://<DEBIAN-MIRROR>/debian/
</code></pre>
<p>If we were building a native chroot then we could have skipped the
<code>debootstrap</code> stuff and let <code>sbuild-createchroot</code> handle
things. Unfortunately this doesn't seem to play nicely with
<code>--foreign</code>.</p>
<p>Now we can remove the <code>qemu-arm-static</code> binary from the
chroot. <code>schroot</code> will automatically bind mount the version from the
host into the chroot which ensures it remains up to date. We can also
unmount the chroot since we will let <code>schroot</code> manage that from here
on:</p>
<pre><code>$ sudo rm /mnt/usr/bin/qemu-arm-static
$ sudo umount /mnt
</code></pre>
<p>Next we need to tweak the resulting <code>schroot</code>/<code>sbuild</code> configuration
since <code>sbuild-createchroot</code> assumes the use of schroot's directory
mode. First remove the symlink to /mnt which it created:</p>
<pre><code>$ sudo rm /etc/sbuild/chroot/wheezy-armel-sbuild
</code></pre>
<p>Lastly we need to edit <code>/etc/schroot/chroot.d/wheezy-armel-sbuild-<SUFFIX></code>
(where is randomly generated) and reconfigure it to use
lvm-snapshot mode, by apply the following changes:</p>
<pre><code> [wheezy-armel-sbuild]
-type=directory
-directory=/mnt
+type=lvm-snapshot
+device=/dev/VG/sbuild-wheezy-armel
+lvm-snapshot-options=--size 2G
description=Debian wheezy/armel autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
</code></pre>
<p>That's it, we now have a chroot which we can trivially invoke via
<code>sbuild</code> to build armel packages:</p>
<pre><code>$ sbuild --arch=armel --dist=wheezy <... other options...>
</code></pre>
<p>We can also use <code>sbuild-update</code> to keep the chroot up to date:</p>
<pre><code>$ sudo sbuild-update -udcar wheezy-armel
</code></pre>
<p>You can also use <code>schroot</code> to login to the chroot directly, although
for that case you'll likely want to create a different chroot using
<code>schroot</code>'s <code>directory</code> or <code>block-device</code> mode instead <code>lvm-snapshot</code>
and drop some of the sbuild specific setup. I expect I'll blog about
this configuration in some more detail at some point in the future
since I'll want to document it to give a more convenient build
environment for <a href="http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions">Xen on
ARM</a>
than the <a href="https://plus.google.com/106815887686504011057/posts/Kgdakxs5cFt">build
farm</a>
which we have at work.</p>