Hi Martin, 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 :)) Cheers, Marco -----Original Message----- From: Martin Fuzzey [mailto:[email protected]] Sent: Tue 2/17/2009 10:50 AM To: Hoefle Marco Cc: [email protected] 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. > > Marco > Hi Marco, Actually cross compiling the kernel with emdebian tools should be quite simple : 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 root Makefile. My prefered one is to modify the makefile like so: --- a/Makefile +++ b/Makefile @@ -190,8 +190,8 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \ # 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) -CROSS_COMPILE ?= +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 first one. Once you've done that its normal "make config/xconfig, make, make zImage). 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 (see arch/arm/tools/mach-types) 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 Documentation/arm 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 flash. Good luck! Martin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
