Alberto Embedded & Open experience

Notes on my experience on Open Source Embedded Systems

Posts Tagged ‘linux

Developing kernel on a Virtual Machine (the solution)

leave a comment »

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!

Advertisements

Written by Alberto!

25/11/2009 at 5:01 pm

Android subsystem is gonna die

with 3 comments

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!

Written by Alberto!

23/11/2009 at 6:11 pm

iMX Linux Boot Process description online

with one comment

Within my links on right side now there is the pdf document that describe the entire Linux boot process adapted for arm i.MX31: after the bootloader work through the execution of /sbin/init!

Taste it! Bye!

Written by Alberto!

03/04/2009 at 9:09 pm

Posted in linux-arm

Tagged with , , , ,

Very deep focus on ARM Boot process

leave a comment »

Here Peter Pearse make a very deep and up-to-date focus analysis of SMP ARM Boot process:
http://www.linux-arm.org/LinuxBootLoader/SMPBoot
Thanks a lot to him 🙂

With little adjusting Voilà! the single core ARM Boot process!
The context where I have to work and without I will not understand nothing :p

Written by Alberto!

02/04/2009 at 3:04 pm

Posted in linux-arm

Tagged with , ,

Kernel XIP

leave a comment »

What is XIP?? Only for memo.. eXecute In Place.
Ref: http://elinux.org/Kernel_XIP

Written by Alberto!

02/04/2009 at 2:04 pm

Posted in linux-arm

Tagged with ,

What Run First

leave a comment »

Form Arm-Linux Mailing list, posted by Russell King
http://lists.arm.linux.org.uk/lurker/message/20011005.154003.5d698445.html

What runs first depends on what type of kernel you start running.

Compressed kernel (aka zImage):

  1. the startup code in arch/arm/boot/compressed/head.S (start label)
    (and maybe some other architecture specific code in other head-*.S files in that directory).
  2. Decompressor proper (via decompress_kernel) in arch/arm/boot/compressed/misc.c which gunzips the kernel.
  3. We then relocate the kernel if required, and call it.

Uncompressed kernel (aka Image):
This is where we join the uncompressed kernel startup.

  1. arch/arm/kernel/head-armv.S (Edit head.S and head-*.S ) describes this, and includes such things as:
    page table initialization and processor cache initialization
    (via support stuff in arch/arm/mm/proc-*.S).
  2. We then proceed to start_kernel in init/main.c, and everything follows from that point on.
  3. The only other thing to note is that the various drivers are initialized via a table built by the linker from the __initcall() and module_init() statements scattered throughout the kernel source. The code which calls them can be found in init/main.c: do_initcalls().

Written by Alberto!

02/04/2009 at 12:55 pm

Fermo per un pò.. ma riprendo!

leave a comment »

Dopo gli eventi della settimana scorsa ho ripreso il lavoro..
Ora mi stò concentrando sulla creazione del supporto ad armadillo 500 per la versione corrente del kernel: 2.6.29 Questo perché:

  1. Atmark con la loro bsp si sono strafregati dello sviluppo mailine del kernel..
  2. -> La bsp risultate è difficile da portare su kernel recenti.
  3. Se devo fare lo sforzo di rivedere l’intera bsp, cosa mi trattiene da farlo fatto bene in modo che possa convivere con tutte le altre??
  4. Per Android è già presente la versione del kernel 2.6.29..! skeggie! 🙂

Written by Alberto!

01/04/2009 at 1:14 pm

Posted in Armadillo

Tagged with ,