Archive for June, 2014

Hacking through device tree, uboot, and linux kernel setup for Cubox i4-Pro

The following are adding further information to the following wiki pages:

First the Cubox i4 Pro boots from sdcard. u-boot has been modified by SolidRun to generate the initial image for booting: SPL and u-boot.img.
Download the u-boot modified for Cubox:

git clone

First create the SPL and u-boot.img for flashing into the sdcard (notice that the crosscompiler used is arm-linux-gnueabi-gcc, but I suspect it is possible to use CodeSourcery’s arm-none-eabi-gcc as well, not tested. but the the linux kernel later "arm-none-eabi-gcc was used for compilation):

export ARCH=arm
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-

#cd u-boot-imx6
make clean
make mx6_cubox-i_config

Next is to flash the SPL and u-boot.img created from above to the SDCARD:

#####DEVICE=/dev/sdb where /dev/sdb is the SDCARD.

dd if=SPL of=$DEVICE bs=1K seek=1
dd if=u-boot.img of=$DEVICE bs=1K seek=42

Next is to download the Linux kernel modified for Cubox (and noticed now the crosstool chain is CodeSourcery’s arm-none-eabi-gcc, please download that first):

git clone
cd linux-linaro-stable-mx6

Ensure /opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/ is in $PATH env variable, where the binary arm-none-eabi-gcc, for example, are found.

export ARCH=arm

export CROSS_COMPILE=arm-none-eabi-

make imx_v7_cubox-i_hummingboard_defconfig
make zImage imx6q-cubox-i.dtb imx6dl-cubox-i.dtb imx6dl-hummingboard.dtb
make modules

##make imx_v7_cubox-i_hummingboard_defconfig
make zImage imx6q-cubox-i.dtb imx6dl-cubox-i.dtb imx6dl-hummingboard.dtb
make modules
make modules_install INSTALL_MOD_PATH=mylibmodule

Create the boot.txt file:

setenv bootargs 'root=/dev/mmcblk0p2 console=ttymxc0,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32'
load mmc 0:1 0x18000000 imx6q-cubox-i.dtb
fatload mmc 0:1 0x10800000 zImage
bootz 0x10800000 - 0x18000000

Using "mkimage" command create the boot.scr based on "boot.txt" from above:

mkimage -A arm -O linux -T script -C none -n "U-Boot commands" -d boot.txt boot.scr

Next is to create the uEnv.txt file:

mmcargs=setenv bootargs root=/dev/mmcblk0p2 rootwait video=mxcfb0:dev=hdmi consoleblank=0

Noticed from above that the "root=/dev/mmcblk0p2" is the location of the rootfs, which as the next few lines will show, is the /dev/sdb2 partition of the SDCARD. The above setting was found to work based on the "printenv" output of my Cubox:

printenv ===> (after navigating through the u-boot's output):

mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot};

and so on……and anything in uEnv.txt will overwrite the original settings from u-boot.img.

After the "dd" operation on the SDCARD from above, next is to create two more partition for the linux kernel + rootfs:

/dev/sdb1: LABEL="BOOT" UUID="F96B-B2E1" TYPE="vfat"
/dev/sdb2: LABEL="Volumio" UUID="66df47cb-6add-46d3-8178-36cf1e4d2d1a" TYPE="ext4"

Disk /dev/sdb: 7902 MB, 7902068736 bytes
244 heads, 62 sectors/track, 1020 cylinders, total 15433728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00055ae1

Device Boot Start End Blocks Id System
/dev/sdb1 2048 131071 64512 b W95 FAT32
/dev/sdb2 131072 7716863 3792896 83 Linux

Yes, noticed that /dev/sdb1 starts from sector 2048, whereas the u-boot.img is written onto 84th sector (42×1024=84×512) and writing u-boot.img image and writing to /dev/sdb1 will not overwrite one another.

In /dev/sdb1 the following files are copied:

├── boot.scr
├── imx6dl-cubox-i.dtb
├── imx6dl-hummingboard.dtb
├── imx6q-cubox-i.dtb
├── SPL
├── u-boot.img
├── uEnv.txt
└── zImage

(not all files are used by the u-boot during bootloading, essentially only imx6q-cubox-i.dtb, uEnv.txt, and zImage are used)

The above list of instructions is convoluted and complicated. But if you get stuck somewhere, for example,, there are lots of experimentation and debugging you can do to figure things out (by the way, if you are using "minicom" then better replace it with another terminal – "minicom" will truncate a lot of the u-boot environmental output, misleading me into thinking that the environment variable is not set. I am using "picocom" now, works marvelously):

For example, after connecting Cubox to the PC, via USB, /dev/ttyUSB1 will be autorecognized:

sudo picocom -f n -p n -b 115200 -i -r -l /dev/ttyUSB1

CuBox-i U-Boot > ls mmc 0:1
231452 u-boot.img
35840 spl
230 boot.scr
43388 imx6dl-cubox-i.dtb
43470 imx6dl-hummingboard.dtb
43845 imx6q-cubox-i.dtb
90 uenv.txt
4900544 zimage

8 file(s), 0 dir(s)

CuBox-i U-Boot > load mmc 0:1 0x18000000 imx6q-cubox-i.dtb
43845 bytes read in 17 ms (2.5 MiB/s)

CuBox-i U-Boot > load mmc 0:1 0x10800000 zImage
4900544 bytes read in 308 ms (15.2 MiB/s)

CuBox-i U-Boot > bootz 0x10800000 - 0x18000000
Kernel image @ 0x10800000 [ 0x000000 - 0x4ac6c0 ]
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800db44

Starting kernel ...

Trying out the commands successfully as above, now it can be packaged together into the "boot.scr" file using "mkimage" command.

These are the esssential u-boot commands:

ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls - list files in a directory (default /)
false - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)

printenv- print environment variables

setenv - set environment variables

After all the above is the Linux kernel booting up messages:

CuBox-i U-Boot > bootz 0x10800000 - 0x18000000
Kernel image @ 0x10800000 [ 0x000000 - 0x4ac6c0 ]
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800db44

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 3.10.30-g860304a (tthtlc@papamama) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-24) ) #2 SMP Sun Jun 8 23:08:03 SGT 2014
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: SolidRun Cubox-i Dual/Quad
Truncating RAM at 10000000-8fffffff to -7f7fffff (vmalloc region overlap).
cma: CMA: reserved 256 MiB at 6e000000
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 8 pages/cpu @81715000 s8512 r8192 d16064 u32768

Full details here:

How to root Sony Ericsson Xperia Z (with minimal installation)

Lately I have successfully rooted my Sony Ericsson Xperia Z (firmware version 10.4.1.B.0.101, using Ubuntu 12.04 64-bit + Android SDK):

First, follow the following instruction (from Sony Ericsson) to unlock the bootloader (so that you can install your own custom recovery software):

As instructed within you have to download Android SDK from google (+ a fastboot USB drivers, if you are on windows, for linux Ubuntu 12.04, the USB drivers is built-in the kernel/distro): (only for Windows)

Next from the following article:

I did just this:

1. Download the, and then the UPDATE-Super-SU: (whose link is from here:

etc) and put the super-su zip file in the Xperia Z’s sdcard.

2. Extract out the "boot.img" file:

-rw-r–r– 1 root root 11313152 Jun 5 00:41 boot.img

md5sum boot.img

8ca52df5bf295631a0bd4dfdf5676baf boot.img

And using "fastboot" to put the Xperial Z into the bootloader mode (the entire screen of Xperia Z is blank black in color, with only the LED light in blue on the top right corner).

3. the using the Android SDK command to install the boot.img as the recovery manager:

fastboot flash boot boot.img

4. Issue "fastboot reboot", and when LED turns pink, immediately click on Volume UP (this sequence is precise and correctly timed, otherwise you will reboot into normal Android normal runtime mode (like me) and has to redo the whole thing again (starting from step 3) and now you will enter CWM recovery screen.

5. In this screen, navigate to the SDCARD where the super-su is located, and install the zip file.

Now you are rooted!! (and only the super-su + boot.img is installed, without the bloat from DOOMLOAD’s AdvStkKernel (:-), but since the CWM recovery manager is installed as well, lots of other stuff can be installed in future….if needed.).

I have done rooting of Nexus 7 (2013, and 2012) as well….another day will elaborate.

Below are collected the references I have consulted:

%d bloggers like this: