On 07/01/16 07:42, Tristan Van Berkom wrote:
Baserock under QEMU
I tried to boot the build system for the armv7lhf arch using qemu
and futzing around with the genivi-initial-setup scripts by
mounting the built image and extracting it's kernel, but did not have
much luck with that, it would seem those scripts are also severely
out of date and expect one to be running an (old) ubuntu system.
There is probably a correct voodoo encantation of qemu-system-arm to
boot this image, but I gave up before finding out what it is.
The sad thing about the latter two approaches is that we would need an
image for a given arch to build an image for that arch, but there is
not much in the way of a build story to support a new arch and build
one of these images from scratch the first time around.
This means that if we want to build on a given board, we depend on
third parties to build an environment with a complete enough stack to
run ybd first.
Actually, we did a big chunk of work on this two years ago, and it
should definitely be possible to cross-build a minimal Baserock
toolchain + Busybox rootfs that can then be used to native-build a full
Baserock system for the new architecture.
People have created Baserock systems for ARM big-endian, MIPS and ARM64
using this method.
The current implementation involves the `morph cross-bootstrap` command
and is documented here:
The basic process is: cross-build the 'bootstrap' mode chunks for the
system you want to cross-bootstrap, to produce a minimal rootfs that can
be run in a chroot, or booted on a device given a suitable kernel (with
init=/bin/sh). The other chunks are exported from the build tool as
source tarballs + shell scripts, with an overall shell script that
builds everything in the correct order. You can then run this script in
the minimal rootfs, go to bed, and in the morning you hopefully have a
system that can run Morph and YBD, which you can then use to do a
normal, clean build of the same system.
(You probably need to go to bed twice if building on MIPS; that's the
big downside of native build that we always suffer with).
That's the cross-bootstrap process.
The `morph cross-bootstrap` stuff could all be reimplemented in other
build tools, there no "magic" in there.
I was going to explain how this is similar to Aboriginal Linux, but then
I read on and spotted that you already did that :-) I will leave what I
wrote about the existing Baserock cross-bootstrap process though because
I think it's important to know about that when deciding what to use ...
On to the juice
Currently I am building an extended toolchain in an armv5l Aboriginal
Linux emulator as a proof of concept, theoretically I just need to
build everything that ybd requires to build the build-essential stratum
and once that is passed the build should truck along (slowly) and
eventually complete. The only stumbling blocks would be some modules
which require special treatment to be built on a given arch.
If this is successful, which I don't see why it should not be, I am
considering Aboriginal Linux as a viable bootstrapping platform for
building systems with Baserock.
Makes sense to me.
So, assuming this plan is a success, this is what I think would be
involved in getting a thoroughly repeatable and documented
bootstrapping process for building Baserock for a given arch:
o Create our own Aboriginal Linux derived platform with an extended
toolchain, just enough to run ybd and get passed build-essential.
This probably means building the bootstrap image using tarballs at
least at first, possibly a repository of them sitting on the trove.
This repository should be able to bootstrap itself into all of the
arches supported by Aboriginal Linux.
It will also serve as documentation about definitions, i.e. it can
be deduced that everything that is built in the bootstrap image, is
in fact a requirement for building Baserock, it is the missing
I don't quite follow how this would work. I probably won't until you
actually start doing it and I can see what it means in practice :-)
o Since we are already building a cross compiler for the bootstrap
image to compile with, it would make sense to drop our
[cross]compiler from the build-essential stratum, this way we can
run ybd on definitions but still use the aboriginal distcc "trick",
allowing us to build full systems for embedded targets at
I've been thinking that it would be nice to drop our build-essential
stratum and replace it with something like crosstool-ng, Buildroot or
Aboriginal. There's a lot of effort involved in maintaining toolchains
for many different platforms, and it would be nice to collaborate on it.
I've been following Aboriginal development for a while and there seems
to be very little movement recently as Rob is busy with other stuff. I
worry that if we want to make big changes, we might end up with loads of
patches waiting for review for a long time, and end up effectively
forking it. Which would kind of miss the point of collaboration.
I also dislike how the whole Aboriginal build system is a bunch of shell
scripts, but I can live with it.
o Drop host dependencies from build extensions
There is no reason to require tools such as mkfs.btrfs from the
host, and indeed, as was outlined in this bug report, we need to
By 'build extensions', do you mean 'deployment extensions' ?
I actually would quite like to drop deployment too, or at least treat it
separately from building. The output of the build process is a
filesystem tree and always will be, regardless of the exact packing and
transport methods we use. The input to a deployment process will always
be a filesystem tree, too.
I say this because I think it's quite a lot of work to 'drop' such
dependencies from the deployment extensions: they still have to come
from somewhere. I would welcome tool that worked on all systems in a
reproducible way, but I don't know if it's immediately achievable.
There are some concerns about maintaining cross-deployment
capabilities in the build extensions which I admit I don't
completely understand (how can you cross-deploy if you are not
cross-building in the first place ?). In any case this should be
dropped as it would become non-essential to the mission and as
such; only add to the overall maintenance burden of Baserock.
If we got rid of our 'one deployment tool to rule them all' assumption,
this would hopefully be a no brainer.
There are workflows that would break if deployment tools totally
disallowed 'cross deployment', for example the 'SDK' system is an x86_64
cross-toolchain system that embeds an armv7l (or whatever) rootfs as the
sysroot. No transformation of the sysroot is required, but through the
lens of our current tooling, that would viewed as 'cross deployment'.
Sam Thursfield, Codethink Ltd.
Office telephone: +44 161 236 5575