[DNX#2006040142000151] [U-Boot-Users] Debugging U-Boot on arm920t using B [...]

[DENX Support System]

Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006040142000151] was created:

<snip>
> First Question:
> 
> If I have understood everything correctly, u-boot ALWAYS relocates
> itselfs to RAM.
> 
> This is the code in Start.S in cpu/arm920t that makes the relocation.
> 
> relocate:				/* relocate U-Boot to RAM	    */
> 	adr	r0, _start		/* r0 <- current position of code   */
> 	ldr	r1, _TEXT_BASE		/* test if we run from flash or RAM */
> 	cmp     r0, r1                  /* don't reloc during debugaitor
> 
> This is how I get the values that _start and _TEXT_BASE take:
> 
> arm-unknown-linux-gnu-gdb u-boot
> GNU gdb 6.2.1
> Copyright 2004 Free Software Foundation, Inc.
> ...
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=arm-unknown-linux-gnu"...
> (gdb) info address _start
> Symbol "_start" is at 0x8f00000 in a file compiled without debugging.
> (gdb) info address _TEXT_BASE
> Symbol "_TEXT_BASE" is at 0x8f00040 in a file compiled without
> debugging.
> (gdb) x/1xw 0x8f00040
> 0x8f00040 <_TEXT_BASE>: 0x08f00000
> (gdb)                      
> 
> Both addresses TEXT_BASE & _start are SDRAM. According to this, this
> code will never relocate. Is this correct ?.
> 
> u-boot$ arm-unknown-linux-gnu-objdump -h  u-boot
> u-boot:     file format elf32-littlearm
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         000138a4  08f00000  08f00000  00008000  2**5
> 
> What I conclude is that the binary is prepared to be loaded and executed
> only from SDRAM. In fact, IŽve loaded u-boot in sdram (0x8f00000) using
> bdi2000, I have defined CONFIG_SKIP_LOWLEVEL_INIT and
> CONFIG_SKIP_RELOCATE_UBOOT and I have been able to debug u-boot using
> gdb. I know this is not the right way to debug u-boot.
> 
> In conclusion, there are two things I don't understand:
> 
>  * I think that LMA address of text section should be Flash 0x10000000. 
>  Because the code must be loaded in non-volatile memory. VMA of course, 
> should be SDRAM 0x8f00000.
> 
>  * I think that the code that
> makes the relocation must be loaded and executed from flash.
> VMA 0x10000000 and LMA 0x10000000. 
> 
> Second Question.
> 
> You have told me that:
> 
> > But for that you have to tell the debugger  that  the code is  running    > from  an  address  that is different from the link address). 
> 
> This is what IŽve done:
> 
> iim at viggen:~/.../u-boot-1.1.3$ arm-unknown-linux-gnu-gdb u-boot GNU gdb
> 6.3 ...
> This GDB was configured as "--host=i686-pc-linux-gnu
> --target=arm-unknown-linux-gnu"...
> (gdb) symbol-file
> Discard symbol table from `/.../u-boot-1.1.3/u-boot'? (y or n) y No
> symbol file now.
> (gdb) add-symbol-file u-boot 0x0000
> add symbol table from file "u-boot" at
>         .text_addr = 0x0
> (y or n) y
> Reading symbols from /.../u-boot-1.1.3/u-boot...done.
> (gdb) b _start_armboot
> 
> Breakpoint 1 at 0x8f00394: file /.../u-boot-1.1.3/cpu/arm920t/start.S,
> line 435.
> (gdb) target remote 192.168.1.5:2001
> Remote debugging using 192.168.1.5:2001
> 0x08f001c0 in ?? ()
> (gdb) c
> Continuing.
> 
> But the breakpoint is still in sdram (0x8f00394), and the program
> doesnŽt stop in the breakpoint.
> 
> 
> Regards.
> 
> Ioritz.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
</snip>

Your U-Boot support team