Adopting FatdogArm for other systems
This article explains how FatdogArm can be made to run on other compatible platforms. Of course, this article only make sense if you want to re-use the binary built FatdogArm here. If you followed my previous articles and built your own; your build is already optimised for the platform of your choosing and there is no need to "adapt" or "adopt" anything.
First things first
What does it mean compatible?
Like all Linux operating systems, FatdogArm contains three components:
- a boot loader
- a kernel (and associated set of kernel modules)
- userspace programs
When we talk about "compatibility" on ARM platform, it can only be for the third component (the userspace programs). The bootloader and the kernel are almost always specific to the platforms (with very rare exceptions - if the platforms runs the same SoC is a very similar board configuration - so rare that for practical purposes we can forget about it).
The compatibility of userspace programs depends on the hardware features that were used when building the userspace programs.
For FatdogArm, the pertinent architecture features that was used during built-time is:
- ARMv7 instruction set (optimised for Cortex-A8, but will run on anything ARMv7)
- VFPv3 FPU. Not VFPv3d16 - it has to be the full VFPv3 (VFPv3-d32). VFPv4 should work, too.
- NEON SIMD instructions (for some of the codec libraries).
Which means if the target platform have similar hardware features; then FatdogArm userspace will most likely run on it. Examples of some other SoC / platform what FatdogArm can potentially (because I haven't tested it):
- Cubieboard (identical SoC - Allwinner A10)
- Cubieboard2 (Allwinwer A20 SoC, same set of features)
- Mele M5 (Allwinner A20 SoC, same set of features)
- XO-4 (Marvell PXA2128 SoC - same set of features, confirmed to run)
- BeagleBone Black (TI AM335x SoC, same set of features)
- Odroid (Exynos SoC, same set of features)
- The upcoming Cubox-i (Freescale i.MX6 SoC, same set of features)
Examples of some other SoC / platforms that FatdogArm cannot run (but can be potentially made to run later on if the libraries are re-compiled for VFPv3-d16):
- XO-1.75 (Marvell Armada 610 SoC - will not run as it only has VFPv3-d16 instead of the full VFPv3)
- The original Cubox (Marvell Armada 510 SoC, - will not run as it only has VFPv3-d16)
Examples of platforms on which FatdogArm will never run:
- Raspberry Pi (ARMv6 architecture, does not support ARMv7)
FatdogArm target segment
Determining the target platform hardware features is one thing; it is another thing to also determine platform's capacity. Here, it is important to bear in mind that FatdogArm's target is desktop-style operations; thus it will require a desktop-class machine to run on.
The "desktop-class" machine means something like this:
- Memory: 512MB RAM or more
- CPU: 1GHz single-core CPU (or better, in terms of speed and number of cores)
- Keyboard and mouse attached (bluetooth devices aren't supported yet)
It is of course possible to trim down FatdogArm to its bare essentials which enables it to run on a much-less endowed system (e.g specialised appliance etc); or to run it as a tablet operating system without keyboard and mice; but that would be beyond the scope of this article.
FatdogArm architecture is based on Fatdog64:
- Boot-loader agnostic.
- Linux kernel can be placed anywhere (not only on /boot) as long as it can be loaded by the bootloader.
- Requires an initramfs; this initramfs (named
initrd) can be placed anywhere as long as it can be loaded by the boot loader.
- All kernel modules and kernel-specific programs stored in
Squashed Filesystem (SFS) named
kernel-modules.sfswhich lives inside initrd.
- all userspace programs are stored in a Squashed Filesystem named
fd-arm.sfs, which can be anywhere as long as the device it is on is accessible by the Linux kernel.
The default image provided is an disk image file containing a single FAT32 partition that contains all the above files. This partition starts at 1MB boundary, thus it is accessible by loop-mounting it like this:
mount -o loop,offset=1048576,ro fatdog-arm-alpha.img /mnt/data
The kernel is named
uImage (it is a zImage prepended by 64-byte u-boot
header), and the initrd (actually initramfs) is named
(it is a normal initrd prepended by 64-byte u-boot header).
You can convert the uInitrd into a normal initramfs (which you can extract
using cpio) by doing this:
dd if=uInitrd of=initrd bs=64 skip=1
And you can convert it back to uInitrd by using
mkimage tools described
Modifying FatdogArm to boot on another target platform
To get FatdogArm to boot on another compatible platform, follow these 5 simple steps:
- Platform-specific boot loader
You will need to have already known how to install the platform-specific bootloader.
- Platform-specific kernel
Build one for your platform. Whether you go with uImage, or zImage, or bzImage, or any other format, really depends on the format required by your boot loader.
- Platform-specific kernel modules
Build the kernel-modules.sfs as described in FatdogInitrd. There is a prepared initrd from FatdogArm meta-distribution, all you need to do is:
- open it,
- replace the kernel-modules.sfs with yours,
- repack it.
- Get the FatdogArm meta-distribution from here.
- Get familiar on how to use the build script by reading this.
- Make your own custom packages (additional packages from the repository, the packages that you compile yourself, or packages that contain scripts to further modify other settings).
- Prepare your own package list (samples are provided) and include your custom packages in this list
- Run the build script to generate the new
Making your own FatdogArm packages
FatdogArm uses Slackware package format (tgz/tbz/txz although tbz is the one I use for the repository - it's a compromise between size and speed); so it is good to read some background material: here, here, and here.
To make a new TBZ package from inside FatdogArm (i.e, native compilation, not cross-compilation), do the following:
- Assuming you run this as root, on FatdogArm.
- Build your application as usual (get the source tarball, configure, etc). But don't install it yet.
- Instead of "make install" (or whatever the installation method the
application use), do this:
paco -lp "appname" "make install"
- Create a directory called
paco2pkg desc "appname"where "appname" is the name you choose before
/archive/repo/appname-descand modify as needed.
slackdesctool is available to help you with that.
- When done, run
paco2pkg pkg "appname". It will create the TBZ package in
/archive/repo, and it will also record your package as installed in the system.
- If you don't want to clutter the currently working system, you can use Fatdog Sandbox for the entire process and only copy the final TBZ package out of the sandbox when you're done.
- For more information about paco see http://paco.sourceforge.net
- Of course, if you know how to do it, using Slackware
makepkg(as indicated in the references previously) with combination of something like
make install DESTDIR=/tmp/xxxwill also work.
Customising FatdogArm (the old way)
The old way of customising/adopting FatdogArm is similar to the above:
one would still need to prepare a bootloader, a kernel, a kernel modules, and
modify the initrd. The only difference is on how to prepare
instead of building fd-arm.sfs from scratch using FatdogArm's
meta-distribution, one uses and modifies an existing fd-arm.sfs from an
existing FatdogArm image.
- Get the fd-arm.sfs from the disk image as explained previously.
- Extract the fd-arm.sfs by issuing this command.
It will create a new directory called
squashfs-rootcontaining all the files inside fd-arm.sfs in the current directory.
- Add/remove packages as needed.
When you do this you must be inside the squashfs-root; thus the commands below is always preceeded by
- Adding a package:
( cd squashfs-root; ROOT=$(pwd) sbin/installpkg /path/to/your/package.tbz )
- Remove package:
( cd squashfs-root; ROOT=$(pwd) sbin/removepkg name-of-package-to-remove )
mksquashfs squashfs-root fd-arm.sfs -comp xz -Xbcj arm -noappend