:wc: relfile 00-WikiIndex ---3 Adopting ''FatdogArm'' for other systems %abs= ''FatdogArm'' was built on Mele A1000 as the development platform (details [[00-WikiIndex] 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'' [[ http://distro.ibiblio.org/fatdog/web/arm-index.html] 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. %= ---4 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) . ---4 ''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. ---4 ''FatdogArm'' architecture ''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.sfs== which 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 ==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. (: customising_fatdogarm :) ---4 Modifying ''FatdogArm'' to boot on another target platform %notice= 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 [[#oldstyle_customisation] old-style customisation]. %= 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. # Create a new fd-arm.sfs image from ''FatdogArm'' meta-distribution - Get the ''FatdogArm'' meta-distribution from [[http://www.ibiblio.org/fatdogscm/cgi-bin/fd-arm.cgi/index] here]. - Get familiar on how to use the build script by [[http://www.ibiblio.org/fatdogscm/cgi-bin/fd-arm.cgi/doc/tip/README.md] 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 ==fd-arm.sfs==. # Done ! . [[AdoptingFatdogArmForQemu] **Example**: How to run ''FatdogArm'' in Qemu] ---4 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: [[http://www.slackbook.org/html/package-management.html] here], [[http://www.slackwiki.com/Packages] here], and [[http://www.slackwiki.com/Building_A_Package] 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" ---= (replace "appname" with your application name, can be anything (but dont' use spaces), and replace "make install" with whatever installation method your application suggests). # Create a directory called ==/archive/repo== and ==/archive/slack-desc== # Run ==paco2pkg desc "appname"== where "appname" is the name you choose before # Inspect ==/archive/repo/appname-desc== and modify as needed. ==slackdesc== tool 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. . Notes: - If you don't want to clutter the currently working system, you can use [[+_blank http://distro.ibiblio.org/fatdog/web/faqs/sandbox.html] 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/xxx== will also work. . (: oldstyle_customisation :) ---4 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. # 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-root== containing all the files inside fd-arm.sfs in the current directory. ---== unsquashfs fd-arm.sfs ---= # 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==. - 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 ) ---= # Modify other files/scripts/configuration files as needed. # Re-pack (re-generate) the sfs by issuing this command: ---== mksquashfs squashfs-root fd-arm.sfs -comp xz -Xbcj arm -noappend ---= # Done. .