Developing kernel on a Virtual Machine (the solution)

I am working now on Ubuntu Karmic Koala.

As I said in my previous post, Qemu is a complete platform emulator that can emulate the Integrator ARM machine platform (CPU and devices!).

In Karmic Koala the latests Qemu version (0.11.0) is shipped within Ubuntu repositories so with this line we can install it:

# sudo apt-get install qemu qemu-kvm qemu-kvm-extras

ARM test images

From the Qemu home page we can download a Linux 2.6 ARM example image builded by Paul Brook and extracting it in $PRJROOT/images, we can find the README file where it is written how to launch the test platform:

# cp DownloadDirectory/arm-test-0.2.tar.gz $PRJROOT/images
# cd $PRJROOT/images
# tar -xvf arm-test-0.2.tar.gz
# cd arm-test
# cat README

So, with or without the graphical interface we can test the qemu arm installation with the followings:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img
or
# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"

A suitable Linux config file

Over the test purpose , executing the test image can give the kernel configuration file stored in /proc/config.gz ! so:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"
Uncompressing Linux...............................................
........................... done, booting the kernel.
Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery ARM))
 #53 Thu May 4 15:05:18 BST 2006
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
Machine: ARM-IntegratorCP
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists
Kernel command line: console=ttyAMA0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total

...

Log in as root with no password.
qemu login: root
# cp /proc/config.gz .
# tar -xvf config.gz
# vi config.gz

With this file we can configure the mainline linux kernel! (copying from screen, copying within net, scrolling the options with a near mainline make menuconfig window).

ARMv5te Toolchain to build the kernel

The machine emulated by qemu-arm is based on the core ARMv5te , so I need the correct toolchain for build all the necessary code.

The Pengutronix OSELAS environment can do that in the OSELAS toolchain project. Similarly at what described in Initializing a Linux Embedded Development Host Machine moving in $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/ we can select the suitable ptxdist configs with:

# cd $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/
# ls ptxconfigs/
arm-1136jfs-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig.old
arm-cortexa8-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
arm-v4t-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v4t-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te_vfp-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.2.3_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
# ptxdist select ptxconfigs/\
  arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
# ptxdist menuconfig

In the menuconfig, all can live as it is but in “misc->prefix for installation” we can choose $PRJROOT/tools where $PRJROOT must be manually extended. So with:

# ptxdist go

A part from minor dependencies that we can solve installing software with apt-get, the toolchain is built and the correct prefix will be:

CROSS_COMPILE_OSELAS_v5=$PRJROOT/tools/OSELAS.Toolchain-1.99.3/arm-v5te-linux-gnueabi/\
   gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-v5te-linux-gnueabi-

If we assign the environmental variable CROSS_COMPILE=CROSS_COMPILE_OSELAS_v5 the kernel configured by the upper config file and compiled with this toolchain is a good kernel to execute within the qemu-system-arm emulator!

A suitable Root Filesystem

Ok we have a good kernel ad a small initrd filesystem, but we have to develop application to run in the emulated device!

We can use the OSELAS.BSP Phytec phyCORE project installed following the description in Initializing a Linux Embedded Development Host Machine.

Download the platform_config file platformconfig-qemu and the ptxconfig one ptxconfigThiny (that is the normal ptxconfig removing all graphic subsystem for a speedier compilation)

Every two configuration file must be placed in $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/configs so with:

# cd $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/
# ptxdist select configs/ptxconfigThiny
# ptxdist platform configs/platformconfig-qemu
# ptxdist toolchain $CROSS_COMPILE_OSELAS_v5
# ptxdist go
# ptxdist images

In  $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/ we will find the root.ext2 image, ready to be the SD/MMC image of the qemu device!

Running qemu

If in the $PRJROOT directory we create the images/phyCORE directory and we put all the necessary:

# cd $PRJROOT
# mkdir -p images/phyCORE
# cp (kernel_path)/arch/arm/boot/zImage images/phyCORE/
# cp $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/root.ext2\
  images/phyCORE/

then we can start qemu:

# qemu-system-arm -kernel images/phyCORE/zImage -sd images/phyCORE/root.ext2 \
  -nographic -append "console=ttyAMA0 root=/dev/mmcblk0"

Results

In results we have a complete developing environment: emulator, toolchain, kernel, software ecosystem.

Kernel modification that do not deal with the hardware abstraction layer can be well developed in the emulator and tested by ad-hoc software inserted in the phyCORE-qemu distribution!

Developing kernel on a Virtual Machine (First try)

To save writing cycles of the Armadillo NAND flash, in those days I had  searched a way to execute the developing kernel on an ARM emulator.

First try: Android Emulator

I am working on Android? so why not using the Android Emulator tool??

I am not a guru on this, so maybe I’m wrong with something.. Someone will correct me if there were an easier way.

Android emulator is known to be build over the Qemu Open Source Process Emulator but Google tend to do things harder than they are: they have introduced a new virtual hardware device based on ARMv5te architecture called Goldfish.

Qemu emulate so well the ARM Integrator platform (same processor architecture), why build another? why create another buggy linux platform? buggy in the sense that it work for the kernel version that is developed, but must be maintained in the successive kernel release and who do this work? Maybe unanswerable question..

I’ve tried to port in mainline the Goldfish platform taking it from the android-goldfish-2.6.29 branch, correcting all the Coding Style problems given by checkpatch.pl resulting in: early support, console output  and maybe network ability, but no ability to mount initrd images or nand images -> no rootfilesystem ability and so I not spend here so many time describing this developing path.

Fortunately the light bulb come up my head and through the Qemu home page I’ve found that the reference machine platform for ARM emulation is the ARM Integrator, well supported in mainline Linux kernel and within the downloads I’ve found a reference kernel plus initrd file to use within.
Good! Second try!

Android subsystem is gonna die

As you can see on linux webgit log the Android subsystem resident on mainline kernel developing tree is gonna die:

Staging: android: mark subsystem as broken

It’s causing lots of build errors, so just mark it as broken.  It is
scheduled to be removed in 2.6.33 anyway.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

A BROKEN subsystem is a piece of kernel code that the build system do not visit in the build process.

The true problem is that Google has stopped to support mainline code leaving it at an embryonic state: no Coding Style corrections and no update on new kernel API changes.

Another important thing is that the android subsystem that live now in mainline kernel is incomplete: many parts of Google layer were not merged with mainline linux, producing an eternal incomplete subsystem.

What the mess with this? Why the mainline part of Android is important? There is always the android branch hosted by Google no?

Yes is true, but what about the next device porting? what about quality on device porting? A mainline architecture support code is controlled and accepted by a number of Community Developers that know better than a lot of people how this things must be done, and sure, also the better developer make mistakes!

Developing a new hardware platform in the Google android branch make this job harder and full of traps.

The aim of my job now is to recover this situation, taking the present mainline android subsystem on the right way in terms of quality and readability and then completing it with the missing things!

So, good Job Alberto!