A bit more than a year ago, I ordered a Geeksphone Peak
, one of the first widely available Firefox OS phones to explore this new OS.
Those notes are probably not very useful on their own, but they might give a few hints to stuck Android developers.
The device has a Qualcomm Snapdragon S4
MSM8225Q SoC, which uses the Adreno 203 and a 540x960 Protocol A (4 touchpoints) touchscreen.
203 (Note: might have been 205) is not supported by Freedreno
, and is unlikely to be. It's already a couple of generations behind the latest models, and getting a display working on this device would also require (re-)writing a working panel driver.
At least the CPU is an ARMv7 with a hardware floating-point
(unlike the incompatible ARMv6 used by the Raspberry Pi), which means that much more software is available for it.
Getting a shell
Start by installing the android-tools package, and copy the udev rules file to the correct location (it's mentioned with the rules file itself).
Then, on the phone, turn on the developer mode
. Plug it in, and run "adb devices", you should see something like:
$ adb devices
List of devices attached
Now run "adb shell" and have a browse around. You'll realise that the kernel, drivers, init system, baseband stack, and much more, is plain Android. That's a good thing, as I could then order Embedded Android
, and dive in further.
If you're feeling a bit restricted by the few command-line applications available, download an all-in-one precompiled busybox
, and push it to the device with "adb push".
You can also use aafm
, a simple GUI file manager, to browse around.
Getting a Fedora chroot
After formatting a MicroSD card in ext4 and unpacking a Fedora system image
in it, I popped it inside the phone. You won't be able to use this very fragile script
to launch your chroot just yet though, as we lack a number of kernel features that are required to run Fedora. You'll also note that this is an old version of Fedora. There are probably newer versions available around, but I couldn't pinpoint them while writing this article.
Runnning Fedora, even in a chroot, on such a system will allow us to compile natively (I wouldn't try to build WebKit on it though) and run against a glibc setup rather than Android's bionic libc
Let's recompile the kernel to be able to use our new chroot.
Avoiding the brick
Before recompiling the kernel and bricking our device, we'll probably want to make sure that we have the ability to restore the original software. Nothing worse than a bricked device, right?
First, we'll unlock the bootloader, so we can modify the kernel, and eventually the bootloader. I took the instructions from this page
, but ignored the bits about flashing the device, as we'll be doing that a different way.
You can grab the restore image from my Fedora people page
, as, as seems to be the norm for Android(-ish) devices makers to deny any involvement in devices that are more than a couple of months old. No restore software
, no product page
The recovery should be as easy as
$ adb reboot-bootloader
$ fastboot flash boot boot.img
$ fastboot flash system system.img
$ fastboot flash userdata userdata.img
$ fastboot reboot
Recompiling the kernel
We grabbed the source code from Geeksphone's github tree
, installed the ARM cross-compiler (in the "gcc-arm-linux-gnu" package on Fedora) and got compiling:
$ export ARCH=arm
$ export CROSS_COMPILE=/usr/bin/arm-linux-gnu-
$ make C8680_defconfig
# Make sure that CONFIG_DEVTMPFS and CONFIG_EXT4_FS_SECURITY get enabled in the .config
We now have a bzImage of the kernel. Launching "fastboot boot zimage /path/to/bzImage" didn't seem to work (it would have used the kernel only for the next boot), so we'll need to replace the kernel on the device.
It's a bit painful to have to do this, but we have the original boot image to restore in case our version doesn't work. The boot partition is on partition 8 of the MMC device. You'll need to install my package of the "android-BootTools" utilities
to manipulate the boot image.
$ adb shell 'cat /dev/block/mmcblk0p8 > /mnt/sdcard/disk.img'
$ adb pull /mnt/sdcard/disk.img
$ bootunpack boot.img
$ mkbootimg --kernel /path/to/kernel-source/out/arch/arm/boot/zImage --ramdisk p8.img-ramdisk.cpio.gz --base 0x200000 --cmdline 'androidboot.hardware=qcom loglevel=1' --pagesize 4096 -o boot.img
$ adb reboot-bootloader
$ fastboot flash boot boot.img
Getting a Fedora chroot, part 2
Run the script. It works. Hopefully.
If you manage to get this far, you'll have a running Android kernel and user-space, and will be able to use the Fedora chroot to compile software natively and poke at the hardware.
I would expect that, given a kernel source tree made available by the vendor, you could follow those instructions to transform your old Android phone into an ARM test "machine".
Going further, native Fedora boot
Not for the faint of heart!
Modify the /etc/fstab so that the root partition is the SD card:
/dev/mmcblk1 / ext4 defaults 1 1
We'll need to create an initrd that's small enough to fit on the boot partition though:
$ dracut -o "dm dmraid dmsquash-live lvm mdraid multipath crypt mdraid dasd zfcp i18n" initramfs.img
Then run "mkbootimg" as above, but with the new ramdisk instead of the one unpacked from the original boot image.
Flash, and reboot.
In the future, one would hope that packages such as adbd and the android-BootTools could get into Fedora, but I'm not too hopeful as Fedora, as a project, seems uninterested in running on top of Android hardware.
Why am I posting this now? Firstly, because it allows me to organise the notes I took nearly a year ago. Secondly, I don't have access to the hardware anymore, as it found a new home with Aleksander Morgado
Aleksander hopes to use this device (Qualcomm-based, remember?) to add native telephony support to the QMI stack
. This would in turn get us a ModemManager Telephony API, and the possibility of adding support for more hardware, such as through RIL
(similar to the oFono RIL plugin
used in the Jolla phone).