See also BootMenu for ARM platform.
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:
dd
). Also, it means that it is practically un-brickable.
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.