[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Debugging low level ARM with GDB
From: |
Dirk Behme |
Subject: |
Re: [Qemu-devel] Debugging low level ARM with GDB |
Date: |
Fri, 24 Mar 2006 16:46:42 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20050923) |
Paul Brook wrote:
If I load the binary version of image u-boot.bin into QEMU,
how does QEMU know to which start address the image was
linked to? Or do I have to load the ELF file?
qemu assumes it's loading a raw binary kernel zImage. Currently it is loaded
at 0x10000. The linux kernel don't care where they are loaded, so this may
change in the future.
If you configure u-boot for a base address of 0x1000 it will probably work.
Thanks!
I linked u-boot to 0x10000 and it was loaded correctly:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x00000000 in ?? ()
(gdb) info register
r0 0x0 0
...
pc 0x0 0
fps 0x0 0
cpsr 0x400001d3 1073742291
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) disassemble 0x10000
Dump of assembler code for function _start:
0x00010000 <_start+0>: b 0x10050 <reset>
...
But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
(0x10000)? Adding
env->regs[15] = KERNEL_LOAD_ADDR;
in hw/integratorcp.c after load_image(kernel_filename,...)
did the job:
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
_start ()
at u-boot-1.1.4/cpu/arm926ejs/start.S:54
54 b reset
(gdb) info registers
r0 0x0 0
...
lr 0x0 0
pc 0x10000 65536
fps 0x0 0
cpsr 0x400001d3 1073742291
(gdb) disassemble
Dump of assembler code for function _start:
0x00010000 <_start+0>: b 0x10050 <reset>
...
and si works. Do I still miss anything here?
Then I tried the other way around: Instead of adapting
u-boot, it should be possible to adapt hw/integratorcp.c to
the address u-boot is linked to by default. This is
0x11080000. For my changes see below. With this, I get
> qemu-system-arm -S -s -kernel u-boot.bin -m 64
qemu: could not load kernel 'u-boot.bin'
Any ideas? Maybe anything with phys_ram_base? Do I have to
adjust
kernel_size = load_image(kernel_filename,
phys_ram_base + KERNEL_LOAD_ADDR);
as well?
Best regards
Dirk
--- ./hw/integratorcp.c_orig 2006-03-24
16:40:23.000000000 +0100
+++ ./hw/integratorcp.c 2006-03-24 16:39:35.000000000 +0100
@@ -10,7 +10,8 @@
#include <vl.h>
#define KERNEL_ARGS_ADDR 0x100
-#define KERNEL_LOAD_ADDR 0x00010000
+//#define KERNEL_LOAD_ADDR 0x00010000
+#define KERNEL_LOAD_ADDR 0x11080000
#define INITRD_LOAD_ADDR 0x00800000
/* Stub functions for hardware that doesn't exist. */
@@ -1188,7 +1189,7 @@ static void integratorcp_init(int ram_si
/* ??? On a real system the first 1Mb is mapped as
SSRAM or boot flash. */
/* ??? RAM shoud repeat to fill physical memory space. */
/* SDRAM at address zero*/
- cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);
+ cpu_register_physical_memory(KERNEL_LOAD_ADDR,
ram_size, IO_MEM_RAM);
/* And again at address 0x80000000 */
cpu_register_physical_memory(0x80000000, ram_size,
IO_MEM_RAM);
@@ -1223,6 +1224,7 @@ static void integratorcp_init(int ram_si
fprintf(stderr, "qemu: could not load kernel
'%s'\n", kernel_filename);
exit(1);
}
+ env->regs[15] = KERNEL_LOAD_ADDR;
if (initrd_filename) {
initrd_size = load_image(initrd_filename,
phys_ram_base +
INITRD_LOAD_ADDR);
Re: [Qemu-devel] Debugging low level ARM with GDB, Daniel Jacobowitz, 2006/03/23