Fatdog Arm Page
Progress
- Getting it to boot
- Booting it with initrd
- Building the native compiler
- Building the applications
- Maintaining software packages
- Progress roadmap
- Extra: Preparing the ARM toolchain yourself
- Extra: Getting the most of your device
- Extra: Touchscreen input
- Extra: Adopting FatdogArm for other systems
- Extra: Running FatdogArm in Qemu
- 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:
- Batteries included - comes with nice case, remote, power supply, etc.
The only thing I need to buy was HDMI cable. - Boots from SD Card.
This makes "flashing" as easy as saving a file to SD Card (or at most,
using
dd
). Also, it means that it is practically un-brickable. - USB ports: instant expansion of fast storage with portable harddisk for
data and swap memory.
It also means conventional keyboard and mouse access. - Wifi / Ethernet built-in: instant network access.
- Supports HDMI and VGA.
- Memory size and CPU speeds are not ridiculously low - the system is capable of native compiling.
- Low cost!
References
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:
- Is the Linux kernel and boot-loader available for that platform
(in another words: is there a complete, open Board Support Package (BSP)
for your board)?
- Is there a way to program your board that doesn't involve flashing its
NAND using proprietary operating system (Windows) software or JTAG or
PROM programmer?
- Is your board unbrickable?
- Lastly - do you have a sample hardware you can send to me for development and testing?
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.