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.
What does it mean compatible?
Like all Linux operating systems, FatdogArm contains three components:
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:
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 is based on Fatdog64:
initrd
) can be placed
anywhere as long as it can be loaded by the boot loader.
kernel-modules.sfs
which lives
inside initrd.
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 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.
To get FatdogArm to boot on another compatible platform, follow these 5 simple steps:
fd-arm.sfs
.
Example: How to run FatdogArm in Qemu
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:
paco -lp "appname" "make install"
/archive/repo
and /archive/slack-desc
paco2pkg desc "appname"
where "appname" is the name you choose
before
/archive/repo/appname-desc
and modify as needed.
slackdesc
tool is available to help you with that.
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:
makepkg
(as
indicated in the references previously) with combination of something
like make install DESTDIR=/tmp/xxx
will also work.
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.
squashfs-root
containing all
the files inside fd-arm.sfs in the current directory.
unsquashfs fd-arm.sfs
cd squashfs-root
.
( cd squashfs-root; ROOT=$(pwd) sbin/installpkg /path/to/your/package.tbz )
( cd squashfs-root; ROOT=$(pwd) sbin/removepkg name-of-package-to-remove )
mksquashfs squashfs-root fd-arm.sfs -comp xz -Xbcj arm -noappend