[Qemu-devel] Debugging low level ARM with GDB

[Qemu-devel] Debugging low level ARM with GDB

[Dirk Behme]

Hello,

I'd like to debug low level ARM bootloader U-Boot using ARM
port of QEMU.

I use qemu-0.8.0-i386.tar.gz for this and start QEMU with

> qemu-system-arm -S -s -m 64 -net none -nographic -kernel 
u-boot.bin -monitor null -parallel null -serial null
Waiting gdb connection on port 1234

(Note: u-boot.bin is the binary one, u-boot used below is
the ELF version)

In another window I start ARM gdb, but seems that I'm not
able to step, disassemble etc:

uboot/u-boot-1.1.4> arm-linux-gdb
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=arm-linux".
(gdb) file u-boot
Reading symbols from uboot/u-boot-1.1.4/u-boot...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x00000000 in ?? ()
(gdb) info r
r0             0x0      0
r1             0x0      0
...
r12            0x0      0
sp             0x0      0
lr             0x0      0
pc             0x0      0
fps            0x0      0
cpsr           0x400001d3       1073742291
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) c
Continuing.

[pressing ctrl-c] Program received signal 0, Signal 0.
0x00018468 in ?? ()
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) info r
r0             0xfffecf00       -78080
r1             0x0      0
r2             0x100    256
r3             0x0      0
...
r6             0x0      0
r7             0x400    1024
r8             0x0      0
...
r11            0x0      0
r12            0x18064  98404
sp             0x0      0
lr             0x180f4  98548
pc             0x18468  99432
fps            0x0      0
cpsr           0x600001d3       1610613203
(gdb)

What do I miss here? Seems that program did something, but
I'm not able to debug it.

Two additional questions:

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?

If my program wants to access the serial ports, how do I have
to configure the serial driver in my program to access these
ports? E.g. which base address do I have to use in the
serial driver? In real HW they differ from chip to chip.

Many thanks and best regards,

Dirk

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

[Paul Brook]

> 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.

> If my program wants to access the serial ports, how do I have
> to configure the serial driver in my program to access these
> ports? E.g. which base address do I have to use in the
> serial driver? In real HW they differ from chip to chip.

Qemu emulates and ARM Integrator/CP baseboard and CM/926 or CM/1026 core 
module. Full documentation is available from http://www.arm.com/

Paul

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

[Dirk Behme]

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

[Paul Brook]

> But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
> (0x10000)?

What makes you think ti's wrong? There's a small bootloader built into qemu.

> 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

You're obviously using the wrong u-boot config then. 0x11080000 isn't even a 
RAM address.

Paul

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

[Dirk Behme]

Paul Brook wrote:
>>But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
>>(0x10000)?
> 
> 
> What makes you think ti's wrong? There's a small bootloader built into qemu.

Uups. Then it seems that I start things the wrong way. I 
start QEMU with -S -s, then I attach GDB, and GDB 
"complains" that PC is at 0x0 (and not 0x10000). How do I 
have to invoke things in the correct way (and that this 
bootloader is used)  so that system is at 0x10000 if I 
attach GDB and can start with si debugging from there?

>>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
> 
> 
> You're obviously using the wrong u-boot config then. 0x11080000 isn't even a 
> RAM address.

Yes, seems that I was unclear here. Sorry. It's for an other 
board. Take this question as the first step for a new 
machine description using integrator as an example.

Thanks for your help and patience!

Dirk

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

[Paul Brook]

On Friday 24 March 2006 16:51, Dirk Behme wrote:
> Paul Brook wrote:
> >>But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
> >>(0x10000)?
> >
> > What makes you think ti's wrong? There's a small bootloader built into
> > qemu.
>
> Uups. Then it seems that I start things the wrong way. I
> start QEMU with -S -s, then I attach GDB, and GDB
> "complains" that PC is at 0x0 (and not 0x10000). How do I
> have to invoke things in the correct way (and that this
> bootloader is used)  so that system is at 0x10000 if I
> attach GDB and can start with si debugging from there?

Sounds like it's working exactly as designed. You'll notice that the code at 
address zero eventually jumps to 0x10000.

Paul

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

[andrzej zaborowski]

Hi,

On 24/03/06, Dirk Behme <dirk.behme@googlemail.com> wrote:
[...]
> But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
> (0x10000)? Adding

You're looking at the values before the qemu internal bootloader is
ran. This bootloader will correctly set PC to 0x10000.

>
> 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
>
Yes, it is possible. With your changes you're allocating RAM at
KERNEL_LOAD_ADDR and then loading the binary at KERNEL_LOAD_ADDR bytes
from the beginning of RAM instead of relative to address 0x0. For an
example of emulation of a board with RAM mapped at address other than
0 you might want to look at the OMAP emulator in this file:
http://www.zabor.org/balrog/qemu-omap.patch

>  > 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);
>
>
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Regards,
Andrew
--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

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

[Daniel Jacobowitz]

On Thu, Mar 23, 2006 at 05:10:07PM +0100, Dirk Behme wrote:
> (gdb) s
> Cannot find bounds of current function
> (gdb) n
> Cannot find bounds of current function

Try using "si" and "ni" to step a single instruction.  But make sure
you can run it before you try to debug it.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Schwarz, Konrad]

[-- Attachment #1.1: Type: text/plain, Size: 930 bytes --]

Hi,
 
One of the changes I would like to contribute (assuming my company gives
the ok) is a somewhat improved reader for ELF executables, and returns
the entry point.  Although somewhat useless for the bootstrap program
(which must start at the processor's reset address), this is useful to
emulate the actions of a ELF loader, such as included in a boot loader.
However, the current design of QEMU hardcodes the image reading strategy
within the "machine" abstraction (a "machine" is what a "board-support
package" typically targets), so if you would like to use this different
loader in a given machine, you will have to modify the "machine"
implementation.
 
The release process could take up to three weeks, but you might wish to
wait that long.
 
The serial port abstraction, and in particular their base addresses,
also materialize in the "machine" implementation.
 
Regards,
 
Konrad Schwarz
 
 
 

[-- Attachment #1.2: Type: text/html, Size: 2204 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Konrad Schwarz.vcf --]
[-- Type: text/x-vcard; name="Konrad Schwarz.vcf", Size: 650 bytes --]

BEGIN:VCARD
VERSION:2.1
N:Schwarz;Konrad
FN:Konrad Schwarz
ORG:Siemens AG;CT SE 2
TITLE:Principal Engineer
TEL;WORK;VOICE:+49 (89) 636-53579
TEL;WORK;FAX:+49 (89) 636-45450
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;53 518;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:53 518=0D=0ASiemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany
ADR;POSTAL;ENCODING=QUOTED-PRINTABLE:;;Siemens AG=0D=0ACT SE 2;M=FCnchen;;81730;Germany
LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Siemens AG=0D=0ACT SE 2=0D=0AM=FCnchen 81730=0D=0AGermany
EMAIL;PREF;INTERNET:konrad.schwarz@siemens.com
REV:20060130T101011Z
END:VCARD

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

[Paul Brook]

> The serial port abstraction, and in particular their base addresses,
> also materialize in the "machine" implementation.

Of course they do. It's a machine specific property.

Paul

[Qemu-devel] Debugging low level ARM with GDB

[Dirk Behme]

Hello,

I'd like to debug low level ARM bootloader U-Boot using ARM 
port of QEMU.

I use qemu-0.8.0-i386.tar.gz for this and start QEMU with

 > qemu-system-arm -S -s -m 64 -net none -nographic -kernel 
u-boot.bin -monitor null -parallel null -serial null
Waiting gdb connection on port 1234

(Note: u-boot.bin is the binary one, u-boot used below is 
the ELF version)

In another window I start ARM gdb, but seems that I'm not 
able to step, disassemble etc:

uboot/u-boot-1.1.4> arm-linux-gdb
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu 
--target=arm-linux".
(gdb) file u-boot
Reading symbols from uboot/u-boot-1.1.4/u-boot...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x00000000 in ?? ()
(gdb) info r
r0             0x0      0
r1             0x0      0
...
r12            0x0      0
sp             0x0      0
lr             0x0      0
pc             0x0      0
fps            0x0      0
cpsr           0x400001d3       1073742291
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) c
Continuing.

[pressing ctrl-c] Program received signal 0, Signal 0.
0x00018468 in ?? ()
(gdb) s
Cannot find bounds of current function
(gdb) n
Cannot find bounds of current function
(gdb) info r
r0             0xfffecf00       -78080
r1             0x0      0
r2             0x100    256
r3             0x0      0
...
r6             0x0      0
r7             0x400    1024
r8             0x0      0
...
r11            0x0      0
r12            0x18064  98404
sp             0x0      0
lr             0x180f4  98548
pc             0x18468  99432
fps            0x0      0
cpsr           0x600001d3       1610613203
(gdb)

What do I miss here? Seems that program did something, but 
I'm not able to debug it.

Two additional questions:

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?

If my program want to access the serial ports, how do I have 
to configure the serial driver in my program to access these 
ports? E.g. which base address do I have to use in the 
serial driver? In real HW they differ from chip to chip.

Many thanks and best regards,

Dirk