This page describes how to obtain memory information and the script.bin from the stock operating system of a sunxi device. This is needed for adding support for a new device, as part of our New Device Bringup howto.

Any of the methods below requires that Sunxi-tools is installed and built on your computer.

Using FEL

Make sure that the original image is on the device, and that the original u-boot will be booted by the device ROM. Remove any SD-card that might have been inserted.

Entering FEL mode

The procedure for entering FEL mode is described on this page, but for clarity, it is reproduced here as well.

By using physical buttons

Fully power off the device, if needs be through a power-button reset.
Hold down the home button and do not release.
Power on the device by pressing the power button.
After a few seconds, press the power button at least three times (or just keep on triggering the power button for several seconds).
After several seconds, release home button.

Note that, if you do not have a Home button, the vol+ / vol- button might work as well. If you have booted through a hard reset (if you have a reset button), or by holding the recovery button (if available), or through usbboot, FEL will not load the necessary information to memory, and the retrieved data will be bogus.

By using the serial console

Fully power off the device, if needs be through a power-button reset.
Connect the UART cable (but do not connect it before or the device will not power off properly).
Start the console program.
Send "2" over the serial link, by hold down "2" on your keyboard.
Power on the device by pressing the power button.
Wait until boot1 says it enters FEL mode, and then you can release "2".

Retrieving data over USB in FEL mode

You should now attach a USB OTG cable. If you have been able to correctly trigger FEL mode, you should now be able to get the FEL version. Run the following from the sunxi-tools tree on your host:

./sunxi-fel version

This should return something resembling:

AWUSBFEX soc=00162300(A10) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

If not, you might not have entered FEL mode correctly.

Now you should be able to retrieve the relevant information by running:

 ./sunxi-fel read 0x42400000 0x82d0 boot1.header 
 ./sunxi-fel read 0x43000000 0x20000 script.bin

Now the retrieved data can be converted to readable text which can then be used in the Device Bringup howto.

 ./sunxi-bootinfo boot1.header > bootinfo.txt
 ./bin2fex script.bin script.fex

Using the original OS

Working with android

The information which was originally here spent most of its time dealing with android intricacies. These are often device specific and the necessary information tends to be multiplied endlessly all over the internet.

To successfully retrieve the necessary information, you need access to the command line, you need a means of transferring the retrieved data, and you need to have root access to the device.

Android Debug Bridge

When working, ADB is by far the most convenient way of working with android. It can give you shell access, and can transfer files.

More information on ADB can be found here.

Terminal program

...

SSH server

...

USB storage

...

SD-Cards under android

...

Rooting android devices

Most sunxi based systems have no restrictions, and root access can be readily attained. If not, search the web for android forums which might describe how to root your device.

Reading memory information from registers

DRAM information can be read from the SoC registers directly using the meminfo tool.

Once you've built this tool, all you need to do is get this file somewhere on your android filesystem (for instance, /data/cache), make sure that it is executable (chmod 755), and then run it and retrieve its output (for instance, to the sdcard).

copying script.bin from flash

Script.bin is directly available from the first partition of the NAND flash (but apparently this is not the case with newer Allwinner devices). Under Android, this flash device should appear as /dev/block/nanda. Often nanda is already mounted, if not, you can just mount it with -t vfat.

copying script.bin from RAM

Script.bin can be also dumped directly from RAM using the script-extractor tool.

Using a livesuit image

While it is much much preferable to retrieve information from your device directly, this sometimes is not possible (either due to a bricked device, or the lack of a fel button or usb-otg). If you have been able to find a livesuit image, you might still get the information you need, at least until you can boot a full sunxi and examine the nand filesystem directly.

Extract the image

First, git clone the awutils repository and build it.

Then, extract the image with awimage:

awimage -u name.img

This will create a directory called name.img.dump, filled with loads of files and matching .hdr files.

Retrieve bootinfo

The files for this are often called 12345678_1234567890boot_0 or 2345678_1234567890boot_1. When in doubt, grep:

grep "eGON.BT" *

You can then run bootinfo from sunxi-tools on one of the files to retrieve the memory information.

Retrieve script.bin

You then need to find the filesystem which usually lives in nanda. This is usually known as RFSFAT16_BOOTLOADER_00000, but when in doubt, grep:

grep "SCRIPT  BIN" *

This is a fat image that can be mounted directly:

mount -o loop /home/user/dir/name.img.dump/RFSFAT16_BOOTLOADER_00000 /mnt/

You can then just take the script.bin and run it through bin2fex.

Retrieve firmware and other random files from Android system

The largest file in your unpacked Livesuit image should be a sparse ext4 filesystem.

file RFSFAT16_SYSTEM_000000000
 RFSFAT16_SYSTEM_000000000: Android sparse image, version: 1.0, Total of 131072 4096-byte output blocks in 1346 input chunks.
simg2img RFSFAT16_SYSTEM_000000000 RFSFAT16_SYSTEM_000000000.img
mount -o loop,ro RFSFAT16_SYSTEM_000000000.img /mnt
cp -a /mnt/vendor/modules .

You can find simg2img in Android SDK or a distro package such as android-tools-fsutils on Debian.

Alternate script.bin retrieval method

This method is limited in that it can only retrieve the script.bin and not the necessary memory information. It also requires access to the UART, which means that it is of limited use now that we have the ability to talk to FEL mode directly.

Fully power off the device, if needs be through a power-button reset.
Connect the UART cable (but do not connect it before or the device will not power off properly).
Start the console program.
Send "1" over the serial link, by hold down "1" on your keyboard.
Power on the device by pressing the power button.
Wait until boot1 says it enters FEL mode, and then you can release "1".

You should now be able to connect a USB OTG cable, and copy script.bin (and .fex if available) off usb storage.

Other information

Wifi, Bluetooth

It is good idea what to try and find out what Wifi and Bluetooth chips your device has. Bluetooth is often implemented in the same chip as wifi if present at all.

You can try to read the text on a chip near antenna wire (often on a subboard) and compare it to list of known WiFi chips common on tablets or try to look at kernel messages from the android system preinstalled on your device.

It is possible that the chip you have is already supported and will work out of the box when you boot linux but you may have a new yet unknown chip. Even when driver for the wifi chip is available somewhere you may need to copy a firmware file from the original android system to use wifi.

Touchscreen

Touchscreen support is not very good so far. Although Allwinner SoCs have built-in support for single-touch resistive touchscreen, it is usually not used due to popularity of capacitive multitouch touchscreens.

Many touchscreens require a firmware file that has to be extracted from android - either from a kernel module (.ko file) or from special directory (usually /etc/firmware or /vendor/firmware).

Identify via kernel log

One possible way to identify the touchscreen controller is to look at the kernel messages from the original android system:

$ cat kernel.log |grep input
<6>[    1.912941] input: sun4i-keyboard as /devices/virtual/input/input0
<6>[    2.181851] input: axp20-supplyer as /devices/platform/sun4i-i2c.0/i2c-0/0-0034/axp20-supplyer.28/input  /input1
<6>[    8.590497] input: Goodix-TS-board-3 as /devices/virtual/input/input2
<6>[    8.936340] input: bma250 as /devices/virtual/input/input3

From the log above, we can see that this device has 4 input devices. And using common knowledge we know that this device is using one of the Goodix chips. Further identification is left as a exercise to the reader.

Identify using the chips from PCB

It is sometimes possible to identify the touchscreen driver by searching the web for some alphanumeric codes that are printed on the chip near the touchscreen cable.

cameras, accelerometers, gps, rtc and other miscellaneous devices

Linux has suport for many of these devices. However, not many people care about them working or not so far.

Retrieving device information

Contents