[Qemu-devel] Debugging low level ARM with GDB

2006-08-20 Thread 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 (No

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

2006-03-27 Thread andrzej zaborowski
Hi, On 24/03/06, Dirk Behme <[EMAIL PROTECTED]> wrote: [...] > But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR > (0x1)? Adding You're looking at the values before the qemu internal bootloader is ran. This bootloader will correctly set PC to 0x1. > > env->regs[15] = KERNEL_LOAD

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

2006-03-27 Thread 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 > >>(0x1)? > > > > 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 >

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

2006-03-27 Thread 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 0x1. The linux kernel don't c

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

2006-03-24 Thread Dirk Behme
Paul Brook wrote: But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR (0x1)? 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 P

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

2006-03-24 Thread 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 mailing list Qemu-devel@nongnu.org http://lists.nongnu.

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

2006-03-24 Thread Paul Brook
> But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR > (0x1)? 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 lin

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

2006-03-24 Thread Schwarz, Konrad
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 e

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

2006-03-23 Thread 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 C

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

2006-03-23 Thread 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 0x1. The linux kernel don't care where they a

[Qemu-devel] Debugging low level ARM with GDB

2006-03-23 Thread 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: