Adopting FatdogArm for other systems

FatdogArm was built on Mele A1000 as the development platform (details here). Therefore, it will run on that platform; however it was not the only platform for which FatdogArm is intended to run.

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:

  1. a boot loader
  2. a kernel (and associated set of kernel modules)
  3. 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:

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):

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):

Examples of platforms on which FatdogArm will never run:

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:

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

FatdogArm architecture is based on Fatdog64:

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 uInitrd (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 in FirstBoot.

Modifying FatdogArm to boot on another target platform

Updated for building from FatdogArm meta-distribution, available from 1 October 2013 onwards (starting from alpha3 release). For the original instructions of customising FatdogArm from existing images, see old-style customisation.

To get FatdogArm to boot on another compatible platform, follow these 5 simple steps:

  1. Platform-specific boot loader
    You will need to have already known how to install the platform-specific bootloader.

  2. 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.

  3. 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:
  4. Create a new fd-arm.sfs image from FatdogArm meta-distribution
  5. Done !

Example: How to run FatdogArm in Qemu

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:

  1. Assuming you run this as root, on FatdogArm.
  2. Build your application as usual (get the source tarball, configure, etc). But don't install it yet.
  3. Instead of "make install" (or whatever the installation method the application use), do this:
     paco -lp "appname" "make install"
    
    (replace "appname" with your application name, can be anything (but dont' use spaces), and replace "make install" with whatever installation method your application suggests).
  4. Create a directory called /archive/repo and /archive/slack-desc
  5. Run paco2pkg desc "appname" where "appname" is the name you choose before
  6. Inspect /archive/repo/appname-desc and modify as needed. slackdesc tool is available to help you with that.
  7. 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.

Notes:

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 fd-arm.sfs - 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.

  1. Get the fd-arm.sfs from the disk image as explained previously.

  2. Extract the fd-arm.sfs by issuing this command.
    It will create a new directory called squashfs-root containing all the files inside fd-arm.sfs in the current directory.
     unsquashfs fd-arm.sfs
    

  3. Add/remove packages as needed.
    When you do this you must be inside the squashfs-root; thus the commands below is always preceeded by cd squashfs-root.

  4. Modify other files/scripts/configuration files as needed.

  5. Re-pack (re-generate) the sfs by issuing this command:
     mksquashfs squashfs-root fd-arm.sfs -comp xz -Xbcj arm -noappend
    

  6. Done.