Fatdog Arm Page

This page documents my experiments on porting Fatdog64 (originally on x86_64) architecture to ARM architecture. It is a work-in-progress.

Progress

  1. Getting it to boot
  2. Booting it with initrd
  3. Building the native compiler
  4. Building the applications
  5. Maintaining software packages
  6. Progress roadmap
  7. Extra: Preparing the ARM toolchain yourself
  8. Extra: Getting the most of your device
  9. Extra: Touchscreen input
  10. Extra: Adopting FatdogArm for other systems
  11. Extra: Running FatdogArm in Qemu
  12. Extra: FatdogArm and Fatdog64 - Compiling together

See also BootMenu for ARM platform.

My development environment

The development environment is a Mele A1000 with the following specifications:

SoC Allwinner A10
CPU type ARMv7 Cortex-A8 1Ghz
RAM 512MB
On-board storage 4GB Nand Flash
Interfaces HDMI
VGA
Component Video
Fast Ethernet
Wifi 802.11g
SATA
SD Card
USB 2.0

Coupled with a low-cost HDMI TV, a few low-capacity SD Cards (1 GB), and and old 40GB USB 2.0 harddisk. The NAND flash it not used; thus the original Android OS is preserved and can still be used at a later time.

The host system used for cross-compiling etc is Fatdog64 622 (x86_64 system). 32-bit SFS is required as some of the tools only run on 32-bit platform, as well as the devx package.

Why Mele is an ideal development platform for me:

References

http://linux-sunxi.org/

FAQ

Question : Will this work on my Rasberry Pi / BeagleBone / Cubieboard / etc, etc?

Answer : Most probably not. It may work with Cubieboard if it uses the same SoC as my dev system (A10) by changing the script.bin, but for others it will not. Others uses complete different SoCs and require different kernels altogether for them to boot.

In fact, this is a major headache for anyone who would like to jump to ARM platform - unlike PC platform which is more or less homogeneous, ARM platforms (notice the plural) are very diverse in terms of instruction sets (ARMv5, ARMv6, ARMv7, ARMv8, ...), on-board hardware configuration (depending on the SoC and board makers), RAM, CPU speed, etc. It is unlikely that one can provide a one-size fits all distribution like what you are used to in the PC desktop world.

And this is just at the operating system, if you consider what we need to do to handle conventional keyboard/mouse inputs, touchscreens, voice inputs ... wondering why Android is popular with hardware manufacturers? (Hint: what do you need for Android to boot on your shiny new tablet?)


Question : So what good is the experiment for?

Answer : Once you know what's involved to get one system to boot, you can easily replicate the steps to build the software to boot other systems (provided that the hardware details is available).

Also, while the kernels and the drivers aren't compatible, the user-space apps (applications, tools) most likey are. So you can take, for example, Gnumeric from my build and use it on other ARM platforms that supports ARMv7 with FPU (e.g. BeagleBone Black) and it should work.


Question : Can you port FatdogArm to this board/tablet/settop box/gadget that I have here?

Answer : General answer:

If the answer to all these questions are yes, then the answer is may be .

If you don't have the BSP then don't bother. I don't do reverse engineering, well not anymore. Looking at disassembly and machine codes trying to figure out what the hardware is doing, no longer interests me.