thanks for your detailed description of how you cross compile the Kernel and the good luck wishes :). I downloaded the same kernel version as the Elions Distribution is running and used the same kernel .config file. I didn't touch the makefile as from reading it it should be possible to get the same when calling make appropriately, in my case:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
and then make ARCH=arm CROSS_COMPILE=arm-linux-gnueab-
I got a vmlinux image in the source tree which I made "u-bootable" by:
mkimage -A arm -O linux -T kernel -C none -a 0xa0008000 -e 0xa0008000 -n "Linux 2.6.22" -d vmlinux pImage
The addresses where stolen from the uboot terminal when booting the Elinos Kernel.
However, after "Kernel starting" pretty much nothing is happening using the new kernel. You mentioned something about a machine number which has to match with uboot and the kernel, I didn't understand this fully. Is mkimage not updating everything and adds the uboot header and checksum etc.? If something is not right to uboot I thought it issues statements like "bad magic number" (had this as well but I didn't feel anything magic about at all).
I thought maybe it is only a console problem and after a certain time I tried to ping the board without success.
What I am doing now is to compare the kernel building to the elinos one and afterwards trying to enable CONFIG_DEBUG_LL.
If you have any hints on how to debug this it would be greatly appreciated as I think you have much more experience in this (for me it is the first time :))
From: Martin Fuzzey [mailto:email@example.com]
Sent: Tue 2/17/2009 10:50 AM
To: Hoefle Marco
Subject: Compiling arm kernel [was Re: Getting emdebian crush running: root passwort created by emsandboy and tty problem]
Hoefle Marco wrote:
> Anyway, for the demo I am happy to have this workaround. The next step is to get rid of the tty problem and then to cross-compile an arm linux kernel using the
> emdebian tools instead of having the Elinos Kernel (are there some docs regarding this?). The company I am working for (haslerrail.com) is strongly considering to use emdebian to replace the Elinos distribution and curious about this demo.
Actually cross compiling the kernel with emdebian tools should be quite
Assuming they are correctly installed and configured (ie
"arm-linux-gnu-gcc" actually runs the compiler).
There are several ways of cross compiling documented as comments in the
My prefered one is to modify the makefile like so:
@@ -190,8 +190,8 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e
# Default value for CROSS_COMPILE is not to prefix executables
# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
export KBUILD_BUILDHOST := $(SUBARCH)
-ARCH ?= $(SUBARCH)
+ARCH ?= arm
+CROSS_COMPILE ?= arm-linux-gnu-
# Architecture as present in compile.h
UTS_MACHINE := $(ARCH)
@@ -311,7 +311,7 @@ include $(srctree)/scripts/Kbuild.include
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
-CC = $(CROSS_COMPILE)gcc
+CC = ccache $(CROSS_COMPILE)gcc
CPP = $(CC) -E
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
To use the second hunk you'll have to install the "ccache" package but
that will substantially speed up all the compilations other than the
Once you've done that its normal "make config/xconfig, make, make
Unfortunately that's the easy part...
Things may be a little trickier depending on your exact board type.
Current kernels already support the PXA270 and several common boards
based on it.
If you have a specific board however you may need to write a little
board specific code. For an example of that take a look at
arch/arm/mach-pxa/imote2.c. This code must contain the MACHINE_START
macro which defines important parameters and any required hardware
configuration tables (serial ports, GPIOs, ...)
If you need to do this you will need to obtain a "machine type" number
Note that regardless of whether you created your own board specific
setup code or not (maybe an existing one is close enough) there is
always a machine type number known to both the kernel AND the boot
loader. The two must match if the kernel is to boot!! [For your first
attempts you'll probably want to enable low level serial debugging
(CONFIG_DEBUG_LL) and have a serial port attached].
For lots of useful info on arm specific issues such as these see
Once you've got a zImage most bootloaders (certainly uboot which I
believe you are using) support transferring the image into RAM via TFTP
and booting from there - this will let you test things without touching
To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org