[Aboriginal] Using filesystem images on real hardware

Rob Landley rob at landley.net
Mon Jul 11 06:51:49 PDT 2011

On 07/10/2011 02:15 AM, Matthew J Fletcher wrote:
> Hi,
> I've built various filesystem images (armv6l,i486) and run them in qemu
> using the aboriginal build machinery just fine.


> Presuming a given specific target board has linux port, e.g Chumby or
> PandaBoard, i guess i just have to create a new target (settings file),

All Aboriginal Linux needs is a new settings file, yes.

What your _target_ is going to need is:

1) binutils+gcc support.

2) libc support (either in uClibc, or you'll need a sources/sections
script to build glibc and changes to simple-cross-compiler.sh and
native-compiler.sh to "build_section glibc" instead of "build_section
uClibc".  Note that glibc requires perl as a build prerequisite, which
is why I added HOST_EXTRA, which is described in the top level "config"

3) linux support.

If your target is already supported by those four software packages,
you're good.  If it isn't, and you need to supply alternate versions of
binutils/gcc/uClibc/linux.  (There's
USE_UNSTABLE=uClibc,gcc-core,binutils infrastructure for this, but I
really need to update the documentation.  Lemme know if you need to do
that and I'll add a FAQ entry...)

> make sure the gcc parameters are correct for soft/hard float and get a
> kernel config file for settings like the following;

Kernel config and uClibc config.  Plus you need to set KARCH to what the
kernel needs ARCH= set to, and so on.


I recently started to automate this, but it's still a bit ugly:

1) Put together your .config file like you want it.
2) run miniconfig.sh on it as described in the FAQ:
3) Use sources/toys/filter.py with the appropriate baseconfig as your
first argument and your new miniconfig as the second.  It'll spit out
all the symbols in the second which weren't in the first.

Then go through it and figure out what you actually _need_...

> # Versatile board

Assuming your new thing is based on a versatile board, sure.

> how did you find that just these config options need to be set, looking
> at most linux kernel config files there are about 4000 lines in it.

The FAQ explains miniconfig.  Since even most of the miniconfig options
were common between boards I split out the common options into
"baseconfig" and the CONFIG_LINUX stuff gets appended to that, then fed
into the kernel.

> I guess most of those are defaults, do you just diff a default config file
> against a board specific one and see whats different ? then make semi
> intelligent guesses about if those changes are actually target specific
> or just the personal preference of the guy who created the kernel config
> for that board ?

I work out the config I want, which is generally pretty minimal.  Start
with allnoconfig and switch on what you need.  Record what you switched
on.  That's miniconfig.  (The miniconfig.sh script just boils down an
existing config into a miniconfig by removing everything that's at the
allnoconfig default value or which the dependencies would set for you if
you switch on the other symbols.  I need to patch the kconfig C code to
do this for me, the way I'm doing it now is really slow and works it out
experimentally by removing each line and seeing which ones change there
result and which ones don't.)

Having done a bunch of boards, there's some commmon infrastructure like
ext3 that they're all going to need, that's pretty much baseconfig.  I
got that by looking at the dozen or so miniconfigs I had at the time and
factoring out the common symbols.  It's really "what a kernel needs to
run an aboriginal linux system image under qemu".  A real hardware board
running jffs2 or something would need totally different symbols.



More information about the Aboriginal mailing list