pages tagged debianijc's bloghttp://www.hellion.org.uk/blog/tags/debian/ijc's blogikiwiki2015-11-06T10:47:10ZCambridge mini-Debconfhttp://www.hellion.org.uk/blog/posts/cambridge-mini-debconf-2015/2015-11-06T10:47:10Z2015-11-06T10:47:10Z
<p>I am currently attending the
<a href="https://wiki.debian.org/DebianEvents/gb/2015/MiniDebConfCambridge">mini-Debconf</a>
being held in space generously provided by ARM's offices in Cambridge,
UK. Thanks to ARM and <a href="https://wiki.debian.org/DebianEvents/gb/2015/MiniDebConfCambridge#Sponsors">the other sponsors</a>
for making this possible.</p>
<p>Yesterday I made a pass through the <a href="https://bugs.debian.org/src:xen">bug
list</a> for the <a href="http://packages.debian.org/xen">Xen
packages</a>. According to the replies I have received from the
<a href="https://www.debian.org/Bugs/">BTS</a> I looked at and acted on:</p>
<ul>
<li><a href="http://bugs.debian.org/797205">#797205</a>: Tagged to reflect that I had previously
forwarded upstream.</li>
<li><a href="http://bugs.debian.org/753358">#753358</a>: Update the found versions and marked as an
upstream issue.</li>
<li><a href="http://bugs.debian.org/798510">#798510</a>: Investigated a bit and asked some followup
questions to the submitter.</li>
<li><a href="http://bugs.debian.org/799122">#799122</a>: Asked for some clarifications from the
submitter and updated the found versions. Will likely followup on
this one some more today.</li>
<li><a href="http://bugs.debian.org/745419">#745419</a>: Sent a
<a href="http://lists.xen.org/archives/html/xen-devel/2015-11/msg00475.html">fix to upstream</a>.</li>
<li><a href="http://bugs.debian.org/784011">#784011</a>, <a href="http://bugs.debian.org/770230">#770230</a>,
<a href="http://bugs.debian.org/776319">#776319</a>: Various CVEs closed as fixed by 4.5.1~rc1-1</li>
<li><a href="http://bugs.debian.org/795721">#795721</a>, <a href="http://bugs.debian.org/784880">#784880</a>: Various CVEs closed as fixed
by 4.6.0-1 (currently in NEW).</li>
<li><a href="http://bugs.debian.org/793132">#793132</a>, <a href="http://bugs.debian.org/785187">#785187</a>: Regular bugs fixed by
4.6.0-1.</li>
<li><a href="http://bugs.debian.org/716496">#716496</a>: Closed (wontfix as far as Debian is concerned)</li>
<li><a href="http://bugs.debian.org/665433">#665433</a>: Closed, apparently unreproducible crash in the
<a href="https://www.debian.org/releases/squeeze/">Squeeze</a> version.</li>
<li><a href="http://bugs.debian.org/439156">#439156</a>, <a href="http://bugs.debian.org/441539">#441539</a>, <a href="http://bugs.debian.org/399073">#399073</a>:
Closed bugs against some truly ancient versions of Xen (Etch or Lenny?). These
got lost when newer versions of Xen were uploaded since the packages have the
Xen major.minor versions in the name. I previously opened <a href="http://bugs.debian.org/796370">#796370</a>
to add a <a href="http://packages.debian.org/reportbug">reportbug</a> script to cause such bugs to be filed against <code>src:xen</code>
in the future and prevent this happening. I hope to see that patch in a future
version of the package.</li>
<li><a href="http://bugs.debian.org/776742">#776742</a>: Tagged as an upstream issue.</li>
<li><a href="http://bugs.debian.org/491793">#491793</a>: Marked as blocked by <a href="http://bugs.debian.org/481542">#481542</a>.</li>
</ul>
<p>Phew! Today I expect more of the same, starting with seeing where the new
information in <a href="http://bugs.debian.org/799122">#799122</a> takes me.</p>
Using Grub 2 as a bootloader for Xen PV guests on Debian Jessiehttp://www.hellion.org.uk/blog/posts/debian-pvgrub2/2015-01-18T09:23:35Z2015-01-18T09:23:35Z
<p>I recently wrote a blog post on using <a href="http://www.gnu.org/software/grub/">grub
2</a> as a Xen PV bootloader for
work. See <a href="https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/">Using Grub 2 as a bootloader for Xen PV
guests</a>
over on <a href="https://blog.xenproject.org">https://blog.xenproject.org</a>.</p>
<p>Rather than repeat the whole thing here I'll just briefly cover the
stuff which is of interest for Debian users (if you want all full background
and the stuff on building grub from source etc then see the original
post).</p>
<p>TL;DR: With Jessie, install <a href="http://packages.debian.org/grub%2Dxen%2Dhost">grub-xen-host</a> in your domain 0
and <a href="http://packages.debian.org/grub%2Dxen">grub-xen</a> in your PV guests then in your guest
configuration, depending on whether you want a 32- or 64-bit PV guest
write either:</p>
<pre><code>kernel = "/usr/lib/grub-xen/grub-i386-xen.bin"
</code></pre>
<p>or</p>
<pre><code>kernel = "/usr/lib/grub-xen/grub-x86_64-xen.bin"
</code></pre>
<p>(instead of <code>bootloader = ...</code> or other <code>kernel = ...</code>, also omit
<code>ramdisk = ...</code> and any command line related stuff (e.g. <code>root = ...</code>,
<code>extra = ...</code>, <code>cmdline = ...</code> ) and your guests will boot using Grub
2, much like on native.</p>
<p>In slightly more detail:</p>
<p>The forthcoming <a href="https://www.debian.org/">Debian</a> 8.0 (Jessie) release will contain support
for both host and guest <code>pvgrub2</code>. This was added in version
<code>2.02~beta2-17</code> of the package (bits were present before then, but
<code>-17</code> ties it all together).</p>
<p>The package <a href="https://packages.debian.org/grub-xen-host"><code>grub-xen-host</code></a> contains grub binaries
configured for the host, these will attempt to chainload an in-guest
grub image (following the <a href="http://xenbits.xen.org/docs/unstable/misc/x86-xenpv-bootloader.html">Xen x86 PV Bootloader Protocol</a>) and fall back to
searching for a grub.cfg in the guest filesystems. <code>grub-xen-host</code> is
<code>Recommended</code> by the Xen meta-packages in Debian or can be installed
by hand.</p>
<p>The package <a href="https://packages.debian.org/grub-xen-bin"><code>grub-xen-bin</code></a> contains the grub binaries
for both the <code>i386-xen</code> and <code>x86_64-xen</code> platforms, while the
<a href="https://packages.debian.org/grub-xen"><code>grub-xen</code></a> package integrates this into the running system
by providing the actual pvgrub2 image (i.e. running <code>grub-install</code> at
the appropriate times to create an image tailored to the system) and
integration with the kernel packages (i.e. running <code>update-grub</code> at
the right times), so it is the <code>grub-xen</code> which should be installed in
Debian guests.</p>
<p>At this time the <code>grub-xen</code> package is not installed in a guest
automatically so it will need to be done manually (something which
perhaps could be addressed for <a href="https://lists.debian.org/debian-devel-announce/2014/11/msg00005.html">Stretch</a>).</p>
Becoming A Debian Developerhttp://www.hellion.org.uk/blog/posts/becoming-a-debian-developer/2014-09-02T17:58:27Z2014-09-02T17:58:27Z
<p>After <a href="http://www.hellion.org.uk/blog/posts/becoming-a-debian-maintainer/">becoming a
DM</a>
at Debconf12 in Managua, Nicaragua and entering the NM queue during
Debconf13 in Vaumarcus, Switzerland I received the mail about 24 hours
too late to officially become a DD during Debconf14 in Portland,
USA. Nevertheless it was a very pleasant surprise to find the mail in
my INBOX this morning confirming that my account had been created and
that I was officially ijc@debian.org. Thanks to everyone who
helped/encouraged me along the way!</p>
<p>I don't imagine much will change in practice, I intend to remain
involved in the <a href="http://packages.debian.org/src%3Alinux">kernel</a> and <a href="http://packages.debian.org/src%3Adebian%2Dinstaller">Debian Installer</a> efforts as well as
continuing to contribute to the <a href="http://packages.debian.org/xen">Xen</a> packaging
and to maintain <a href="http://packages.debian.org/qcontrol">qcontrol</a> (both in Debian and upstream) and
<a href="http://packages.debian.org/sunxi%2Dtools">sunxi-tools</a>. I suppose I also still maintain <a href="http://packages.debian.org/ivtv%2Dutils">ivtv-utils</a> and <a href="http://packages.debian.org/xserver%2Dxorg%2Dvideo%2Divtv">xserver-xorg-video-ivtv</a> but they require
so little in the way of updates that I'm not sure they count.</p>
Debian 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/debian/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>
Heading to DebConf 13http://www.hellion.org.uk/blog/posts/heading-to-debconf13/2013-08-12T18:56:19Z2013-08-12T14:14:05Z
<p><a href="http://debconf13.debconf.org"><img src="http://media.debconf.org/dc13/artwork/dc13-btn0-going-sm.png" alt="Going to DebConf13!" title="" /></a></p>
<p>Seems like DebConf 13 is in full swing, I'm not heading over until
tomorrow because I spent the weekend at the <a href="http://www.bloodstock.uk.com/">Bloodstock
Festival</a>. As sad as I am to miss the
Cheese and Wine party tonight, having seen a dozen or so excellent
bands since Friday, lubricated by a few gallons of Hobgoblin, and
rounded off by Exodus, Anthrax & Slayer last night I think I made the
right call!</p>
<p>So I got home around lunchtime today, unpacked my rucksack, scrubbed
myself clean, repacked again for Switzerland (no tent this time). Next
up is a curry with my parents tonight and then catching the Eurostar
tomorrow morning, I'll have plenty of time for hacking on my
cubieboard2 on the train and finally arrive in Vaumarcus tomorrow
evening. See everyone soon!</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>
It Lives! Xen running on 64-bit ARMhttp://www.hellion.org.uk/blog/posts/it-lives-xen-on-aarch64/2012-11-28T12:41:06Z2012-11-28T12:37:35Z
<p>For the last few weeks I've been working on getting Xen running on
64-bit ARM (AArch64), using the Fast Models. This morning I finally
solved the last bug (a pretty dumb one as it turns out) and booted
domain 0 to a prompt! A screenshot is worth 1,000 words, although
you'll just have to trust me that this is running under Xen :-):</p>
<p><img src="http://www.hellion.org.uk/blog/posts/xen-on-arm64.png" alt="Xen on ARM64 Prompt" /></p>
<p>At the moment I'm using the same 32-bit dom0 kernel as we run on the
32-bit port of Xen, obviously we eventually want to support both 32-
and 64-bit guests. In fact we went to a fair bit of trouble with the
32-bit port to try and ensure that the hypercall ABI would be the same
for both and avoid the need for a compatibility layer (<a href="http://www.xen.org/xensummit/xs12na_talks/T3.html">Stefano's
talk</a> from
XenSummit in the summer has some details on that).</p>
<p>Combined with <a href="http://bugs.debian.org/599161">Debian bug #599161</a> finally being tracked down and fixed
upstream all in all this is shaping up to be a pretty good week!</p>
Consolidating Qcontrol Configuration Fileshttp://www.hellion.org.uk/blog/posts/consolidating-qcontrol-configuration-files/2012-11-21T20:59:30Z2012-11-21T20:59:30Z
<p>A little while ago Michele Cane filed <a href="http://bugs.debian.org/689912">Debian bug #689912</a> against
<a href="http://packages.debian.org/qcontrol">qcontrol</a> asking that the package install the correct
configuration file for a TS-419P II, a newer device which has an
LCD.</p>
<p>It turns out that to support devices with LCDs properly we need to
probe a GPIO line in order to figure out if an LCD is attached or if a
serial console is in use (since the two are mutually exclusive on this
hardware, when you attach a serial console you must toggle a jumper
too).</p>
<p>This actually turns out to be rather trivial since <code>qcontrol</code>'s
configuration files are actually simple <a href="http://www.lua.org/">Lua</a>
programs and the state of the GPIO lines can be accessed via sysfs and
so we can read the state directly from the configuration file itself.</p>
<p>While looking into this I happened to notice that the various
board-specific configuration files are actually very similar and that
the differences can all be detected by a combination of the <code>Hardware</code>
field in <code>/proc/cpuinfo</code> and the GPIO lines.</p>
<p>So I started looking into whether I could write a single consolidated
<code>qcontrol.conf</code> file to replace the various variant specific files. It
turns out to be quite possible, the resulting consolidated file has
been posted to the <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=125;filename=consolidated.lua;att=1;bug=689912">bug
log</a>
(see also my
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689912#125">mail</a>).</p>
<p>The danger with configuration files which are also
fully-fledged programming languages is that there is a temptation to
write more and more complex configuration files with the danger that
the primary purpose of the file (configuration) can be obscured. I
think in this case it is a close call but on balance I think the
downsides outweigh the advantages, so I've uploaded qcontrol
0.4.2+svn-r40-2 which simply adds LCD support to the relevant board
specific configuration file.</p>
<p>In process of doing so I seem to have fallen into a trap which seems
to catch out many <code>sbuild</code> users at least once and uploaded a package
with "UNRELEASED" still in the changelog. To try and save myself (and
others) some blushes in the future I've filed <a href="http://bugs.debian.org/693841">Debian bug #693841</a>
(wishlist) against <code>dput</code> to see if it can catch this case, I've also
added to my prerelease checklist.</p>
<p>As it happens my own TS-419P II arrived today. I intend to use it for
second tier storage (mythtv recordings, music, mirrors) as well as
light server duties (MTA, internal DNS etc) which should allow me to
turn off the existing PC in the cupboard under the stairs which is
getting a bit long in the tooth and starting to become a bit
unreliable (I also suspect its costing a fortune to run).</p>