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

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

http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard

http://imx.solid-run.com/wiki/index.php?title=U-Boot#Files_involved_in_booting

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 https://github.com/SolidRun/u-boot-imx6.git

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
make

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 https://github.com/SolidRun/linux-linaro-stable-mx6.git
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

### ONLY FOR BEGINNING
##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, http://imx.solid-run.com/forums/viewtopic.php?f=17&t=450, 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:

http://pastebin.com/rs1DkzJL

Advertisements

One response to this post.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: