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
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
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
>
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
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
> 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.
> 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
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
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
> 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
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:
11 matches
Mail list logo