Re: [Qemu-devel] Debugging low level ARM with GDB

[Dirk Behme <dirk.behme@googlemail.com>]

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