[U-Boot-Users] u-boot and linux-2.6.9
I am trying to boot on an ARM-Integrator AP a linux-2.6.9 kernel with u-boot. I tried u-boot-1.1.1 stable and cvs, but both result in "data abort" just at the point of "Starting kernel .... ". Here is the dump from minicom:
Integrator-AP # bootm 24400000 Boot reached stage 1 ## Booting image at 24400000 ... Boot reached stage 2 Boot reached stage 3 Image Name: Linux-2.6.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1216080 Bytes = 1.2 MB Load Address: 00008000 Entry Point: 00008000 Boot reached stage 4 Boot reached stage 5 Boot reached stage 6 OK Boot reached stage 7 Boot reached stage 8 Boot reached stage 14 No initrd Boot reached stage 15 ## Transferring control to Linux (at address 00008000) ...
Starting kernel ...
data abort pc : [<0000801c>] lr : [<0100bcbc>] sp : 00fd7bd4 ip : 00fd7bc4 fp : 00fd7c10 r10: 00000000 r9 : 00fd7c84 r8 : 00fd7fdc r7 : 0100f1b4 r6 : 0100f1b4 r5 : 00000000 r4 : 24400040 r3 : e1a00001 r2 : 00000100 r1 : e1a00000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Has anyone succeeded in booting a 2.6.x kernel with u-boot?
Kind greetings,
Jean-Paul Saman
jean-paul.saman@philips.com schreibt:
Integrator-AP # bootm 24400000
Boot reached stage 1
## Booting image at 24400000 ...
Boot reached stage 2
Boot reached stage 3
Image Name: Linux-2.6.9
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1216080 Bytes = 1.2 MB
Load Address: 00008000
^^^^^^^^
That load address looks rather low for an ARM system; are you sure you have RAM there?
Cheers Anders
In message OFA94675DE.B9E9439A-ONC1256F70.004A5D92-C1256F70.004AEC93@philips.com you wrote:
Image Name: Linux-2.6.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1216080 Bytes = 1.2 MB Load Address: 00008000 Entry Point: 00008000
What does your memory map look like? Is there really RAM at this address?
--=_alternative 004AEC8CC1256F70_= Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">I am trying to boot on an ARM-Integrator
Will you please stop posting HTML messages to this mailing list? Thanks.
Wolfgang Denk
Integrator-AP # bootm 24400000
What core mdoule are you using?
Image Name: Linux-2.6.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1216080 Bytes = 1.2 MB Load Address: 00008000 Entry Point: 00008000
By default IntegratorAP has SDRAM starting at 0.
data abort
pc : [<0000801c>] lr : [<0100bcbc>] sp : 00fd7bd4 ip : 00fd7bc4 fp : 00fd7c10 r10: 00000000 r9 : 00fd7c84 r8 : 00fd7fdc r7 : 0100f1b4 r6 : 0100f1b4 r5 : 00000000 r4 : 24400040 r3 : e1a00001 r2 : 00000100 r1 : e1a00000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
The data abort may not be caused by linux code, though the PC shows execution is at 0x801c. Instead incompatible cache clear instruction will cause this abort. Check the implementation of cleanup_before_linux() on your CPU and make sure the cache is disabled using the right instruction.
Regards, -Shawn.
On Mon, Dec 20, 2004 at 02:37:25PM +0100, jean-paul.saman@philips.com wrote:
I am trying to boot on an ARM-Integrator AP a linux-2.6.9 kernel with u-boot. I tried u-boot-1.1.1 stable and cvs, but both result in "data abort" just at the point of "Starting kernel .... ". Here is the dump from minicom:
Integrator-AP # bootm 24400000 Boot reached stage 1 ## Booting image at 24400000 ... Boot reached stage 2 Boot reached stage 3 Image Name: Linux-2.6.9 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1216080 Bytes = 1.2 MB Load Address: 00008000 Entry Point: 00008000 Boot reached stage 4 Boot reached stage 5 Boot reached stage 6 OK Boot reached stage 7 Boot reached stage 8 Boot reached stage 14 No initrd Boot reached stage 15 ## Transferring control to Linux (at address 00008000) ...
Starting kernel ...
data abort pc : [<0000801c>] lr : [<0100bcbc>]
That is a rather odd address to have an abort at assuming you're using the uImage obtained from `make uImage` because there are normally NOPs from 0x8000 through 0x801f, e.g.
../BUILD/integrator/default/arch/arm/boot/compressed/vmlinux: file format elf32-littlearm
Disassembly of section .text:
00000000 <start>: 0: e1a00000 nop (mov r0,r0) 4: e1a00000 nop (mov r0,r0) 8: e1a00000 nop (mov r0,r0) c: e1a00000 nop (mov r0,r0) 10: e1a00000 nop (mov r0,r0) 14: e1a00000 nop (mov r0,r0) 18: e1a00000 nop (mov r0,r0) 1c: e1a00000 nop (mov r0,r0) 20: ea000002 b 30 <_text+0x30>
sp : 00fd7bd4 ip : 00fd7bc4 fp : 00fd7c10 r10: 00000000 r9 : 00fd7c84 r8 : 00fd7fdc r7 : 0100f1b4 r6 : 0100f1b4 r5 : 00000000 r4 : 24400040 r3 : e1a00001 r2 : 00000100 r1 : e1a00000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
Has anyone succeeded in booting a 2.6.x kernel with u-boot?
FWIW, I just booted 2.6.10-rc3 bk latest on IntegratorAP with ARM920T processor module using latest u-boot CVS:
Integrator-AP # bootm 0x800000 ## Booting image at 00800000 ... Image Name: Linux-2.6.10-rc3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1199040 Bytes = 1.1 MB Load Address: 00008000 Entry Point: 00008000 OK No initrd ## Transferring control to Linux (at address 00008000) ...
Starting kernel ...
Uncompressing Linux.................................................................................. done, booting the kernel. Linux version 2.6.10-rc3 (gdavis@localhost) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #6 Mon Dec 20 14:46:41 EST 2004 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU: D VIVT write-back cache CPU: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: ARM-Integrator Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: console=ttyAM0,38400n8 root=/dev/nfs ip=bootp mem=32M PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 29696KB available (1864K code, 458K data, 308K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 PCI: bus0: Fast back to back transfers disabled PCI: bus1: Fast back to back transfers enabled PCI: Bus 1, bridge: 0000:00:09.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. NetWinder Floating Point Emulator V0.97 (double precision) Installing knfsd (copyright (C) 1996 okir@monad.swb.de). JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc. matroxfb: Matrox Millennium II (PCI) detected matroxfb: 640x480x8bpp (virtual: 640x13081) matroxfb: framebuffer at 0x50000000, mapped to 0xc2880000, size 8388608 fb0: MATROX frame buffer device fb0: initializing hardware Serial: AMBA driver $Revision: 1.41 $ ttyAM0 at MMIO 0x16000000 (irq = 1) is a AMBA ttyAM1 at MMIO 0x17000000 (irq = 2) is a AMBA io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) e100: Intel(R) PRO/100 Network Driver, 3.2.3-k2-NAPI e100: Copyright(c) 1999-2004 Intel Corporation e100: eth0: e100_probe: addr 0x40908000, irq 16, MAC addr 00:03:47:95:50:65 elevator: using anticipatory as default io scheduler mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 e100: eth0: e100_watchdog: link up, 10Mbps, half-duplex Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 192.168.1.103, my address is 192.168.1.84 IP-Config: Complete: device=eth0, addr=192.168.1.84, mask=255.255.255.0, gw=192.168.1.1, host=192.168.1.84, domain=, nis-domain=(none), bootserver=192.168.1.103, rootserver=192.168.1.103, rootpath=/tftpboot/integrator Looking up port of RPC 100003/2 on 192.168.1.103 Looking up port of RPC 100005/1 on 192.168.1.103 VFS: Mounted root (nfs filesystem). INIT: version 2.78 booting Activating swap... Checking all file systems... fsck 1.27 (8-Mar-2002) Calculating module dependencies... done. Loading modules: Mounting local filesystems... nothing was mounted Cleaning: /etc/network/ifstate. Setting up IP spoofing protection: rp_filter. Disable TCP/IP Explicit Congestion Notification: done. Configuring network interfaces: done. Starting portmap daemon: portmap. Mounting remote filesystems... Cleaning: /tmp /var/lock /var/run. INIT: Entering runlevel: 3 Starting kernel log daemon: klogd. Starting system log daemon: syslogd. Starting internet superserver: inetd.
MontaVista(R) Linux(R) Professional Edition 3.1
192.168.1.84 login:
Kind greetings,
Jean-Paul Saman
-- Regards, George
On my ARM integrator AP board with ARM920T u-boot CvS does not start the Linux kernel. Maybe it is a configuration or toolchain problem?
I use gcc 2.95.3 from www.arm.linux.org.uk to compile u-boot and load u-boot.bin on the ARM Integrator AP flash. The kernel is a uImage and works with the u-boot bootloader from ARM Ltd.
I found that gcc release-3.4.0 from codesourcery is unable to compile u-boot..
What compiler are you guys using? What additional configuration did you do after: make ARCH=arm CROSS_COMPILE=arm-linux- integratorap_config?
Kind greetings,
Jean-Paul Saman
On Tue, Dec 21, 2004 at 11:40:28AM +0100, jean-paul.saman@philips.com wrote:
On my ARM integrator AP board with ARM920T u-boot CvS does not start the Linux kernel. Maybe it is a configuration or toolchain problem?
I use gcc 2.95.3 from www.arm.linux.org.uk to compile u-boot and load u-boot.bin on the ARM Integrator AP flash.
I tested u-boot built using that very same toolchain and did not notice any problems here. However, it is worth noting that U-Boot support for the Integrator/AP currently assumes use of an ARM926 processor module. But I don't see any obvious use of ARM926 features which would cause problems for ARM920T processor module, i.e. it should work.
The kernel is a uImage and works with the u-boot bootloader from ARM Ltd.
That's odd, I wonder what magic the ARM Ltd. U-Boot has that current CVS lacks? : P
I found that gcc release-3.4.0 from codesourcery is unable to compile u-boot..
Because it includes gcc-4 command line switch changes related to ARM ABI changes, IIUC. It's been reported on these lists already.
What compiler are you guys using?
Various. Other than the gcc-4 related ARM ABI changes included in the above CSL toolchain, I haven't noticed any toolchain related problems. FWIW, I've recently used gcc 2.95.3 and 3.3.1 and do not see any problems here.
What additional configuration did you do after: make ARCH=arm CROSS_COMPILE=arm-linux- integratorap_config?
The "ARCH=arm" is not needed. Otherwise, I use the same command as you have above with no changes to CVS current. Works for me. : )
Hmm... I just tested autobooting U-Boot, S1-1 ON and S1-4 OFF, and in this case I get:
Integrator-AP # bootm 0x800000 ## Booting image at 00800000 ... Image Name: Linux-2.6.10-rc3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1193108 Bytes = 1.1 MB Load Address: 00008000 Entry Point: 00008000 OK No initrd ## Transferring control to Linux (at address 00008000) ...
Starting kernel ...
Uncompressing Linux.................................................................................. done, booting the kernel. Linux version 2.6.10-rc3 (gdavis@davisg.ne.client2.attbi.com) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #9 Tue Dec 21 14:50:36 EST 2004 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) CPU: D VIVT write-back cache CPU: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Machine: ARM-Integrator Memory policy: ECC disabled, Data cache writeback <7>On node 0 totalpages: 8192 <7> DMA zone: 8192 pages, LIFO batch:2 <7> Normal zone: 0 pages, LIFO batch:1 <7> HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=ttyAM0,38400n8 root=/dev/nfs ip=bootp mem=32M <7>Relocating machine vectors to 0xffff0000 PID hash table entries: 256 (order: 8, 4096 bytes) <1>Unhandled fault: external abort on non-linefetch (0x02a) at 0xee0003da <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 <1>pgd = c0004000 <1>[00000000] *pgd=00000000 Internal error: Oops: 5 [#1] Modules linked in: CPU: 0 PC is at kmem_cache_alloc+0x18/0x48 LR is at __sigqueue_alloc+0x38/0xa4 pc : [<c008e94c>] lr : [<c0074694>] Not tainted sp : c0225e7c ip : c0225e90 fp : c0225e8c r10: 00000001 r9 : 600000d3 r8 : 200000d3 r7 : c0226c7c r6 : 00000007 r5 : 00000000 r4 : 800000d3 r3 : c02836b8 r2 : 800000d3 r1 : 00000020 r0 : 00000000 Flags: Nzcv IRQs off FIQs off Mode SVC_32 Segment kernel Control: C000717F Table: 00004000 DAC: 0000001D Process swapper (pid: 0, stack limit = 0xc0224190) Stack: (0xc0225e7c to 0xc0226000) 5e60: c0226a6c 5e80: c0225ea0 c0225e90 c0074694 c008e944 00000001 c0225ec0 c0225ea4 c00750d8 5ea0: c007466c 00000001 c0226a6c 00000007 00000000 c0225ee0 c0225ec4 c007528c 5ec0: c00750b8 00000007 c0226a6c 00000006 00000023 c0225f08 c0225ee4 c0075374 5ee0: c007520c 0000002a c0224000 c02274b0 ee0003da c0225f30 000228ac c0225f2c 5f00: c0225f0c c005ca04 c00752e8 c027c300 c0225f64 c027c368 c0227204 c028f51c 5f20: c0225f98 c0225f30 c00552e4 c005c9a4 00000000 00000000 ee0003c0 ee0003da 5f40: c020a39c 00000000 c027c368 c0227204 c028f51c 41129200 000228ac c0225f98 5f60: c0228220 c0225f78 c0228238 c001aa28 600000d3 ffffffff c0022dc0 00000000 5f80: c027c368 00000000 c0226fac c0225fc0 c0225f9c c001d040 c001a88c c0145c8c 5fa0: c0022dc0 c0022dc4 c027c368 c027c32c c0226fac c0225fd8 c0225fc4 c001c72c 5fc0: c001d01c c0297cd8 c0297cd8 c0225ffc c0225fdc c00088c0 c001c70c c0008548 5fe0: c027c378 c0297cd8 c0297cd8 c027c368 00000000 c0226000 c0008080 c0008834 Backtrace: [<c008e934>] (kmem_cache_alloc+0x0/0x48) from [<c0074694>] (__sigqueue_alloc+0x38/0xa4) r4 = C0226A6C [<c007465c>] (__sigqueue_alloc+0x0/0xa4) from [<c00750d8>] (send_signal+0x30/0x154) r4 = 00000001 [<c00750a8>] (send_signal+0x0/0x154) from [<c007528c>] (specific_send_sig_info+0x90/0xdc) r7 = 00000000 r6 = 00000007 r5 = C0226A6C r4 = 00000001 [<c00751fc>] (specific_send_sig_info+0x0/0xdc) from [<c0075374>] (force_sig_info+0x9c/0xa4) r7 = 00000023 r6 = 00000006 r5 = C0226A6C r4 = 00000007 [<c00752d8>] (force_sig_info+0x0/0xa4) from [<c005ca04>] (do_DataAbort+0x70/0xa0) [<c005c994>] (do_DataAbort+0x0/0xa0) from [<c00552e4>] (__dabt_svc+0x44/0x60) r8 = C028F51C r7 = C0227204 r6 = C027C368 r5 = C0225F64 r4 = C027C300 [<c001a87c>] (vgacon_startup+0x0/0x3cc) from [<c001d040>] (con_init+0x34/0x288) r8 = C0226FAC r7 = 00000000 r6 = C027C368 r5 = 00000000 r4 = C0022DC0 [<c001d00c>] (con_init+0x0/0x288) from [<c001c72c>] (console_init+0x30/0x48) r8 = C0226FAC r7 = C027C32C r6 = C027C368 r5 = C0022DC4 r4 = C0022DC0 [<c001c6fc>] (console_init+0x0/0x48) from [<c00088c0>] (start_kernel+0x9c/0x1b4) r5 = C0297CD8 r4 = C0297CD8 [<c0008824>] (start_kernel+0x0/0x1b4) from [<c0008080>] (__mmap_switched+0x0/0x40) r6 = C027C368 r5 = C0297CD8 r4 = C0297CD8 Code: e24cb004 e10f4000 e3842080 e121f002 (e5902000) <0>Kernel panic - not syncing: Attempted to kill the idle task!
Oops! 8 )
This appears to be due to the fact that the ARM bootMonitor is not fully initialising the PCI subsystem for the autoboot case. Hence, Linux oopses touching the VGA console because it does not fully initialise PCI either, I guess.
FWIW, the kernel oops above is resolved by enabling Integrator PCI support in U-Boot. Here's what I did to enable Integrator PCI support in U-Boot:
Index: u-boot/include/configs/integratorap.h =================================================================== --- u-boot.orig/include/configs/integratorap.h +++ u-boot/include/configs/integratorap.h @@ -65,18 +65,14 @@ #define CFG_SERIAL0 0x16000000 #define CFG_SERIAL1 0x17000000
-/*#define CONFIG_COMMANDS (CFG_CMD_DHCP | CFG_CMD_IMI | CFG_CMD_NET | CFG_CMD_PING | CFG_CMD_BDI | CFG_CMD_PCI) */ -/*#define CONFIG_NET_MULTI */ -/*#define CONFIG_BOOTP_MASK CONFIG_BOOTP_DEFAULT */ - -#define CONFIG_COMMANDS (CFG_CMD_IMI | CFG_CMD_BDI | CFG_CMD_MEMORY) - +#define CONFIG_COMMANDS (CONFIG_CMD_DFL | CFG_CMD_DHCP | CFG_CMD_PING | CFG_CMD_PCI) +#define CONFIG_NET_MULTI
/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */ #include <cmd_confdefs.h>
#define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGS "root=/dev/mtdblock0 mem=32M console=ttyAM0 console=tty" +#define CONFIG_BOOTARGS "root=/dev/mtdblock0 console=ttyAM0 console=tty" #define CONFIG_BOOTCOMMAND ""
/* @@ -131,10 +136,9 @@ * PCI definitions */
-/*#define CONFIG_PCI /--* include pci support */ -#undef CONFIG_PCI_PNP +#define CONFIG_PCI +#define CONFIG_PCI_PNP #define CONFIG_PCI_SCAN_SHOW 1 /* show pci devices on startup */ -#define DEBUG
#define CONFIG_EEPRO100 #define CFG_RX_ETH_BUFFER 8 /* use 8 rx buffer on eepro100 */
-- Regards, George
In message 20041222053257.GF7494@mvista.com you wrote:
The kernel is a uImage and works with the u-boot bootloader from ARM Ltd.
That's odd, I wonder what magic the ARM Ltd. U-Boot has that current CVS lacks? : P
That's easy to find out: just run a diff over the sources. They did give you the sources, didn't they?
Best regards,
Wolfgang Denk
participants (5)
-
Anders Larsen -
George G. Davis -
jean-paul.saman＠philips.com -
Shawn Jin -
Wolfgang Denk