FatdogArm Alpha4 Release Notes
FatdogArm Alpha4 was released on 29 October 2013.
Fatdogarm Alpha4 for Odroid-U2 was released on 31 December 2013.
Odroid-U2 instruction fixed on 1 Feb 2014.
FatdogArm is a port of Fatdog64 to the ARM platform (the original porting process is documented here), targeted for desktop-style operation.
This is the fourth public release of FatdogArm, and it supersedes and obsoletes previous alpha releases (alpha, alpha2 and alpha3).
This is a minor bugfix release:
- Regression on missing SendTo links (they were removed in alpha2 and came back in alpha3)
- Fix over RAM layer operation (RAM layer was not reliable due to missing "lsof" binary)
- Changes of distribution methods - it is now distributed as two-part archive (SFS and kernel package) instead of one disk-image.
- Support for Cubieboard2 (A20 SoC) and mk802ii (A10 SoC)
Note: This is an alpha-quality software release, so it is not meant for general end-user consumptions. Instead it is released "as is" for testers and tinkerers who may find the software useful, or for porting to another devices.
WARNING: ALPHA-QUALITY SOFTWARE: READ EVERYTHING IN THIS DOCUMENT IN FULL FIRST BEFORE ATTEMPTING TO BOOT.
- All of Fatdog64 versatile boot options except LVM and encrypted savefile.
- Complete desktop for day-to-day usage:
- Web browser: Seamonkey
- Email client: Seamonkey Mail
- Calendar and PIM: Seamonkey Mail
- Secure Email client: Sylpheed (gpg-enabled)
- Word processor: Abiword
- Spreadsheet: Gnumeric
- PDF Viewer: Evince
- Image editor: mtpaint
- Image viewer: Viewnior
- Media player: Xine
- Printing system: CUPS with Ghostscript and Gutenprint drivers
- Remote connection: VNC, SSH (both server and clients included)
- IDE / Text Editor: Geany
- HTML Editor: Seamonkey composer
- Development tools (headers, libraries, gcc compiler, make, binutils)
- Full version of the utilities (core-utils, util-linux, findutils, diffutils, etc)
- More packages from its own repository (still small at the moment, but growing).
- Small (less than 300MB)
FatdogArm was originally built and tested on Mele A1000 device. The only important consequence of this are:
- FatdogArm requires:
- CPU supporting ARMv7-A instruction architecture (binaries are optimised for Cortex-A8)
- VFPv3 FPU (the full VFPv3 aka VFPv3-d32)
- NEON SIMD support
- 512MB RAM recommended although it will run with 256MB RAM
- FatdogArm's glibc supports kernel features up to 2.6.25
- FatdogArm's glibc was originally built with 3.0 kernel headers
- Qemu, see the instructions here.
- OLPC XO-4, maintained by mavrothal, releases here.
- OLPC XO-1.75, early porting efforts (stalled, no releases yet, support planned in beta release).
- Pandora, adapted by 01micko, work in progress - no releases/instructions yet.
- A13-based tablet, early porting efforts (stalled, no releases yet).
- A20 (Cubieboard2) - from alpha4 onwards.
- Odroid-U2 (Exynos4412) - from alpha4 onwards.
Earlier releases of FatdogArm were done as images (specifically, images for Mele A1000). But, recognising the diversity of ARM platforms, and reflecting on the collaboration between myself and mavrothal on adopting FatdogArm for OLPC XO-4 laptop, starting from alpha3 FatdogArm is now released as a "meta-distribution".
The "meta-distribution" provides templates and build scripts, which will pull packages from FatdogArm repository, and build a new basesfs (fd-arm.sfs) from scratch. The "meta-distribution" is a fossil repository located here.
Currently the build script will only make a new basesfs. It will not create a custom initrd or build a custom kernel or prepare a bootloader for you - the steps that you will still need to do to make FatdogArm run on another ARM platform.
(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.)
But for those that don't want or can't build a FatdogArm yourself, that's okay too - we have another distribution: FatdogArm pre-built SFS and kernel packages. All you need to do is get the FatdogArm SFS and the appropriate kernel package for your device, and then follow the INSTALL instructions for your kernel platform.
For alpha4, the following kernel packages are provided:
- A10 SoC (for Mele A1000 and similar)
- A10 SoC (for MK802ii and similar)
- A20 SoC (for Cubieboard2)
- OLPC XO-4 (bundled SFS + kernel packages)
- Odroid-U2 (Exynos4412 - separate SFS + kernel packages)
Future releases may provide support for more platforms. Please read-on for platform specific notes.
Note: starting from alpha4, FatdogArm is no longer distributed as disk image.
Unlike many other distributions out there, which provide compressed disk images which needs to be expanded and then written to a specific-sized SD Card, FatdogArm is provided in two parts - the common SFS file, and platform/device-specific kernel packages.
To install FatdogArm, please follow these easy steps:
- Download fd-arm.sfs from http://distro.ibiblio.org/fatdog/arm/releases/alpha4/ Also download your kernel package.
- Get yourself a decent-sized SD Card (anything 1GB or bigger is good)
- Choose one-partition layout or two-partition layout below, as needed. Use your favorite partition editor to do this; gparted is recommended. You can skip this step if your partition layout is already correct.
- One-partition layout:
- Erase all partitions from your SD Card.
- Create a FAT partition as the first (and only) partition.
- The size of this FAT partition must be larger than 300MB, I recommend that you expand the partition to cover the entire SD Card.
- This partition must start at least with 1MB offset (or 2048 sectors) from the beginning of the SD Card.
- Two-partition layout:
- Erase all partitions from your SD Card.
- Create a FAT partition as the first partition.
- The size of this FAT partition must be larger than 300MB.
- This first partition must start at least with 1MB offset (or 2048 sectors) from the beginning of the SD Card.
- Create the second partition. This can be of any types, but ext4 is recommended.
- You can choose any size for the second partition, the larger the better.
- If you wish, you can create the 3rd, 4th partitions as well (although it doesn't make a lot of sense).
- Extract the kernel-package tarball to the first partition of the SD Card. Also copy fd-arm.sfs to the first partition of the SD Card.
- Install the bootloader to the SD Card like this:
dd if=uboot-xxx.bin of=/dev/your-sdcard-device bs=1024 seek=8. Be extra careful with your "/dev/your-sd-card-device", wrong path can irrevocably destroy your harddisk.
- Delete the uboot-xxx.bin from your SD Card, it is not needed anymore.
- Done! The SD Card is now bootable and will boot directly to graphical desktop in about 15-30 seconds (depending on the speed of your SD Card).
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: Don't use any of the "NAND" devices unless you know exactly what you're doing - these are the internal storage of your Mele and it contains Android OS and Data. Writing to them may make the Android unbootable, requiring Android re-flashing (your FatdogArm however will continue to work).
If you choose not to save, your changes in that session is discarded.
Known quirks and problems
- The system is configured to display on HDMI by default. If you 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.
- Encrypted savefile is not supported yet, so do not attempt to enable encrypted savefile in the session shutdown dialog.
- Xine sometimes crash if you choose the wrong video driver. If you want to start Xine without playing anyfile, you need to use the SDL driver (start it from terminal like this:
xine -V sdl). On the other hand, the SDL driver isn't so good when you want to play full screen (it will crash), so you will need to use "xv" or "xshm" driver to do that (set this from inside Xine's preference dialog). Yeah, annoying, I know.
- The sunxifb driver supports G2D acceleration (2D acceleration) but that's all about it. There is no 3D acceleration (Mali GPU) or video acceleration (Cedar VPU) so the most you can play is SD video upscaled to 720p; anything else will stutter.
- By default none of the memory is reserved for Mali an VPU so don't try to enable them (loading the module); this is done to maximise the available memory for applications. If you want to try them, make sure you edit uEnv.txt on the first FAT partition and modify the "extras" line to tell the kernel to do memory reservation.
OLPC XO-4 specific notes
All functions of the laptop are supported including touch, screen rotation, gamekeys, video camera and power management.
At 300MB this build is a full development environment to build any applications that are not in the FatdogArm package repository yet.
To run fd-arm_XO-4:
- download the fd-arm_xo4_1.1.tar.gz file from ibiblio or one if its (faster) mirrors
- then extract the tarball at the root of any USB (thumb) drive or SDcard, then connect/insert it to your XO-4 and power up.
- Visiting specific pages may result in web page and desktop image corruption. This is a problem of the dove video driver exposed by the mozzila/firefox browsers (also present in OLPC builds). A solution is to set Option "UseGPU" to "false" in xorg.conf. However this will result in decreased video performance and inability to use Adobe Flash.
- Network wizard may fail to save the settings the first time is run. To solve this problem just run the network wizard again.
Odroid-U2 specific notes
Odroid-U2 requires its kernel package as well as its own SFS, fd-arm-u2.sfs (which needs to be renamed to fd-arm.sfs before use). It can use the original fd-arm.sfs but requires some modifications (disabling of 02-cpuspeed and change of framebuffer device to /dev/fb1 for Xorg) which has been done for convenience in its SFS package.
Installation is very similar to A10/A20 devices, in fact, follow the guide for A10/A20 except that:
- You need to write the bootloader like this:
dd if=uboot-u2.bin of=/dev/your-sdcard-device seek=1(Note
seek=1here, instead of
seek=8for A10/A20, and there is no need for
- The first partition must start with at least 5MB offset (16 MB recommended); contrast this with A10/A20 which requires only 1MB offset.
- Remember to use fd-arm-u2.sfs instead of the standard fd-arm.sfs; and rename it to fd-arm.sfs before use.
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,
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-d32 FPU, Neon and Cortex-A8 optimisations.
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: Where is the devx.sfs?
A: There is no devx. The image contains gcc compiler (C and C++), binutils, make, and all the library headers - thus you can compile applications straight away. The static libraries have been removed to reduce the size, though. If you want them you need to re-install the packages from the repository. Also, if you need autoconf, automake, m4, cmake, flex and bison, they are available on the repository. Git, svn and fossil are also available in the repository.
Q: Is there any hardware acceleration (3D, VPU, etc) ?
A: Planned to, but not yet. Acceleration is very device specific, but FatdogArm is meant to be general; so any device-specific hardware acceleration will only be made available through repository and/or platform-specific releases.
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 XO-4 image, 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 XO-4 image, 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.