FatdogArm Beta1 Release Notes

FatdogArm Beta1 was released on 10 March 2014.

FatdogArm Linux is a small yet versatile operating system for ARM platform, targeted for desktop-style operations. It was originally conceived as a port from its bigger and more well-known Fatdog64 Linux: the Alpha version of FatdogArm (of which the latest version was Alpha4) is a direct port from Fatdog64, as documented here).

Introducing FatdogArm Beta

FatdogArm Beta is a second-generation release of FatdogArm. No longer a direct port, FatdogArm Beta is a complete rebuild of the operating system based LFS 7.4, done on FatdogArm Alpha.

Beta1 is the first public release of the new operating system.

Major features (compared to Alpha version):

Note: This is an early-release software. While we think that it is stable enough for end-users, it may still contain bugs and other rough edges. Exercise caution when using it and always back-up your important data.

FatdogArm features

Target system

FatdogArm Beta is built and tested on Odroid-U2; it is also tested on Odroid-U3, Mele A1000, A20/Cubieboard2, OLPC XO-1.75 laptop and XO-4 laptop.

But those are not the only platforms that FatdogArm can run; it can run on any other ARM platform as long as they meet at least these:

As long as these conditions are met, you can adopt FatdogArm to run on your favorite device. In fact, in addition to the above officially supported platforms, FatdogArm also runs on:

FatdogArm Distribution

FatdogArm Beta is distributed as a combination of a SquashFS file (fd-arm.sfs) which contains all of FatdogArm files in a single compressed file; and a few kernel package tarballs.

There are two SquashFS (shortened to "SFS") files; one (fd-arm.sfs) contains the basic operating system files. This file is often called as basesfs ("the base SFS"). There is another SFS file, called "devx" SFS (the actual name for beta1 is devx-beta1.sfs); this one contains all the software required for development (e.g. compilers, etc). You don't need devx SFS to run FatdogArm unless if you want build stuff yourself.

To install FatdogArm, get the basesfs (fd-arm.sfs) and the appropriate kernel package tarball for your platform, and then follow the platform-specific INSTALL instructions. You may also want to read the generic install instructions below.

For beta1, the following kernel packages are provided (officially supported):

Future releases may provide support for more platforms.

Alternatively, if you don't like the default package selection in the provided fd-arm.sfs, you can choose to build your own basesfs. Starting from alpha3, FatdogArm is also distributed as "meta-distribution".

The "meta-distribution" provides templates and build scripts, which will pull packages from FatdogArm repository, and build a new basesfs from scratch, based on package selection that you provide. You may want to build FatdogArm with full NLS information; or you may want to make a minimal console-only build for headless operation, etc: the choice is up to you.

(As a comparison, Puppy Linux also has a "meta-distribution", it is called Woof and is capable of building Puppy Linux images from many different upstream distributions - e.g. Ubuntu, Slackware, or its own PET packages.)

A few notes, though.

Note1: The "meta-distribution" script have only been tested on FatdogArm and Fatdog64. Though it should run on other systems too, you may need to tweak it first.

Note2: The "meta-distribution" build script will only make a new basesfs. It will not create a custom initrd or build a custom kernel or prepare a custom bootloader for you - you still need to do those steps if you plan to run FatdogArm in anything other than the official supported platforms. See: Running FatdogArm on another ARM platform.

Generic Installation Instructions

In general, to install FatdogArm you need to:

  1. Partition your SD Card correctly.
  2. Get the appropriate kernel package tarball, and extract its content to the first partition of the SD Card
  3. Get the `fd-arm.sfs` basesfs and copy that over to the first partition of the SD Card
  4. Install the boot-loader: this is platform-specific. It may involve dd-ing the boot-loader file into a specific location on your SD Card. The boot-loader is included in the kernel package.

And you're good to go.

Special notes for OLPC XOs:
To partition the SD Card:

  1. Get an SD Card which is at least 1GB in capacity (bigger is better).

  2. You can choose between one single partition or two partition layout.
    1. Single partition has the benefit of being accessible by that other Operating System which can only recognise a single partition in SD Card (you know which one).
    2. Two partition has the benefit that you can store your files in the second partition directly using "save directory" instead of "savefile".

  3. Fire up your partitioning software. In FatdogArm this would be fdisk, in Fatdog64 you can use fdisk, parted, or gparted. Please use MBR-style partition, do not attempt to use GPT or the likes unless you like trouble.

  4. One partition layout:
    1. Erase all partitions from your SD Card.
    2. Create a FAT32 partition as the first (and only) partition.
    3. The size of this FAT partition must be larger than 300MB, I recommend that you expand the partition to cover the entire SD Card.
    4. For A10/A20/Mele/Cubieboard2: the partition must start at least with 1MB offset (or 2048 sectors) from the beginning of the SD Card.
      For Odroid U2/U3: the partition must start at least with 5MB offset (or 10240 sectors) from the beginning of SD Card.
      You can save yourself from trouble and start it from 16MB from the beginning, this will cover both Odroid/Mele and other future variants.

  5. Two partition layout:
    1. Follow the one-partition instructions above, but do not expand the first partition to fill the entire SD Card; leave some space. In fact, use the minimum that is necessary to keep your basesfs and any other SFS you may use.
    2. Create the second partition. This can be of any types, but ext4 (with/without journal) is recommended.
    3. You can choose any size for the second partition, the larger the better.
    4. If you wish, you can create the 3rd, 4th partitions as well.

Saving sessions (Persistence)

When you shutdown for the first time, you will be asked on where to keep your changes. You can either choose "mmcblk0p1" - this is your first SD Card partition, or "mmcblk0p2" - your second SD Card partition, as the location to save to ("mmcblk0p2" will only be shown if you choose the two-partition layout). If you created ext2/3/4 partition, you can use "save directory" feature; otherwise you have to use the "savefile" feature (slower).

WARNING: For Mele/Cubieboard2: Don't use any of the "NAND" devices unless you know exactly what you're doing. The "NAND" devices are the internal storage of your Mele/Cubieboard2 and it contains Android OS and Data. Writing to them may make the Android unbootable, requiring re-flashing the Android (your FatdogArm however will continue to work).

NOTE: For XOs, "mmcblk0" devices are the internal NAND flash. If you use USB flash drive then it will be designated as "sda1" or "sda2". Make sure you choose the right device.

If you choose not to save, your changes in that session is discarded.

Enabling 3D GPU Acceleration

For OLPC XOs: the required drivers is already part of the basesfs. All you need to do is to turn it on. Please beware that turning on GPU acceleration can cause display corruption in some circumstances (this is a known problem and it also happens on OLPC's own official operating system).

To turn it on: edit /etc/X11/xorg.conf.d/20-gpudriver.conf and change Option "UseGPU" "false" to Option "UseGPU" "true".

For A10/A20/Mele/Cubieboard2:

  1. By default the system is configured to not reserve memory for the GPU. In this condition, if you try to enable GPU, the system will crash. To properly reserve memory for the GPU, edit uEnv.txt, locate the extras line, and remove the word sunxi_no_mali_mem_reserve. It is better if you also increase sunxi_fb_mem_reserve from 8 to 16. Please note by doing this you are allocating 64MB for Mali GPU, if you're on Cubieboard2 this may not seem like a big deal but for Mele which only has 512MB, it is. After you have done this, reboot.
  2. Install libmali (choose the sunxi version).
  3. Install xf86-video-fbturbo-mali.
  4. Reboot.
  5. You can test 3D acceleration using es2gears or glmark2.

For Odroid-U2/U3:

  1. Install libmali (choose the odroid version).
  2. Install xf86-video-fbturbo-mali.
  3. Reboot.
  4. You can test 3D acceleration using es2gears or glmark2.

Known quirks and problems

  1. A10/A20/Mele/Cubieboard2:
    The system is configured to display on HDMI by default. If you need to use another output, you will need an updated "script.bin" (a file that controls hardware configuration for Allwinner SoC devices). This "script.bin" is created from a text file called the FEX file, using a tool called fex compiler (fexc). One such tool is available here - this tool should work on any 32-bit/64-bit x86 Linux. You may want to check if there are pre-made fex file for your device here, if not, in addition to the Fex file guide above, you may want to read this for configuring your output.

  2. Xine sometimes crashes if you choose the wrong video driver. If you want to start Xine without playing anyfile, the safe bet is to use the XShm driver (it is pre-configured to do so; if you have already changed it you can always do it by starting it from terminal like this: xine -V xshm). On the other hand, XShm driver is slow. On A10/A20/Mele/Cubieboard2/XO-1.75 and XO-4 you may want to use the "xv" driver for better video playback (but the "xv" driver will crash Xine if you start it without a file - annoying, I know).

  3. On anything other than the XOs, the default Xorg video driver is fbturbo (formerly sunxifb). On A10/A20 this driver supports 2D acceleration using G2D. On other platforms it is simply a "faster fbdev". The XOs uses dovefb (generic Marvell framebuffer driver) instead. The generic fbdev is included for fallback purposes and should work for all platforms (just remember that in Odroid the framebuffer is located at /dev/fb1 instead).

  4. 3D GPU acceleration is not enabled by default. On XOs this is done because GPU acceleration can corrupt screen when accessing certain websites. Please read notes above on how to enable 3D acceleration.

  5. A10/A20/Mele/Cubieboard:
    There is no video playback acceleration (Cedar VPU). Work on this is in progress by the fine people in linux-sunxi. Help them if you can.

  6. Except on OLPC XO-4, there is no Flash Player. Adobe no longer distributes a standalone Flash Player for generic ARM devices; no doubt because to get a decent performance Flash must be compiled with platform-specific optimisation e.g. Cedar VPU or 3D GPU etc so releasing a generic but poor-performing Flash player does not help Adobe's brand.

Generic Q & A

Q: Where is the documentation for FatdogArm?
A: None exist yet, but you can use this as a reference. Most of it are applicable (major exceptions: FatdogArm doesn't use humongous initrd, FatdogArm uses Slackware's pkgtool TBZ format instead of PET packages, installation procedures, etc).

Q: There are so many references to Fatdog64 both in window titles, messages, etc.
A: Yes, that's because FatdogArm is a port of Fatdog64 and uses many Fatdog64 tools. This will change overtime but don't expect it to happen soon.

Q: Is FatdogArm for 64-bit ARM archictecture (ARMv8) then?
A: No. It is currently built for 32-bit ARMv7 architecture.

Q: Is it softfloat or hardfloat?
A: Hardfloat, with VFPv3-d16 FPU and Cortex-A8 optimisations. No NEON.

Q: Will FatdogArm work on my tablets, settop boxes, devboards, etc?
A: While I have managed to get FatdogArm to run a particular tablet, do not expect this to be the norm. The reason is simple: every ARM device is different. But you may want to adopt FatdogArm to run on your favorite device :)

Q: Do I really need devx.sfs? I don't need one for Alpha4.
A: Yes, you need one for Beta. I have split the development packages from the main basesfs to make it smaller; so if you want to compile stuff you need to get devx.sfs.

Q: Is there any hardware acceleration (3D, VPU, etc) ?
A: Yes, 3D acceleration is available in all supported platforms, but they are not enabled by default. VPU is not supported yet (no support from upstream project).

Q: I don't want to boot to graphical desktop, I want to boot to console only.
A: Open uEnv.txt on the first FAT partition of your SD Card, then add "pfix=nox" to the end of the line that starts with "extras". For the XO, open boot/olpc.fth and append "pfix=nox" to the line commented with "set kernel command line".

Q: I have a savefile but temporarily don't want to use it
A: Open uEnv.txt on the first FAT partition of your SD Card, then add the a new line that says savefile=savefile=none. For the XO, do the same to boot/olpc.fth.

Q: I want to save my session but I don't want to create a second partition, because some stupid operating system doesn't recognise SD Cards with more than one partition.
A: Sure, you can save your session on the first FAT partition too. But make sure you you have a large enough partition, in fact, why not size the partition to fit the entire SD Card.

Q: This uEnv.txt editing business is so unlike editing syslinux.cfg or grub.lst. Can't you use syslinux or Grub or Grub2 instead?
A: Unfortunately, no. Those bootloaders are for x86 (and x86_64) only. In the ARM world the common bootloader is das U-boot, which is a versatile bootloader which matches or exceeds syslinux and Grub in terms of capability; however unless you have serial terminal connected to the platform, you have very little chance to interact with it.

To that point, I have created a simple boot manager called "BootMenu", which reads a syslinux-like configuration file and provides a user-friendly menu interface for selecting different boot configurations. A sample bootmenu.cfg is provided on the image; documentation here.

Note that booting with BootMenu depends on your kernel/platform support. Some kernel/platform simply will not work with it, for example Cubieboard2. (You will see the menu, you can choose the items, but the actual boot process after that will fail). This is a known problem and is a kernel issue, there isn't much that we can do about it until the kernel is fixed by upstream.

Q: I have a question not listed here.
A: Drop me a message on my blog or on the Puppy Linux Forum. FatdogArm threads are usually located in "Puppy Projects" section.

Notes and Credits

OLPC XO support for FatdogArm was original work done by mavrothal from Puppy Linux forum from his original XO-pup work.

In previous Alphas, FatdogArm for OLPC was as separate build of FatdogArm with modifications to support XO-specific functions: touch (XO-4 only), screen rotation, gamekeys, video camera, wifi and power management.

In Beta release, I have collected mavrothal's work and merge them into the main FatdogArm build so that they can be supported directly within FatdogArm release; but there is no doubt that the hard work came from and acknowledgement must go to mavrothal.

Further Links for OLPC XO support and about XO-pup:

I'd also like to thank 01micko who helped with testing and contributed packages.

Previous release notes: alpha4 alpha3 alpha2 alpha

(Note: Only alpha4 binaries are still available; the rest have been removed).