Building AllWinner Android Firmwares

Foreword

This is a work-in-progress post. I'll periodically update this page with new informations, tweaks and tools, because I wanted a single page to collect all the valuable informations about this theme.

Introduction

The AllWinner A10 platform is a relatively new System-on-chip (SoC) product developed by a Chinese Company. His strength point is certainly the low cost compared to computation power and peripheral integration.

The A10 SoC is based on Cortex-A8 ARM core, and provides a Mali-400 GPU on chip.

Another very interesting point about the A10 based products, is that since the SoC has an hardwired primary bootloader, they are practically unbrickable, that makes the A10-based tablet a great base for tablet hackers.

There are many A10 based tablet on the market. The most famous on the European and Italian Market is the Mediacom product line, like the 702 and the 932i.

On the other hand, as usual from many android manufacturer (despite Android openness), the kernel and Android sources hasn't yet been officially released, and only "leaked" version are available on many unofficial repository.

Actually, the most complete Android version is Gingerbread (2.3.6); there's also an IceCream Sandwich version (4.0.3), but last time I checked, it wasn't compilable.

Flashing tools and procedure

Let's start from the flashing procedure, it should be the latest phase, but I prefer to start from the easier part; also because I think it's better to familiarize with this procedure, that you can try with the official, stock, firmwares, and then proceed with the more complex phases, that is: Unpacking and Re-Packing the firmwares, and Customizations.

There are two tools that can be used to flash the tablet: the Livesuit and the PhoenixUsbPro or PhoenixCard.

Almost everybody on the net is using Livesuit, because the Phoneix tool requires one more key file; also the Livesuit is easy to use, but the Phoenix tool can flash up to 200 or so devices at one time.

The Livesuit can be downloaded from here:

– Version 1.07

Note that Livesuit is only in chinese, fortunately after having used it for the first time, it's easy to use and remember the commands.

The first icon selects the IMG file you'll flash on the tablet, while the last one shuts down the livesuit.

[warning]Note that this icon is the only way to cleanly exit from livesuit, using the close command will close the program but will not shutdown all the process, so you’ll not be able to restart it a second time, without shutting down it from the Windows task manager.[/warning]

First, select the image with the first icon.

Then, power off the tablet, then keep presses the "Volume up" button and insert the USB cable. Then press and release the power button for 5-6 times until Windows will have detected the new device.

The first time Windows will install the drivers.

Then Livesuit will ask you if you want to format the entire partitions. This will erase the entire flash memory, so if you haven't a recent backup, say no.

But note that formatting the partitions will give you a completely clean and functional tablet, so you'll maybe want to format it.

[warning]In any case, remember to make and check a backup of your data (/sdcard/)! You always may have a non-functional device, so you are warned![/warning]

After 3 or 4 minute, an empty (!) message box will tell you that the process is completed.

…

Creating the firmware

The firmware must be created by using the "kitchen" suite.

It's a set of programs and scripts that automatically unpack and repack the img file onto the different partition images.

Every android installation is composed by 6 partitions on the internal flash memory:

Bootloader: this is the second program that is executed when you power up or reset your device. The first is an internal bootloader that can't be written.

Kernel: this is the main linux kernel, and is executed after the bootloader

Recovery Kernel: this kernel is executed when the bootloader is executed in "recovery" mode. This allow the tablet to be recovered if the main kernel or installation is broken, malfunctioning or erased

Rootfs, the main Android installation. This partition is mounted in the /system/ directory of your tablet, and contains all the main programs, libraries and drivers

Cache: this partition is used by dalvik (the Java Virtual Machine that Android uses) to compile the applications and allows each app to be loaded without being recompiled, so executing very fast

Userdata: This is where you, the user, put all your data and applications. It's mounted by Android in /sdcard/, and is called "the external sdcard" even if it resides inside the internal flash memory.

From now on, I suppose that you'll copy your files in a different subdirectory for each partition, so when I'll write to copy a file in "boot/linux/", this means that it will be into the linux directory of the boot image/partition. Or, root/system/app will be the system/app directory from the root file system directory image.

…

Customizing the splash screens

There are 3 splash screen on the tablet image: The bootloader splash screen, the Kernel Splash Screen and the android Boot Animation.

These are three differents formats:

the boot is a 32bit Windows Bitmap image (BM8)

the Kernel is a raw, RGBA image, and

the Android is a zip file containing png or jpg images and a control file

The boot image can be created from a standard image by using Photoshop: Load the image, then save it as a 32 bit Windows Bitmap, without compression. You can't use ImageMagick, because the bmp3 filter only create a 24bit image, and there's no way to bypass this function. Even forcing "-depth 32" generate a BM6 file header (24bit).

The file must be saved in the bootfs archive

$ cp linux.bmp bootfs/linux/linux.bmp

The kernel image is a rgba raw file, and can be easily created by using ImageMagick; then copy it on the kernel

$ convert bootsplash.jpg initlogo.bgra

$ mv initlogo.rgba kernel/initlogo.rle

Note the .rle extension

[warning]dfighter1985 noted in a previous version of this post that the resulting image is “blueish”. We needed to apply a +180degree hue correction. Indeed the problem was with the channel ordering, that is BGRA for AllWinner, not RGBA as previously stated. The command line has been fixed. Thanks to dfighter1985 for the comment.[/warning]

The Android bootanimation is yet another different format.

The file, named bootanimation.zip and placed on the /system/media directory, is, as self-evident, a zip archive.

Inside the file, there must be a text file called desc.txt and a set of animation frames as png files inside one (or more) subdirectory.

The animation can include various subsequences. The most obvious is a single sequence repeated as a loop, but another common animation can include a first subsequence played only once, and a progress loop.

Each subsequence is put on a different directory, part0, part1, etc… The sequence is read "as is". So

Each file is named androidXXXX.png, with XXXX the frame number as 0000, 0001, 0002 and so on.

The desc.txt file describe the content and behavior of the animation:

$ cat bootanimation/desc.txt
800 480 30
p 0 0 part0

The first line specifies: width and height of the frames and the desired framerate (frames per seconds)

The following lines define the animation subsequences: "p" identifies a subsequence, the first number is the repeat count (0 means "loop forever"), the second is the pause between subsequences, and the last string is the directory containing the subsequence.

Pack it as a zip file, pay attention not to include any subdirectory (the desc.txt file and all other part* directories must be in the root of the zip file), and save it in /system/media/bootanimation.zip.

Hi Dfighter, thanks for your visit.
Very difficult to tell. If the problem is on the boot splash screen, it could be due to a bad ordering of the RGBA values; note that also for me there’s a difference between the bootloader image and the kernel boot image.
If the problem is happening also after the boot is completed (i.e. on the android launcher and lock screen), the problem is on the screen driver. Look carefully in the logger and in /proc/kmsg if there’s some information or error message. Did you recompile the kernel from scratch?

Hi there!
Since then I’ve found the solution. Basically all you have to do is apply +/-180 hue to the original image before flashing and then it will appear right on the device.
I’m not at all sure about why this is needed, since the bootloader image display just right. However at least it’s solved! 🙂

Btw I haven’t recompiled anything yet, only getting to know Android devices at the moment.