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: andrzej zaborowski
Subject: Re: [Qemu-devel] Debugging low level ARM with GDB
Date: Mon, 27 Mar 2006 21:48:06 +0200

Hi,

On 24/03/06, Dirk Behme <address@hidden> 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
> address@hidden
> 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

reply via email to

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