I just got the first kernel panic in the ECB_AT91 with Linux 2.6.20. I learnt a lot trying to get it. We support Linux 2.6.17, but it's kinda old. So, we need to support a newer version of the kernel.
You don't know how happy you can feel when you can get a kernel panic after so many hours reading code and after endless futile booting with no kernel output ... I did a lot of things wrong before getting this kernel panic. I even had a broken copy of u-boot that I compiled that made me waste many hours.
How not to do it:
- Waste a lot of time trying to port right away from Linux 2.6.7 to Linux 2.6.20
How to do it:
- Take Linux 2.6.17 and get a minimal .config that results in a kernel panic
- Then go to the starting code and try to remove a lot of code and still get a kernel panic
- It will help you know what to look for
- It's arch/arm/mach-at91rm9200/board-dk.c
- We're overwriting this file. I will create a board-ecbat91.c in 2.6.20 and an entry that you can select in "make menuconfig"
- Go to the newer version that has most patches integrated and use the old .config to get a panic
- Fix some silly code to make it compile
- Notice how much time you wasted with the wrong approach
- Write a blog post about it
In the end, it seems so simple :) Just for the record, I'll put the instructions that say how to get the kernel panic.
tar xjf ../linux-2.6.20.tar.bz2 cd linux-2.6.20
Add the patch.
$ cat ../2.6.20.panic.patch | patch -p1 patching file arch/arm/mach-at91rm9200/board-dk.c patching file .config
Enable ccache in the Makefile (optional if you like to waste time, mandatory if you're impatient) – Well, for a single compilation it does not matter, but you should use ccache... I just wanted to advertise it.
CC = ccache $(CROSS_COMPILE)gcc CPP = ccache $(CC) -E
Compile Linux.
crossmake -j2 vmlinux
And the rest just like in the instructions.
The result:
ecb_at91 >tftp
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'ecb_at91.img'.
Load address: 0x20200000
Loading: #################################################################
########################################
done
Bytes transferred = 534902 (82976 hex)
ecb_at91 >boot
## Booting image at 20200000 ...
Image Name: Linux Kernel Image
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 534838 Bytes = 522.3 kB
Load Address: 20008000
Entry Point: 20008000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Linux version 2.6.20 (n@gaira) (gcc version 3.4.5) #1 Tue Feb 6 05:07:49 COT 2007
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
Machine: Atmel AT91RM9200-DK
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists. Total pages: 4064
Kernel command line: mem=32M rootfstype=reiserfs root=/dev/mmcblk0p1 console=ttyS0,115200n8
AT91: 128 gpio irqs in 4 banks
PID hash table entries: 128 (order: 7, 512 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 32MB = 32MB total
Memory: 31284KB available (960K code, 140K data, 56K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
io scheduler noop registered
io scheduler anticipatory registered (default)
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a ATMEL_SERIAL
mice: PS/2 mouse device common for all mice
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Thanks to Carlos Camargo for his help.
So, soon we will support the latest kernel. The support for this procesor is rather mature now in Linux.
Discussion (2)Last update: 2007-06-02 (Rev 11536)