qemu-devel
[Top][All Lists]
Advanced

[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);








reply via email to

[Prev in Thread] Current Thread [Next in Thread]