[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Tetsuyuki Kobayashi]

Hello,

U-Boot from NOR flash relocates itself to RAM erea. The relocation address is
calaculated at runtime to get maxium contiguous space to load kernel. So it may
vary after code changed. In the early debug phase it would be easier to handle
if the relocation address does not change per build.

My idea is define fixed address as CONFIG_DEBUG_RELOC_FIX_ADDR in config file
and relocate to the address. Then you don't need to execute 'bdinfo' command to
get actual relocated address. It is done by the first patch.

The second patch is for u-boot_r, which is linked for fixed relocation address.
When you want to symbolic debug after relocation, flash 'u-boot.bin' and
load symbol from 'u-boot_r' to debugger.
(CF. When you want to symblic debug before relocation, load symbol from 'u-boot'
 to debugger.)

This patch set is based on v2013.01-rc1. (Tell me if I should rebase.)
This is for ARM, but similar change could apply for other arch.


Tetsuyuki Kobayashi (2):
  DEBUG: fix relocation address
  DEBUG: make u-boot_r which is linked for fixed relocation address

 Makefile                |    7 +++++--
 arch/arm/lib/board.c    |    9 ++++++++-
 config.mk               |    5 +++++
 include/configs/kzm9g.h |    4 ++++
 4 files changed, 22 insertions(+), 3 deletions(-)

-- 
1.7.9.5

[U-Boot] [PATCH 1/2] DEBUG: fix relocation address

[Tetsuyuki Kobayashi]

U-Boot from NOR flash relocates itself to RAM erea. The relocation address is
calaculated at runtime to get maxium contiguous space to load kernel. So it may
vary after code changed. In the early debug phase it would be easier to handle
if the relocation address does not change.
This patch sets relocation address to fixed address specified by
CONFIG_DEBUG_RELOC_FIX_ADDR. If there is no enough space after
CONFIG_DEBUG_RELOC_FIX_ADDR, it is ignored.
patch to kzm9g.h is a example. CONFIG_DEBUG_RELOC_FIX_ADDR should be defined at
each config file.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
---
 arch/arm/lib/board.c    |    9 ++++++++-
 include/configs/kzm9g.h |    4 ++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 92cad9a..340aa6e 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -377,7 +377,14 @@ void board_init_f(ulong bootflag)
 	addr &= ~(4096 - 1);
 
 	debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr);
-
+#ifdef CONFIG_DEBUG_RELOC_FIX_ADDR
+	if (addr >= CONFIG_DEBUG_RELOC_FIX_ADDR) {
+		addr = CONFIG_DEBUG_RELOC_FIX_ADDR;
+		debug("Fixing relocation address to %08lx\n", addr);
+	} else {
+		debug("CONFIG_DEBUG_RELOC_FIX_ADDR is ignored. It should be less than %08lx\n", addr);
+	}
+#endif
 #ifndef CONFIG_SPL_BUILD
 	/*
 	 * reserve memory for malloc() arena
diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index 4898fb6..f96ea3e 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -23,6 +23,10 @@
 
 #undef DEBUG
 
+/* Uncomment this to relocate to fixed address */
+/*#define CONFIG_DEBUG_RELOC_FIX_ADDR 0x5f800000 */
+
+
 #define CONFIG_RMOBILE
 #define CONFIG_SH73A0
 #define CONFIG_KZM_A9_GT
-- 
1.7.9.5

[U-Boot] [PATCH 1/2] DEBUG: fix relocation address

[Wolfgang Denk]

Dear Tetsuyuki Kobayashi,

In message <1353476660-18018-2-git-send-email-koba@kmckk.co.jp> you wrote:
> U-Boot from NOR flash relocates itself to RAM erea. The relocation address is
> calaculated at runtime to get maxium contiguous space to load kernel. So it may
> vary after code changed. In the early debug phase it would be easier to handle
> if the relocation address does not change.
> This patch sets relocation address to fixed address specified by
> CONFIG_DEBUG_RELOC_FIX_ADDR. If there is no enough space after
> CONFIG_DEBUG_RELOC_FIX_ADDR, it is ignored.
> patch to kzm9g.h is a example. CONFIG_DEBUG_RELOC_FIX_ADDR should be defined at
> each config file.
> 
> Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
> ---
>  arch/arm/lib/board.c    |    9 ++++++++-
>  include/configs/kzm9g.h |    4 ++++
>  2 files changed, 12 insertions(+), 1 deletion(-)

NAK for this patch for the general reasons outlined oin my summary
reply to the cover letter.

In addition:

- If this is supposed to be a RFC patch series, then please add the
  RFC part to ALL patches, not only to the cover letter.

- Any changes to basic infrastucture like this have to be done in a
  general, architecture-independent way.  Doing this for ARM only is
  not acceptable.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson

[U-Boot] [PATCH 2/2] DEBUG: make u-boot_r which is linked for fixed relocation address

[Tetsuyuki Kobayashi]

If CONFIG_DEBUG_RELOC_FIX_ADDR is defined, make u-boot_r.
u-boot_r is ELF file which is linked for fixed relocation address specified by
CONFIG_DEBUG_RELOC_FIX_ADDR. Feed this file to debugger to get relocated symbol
addresses.

Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
---
 Makefile  |    7 +++++--
 config.mk |    5 +++++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index bc15209..56d87cd 100644
--- a/Makefile
+++ b/Makefile
@@ -405,6 +405,9 @@ ALL-$(CONFIG_NAND_U_BOOT) += $(obj)u-boot-nand.bin
 ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
 ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
 ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
+ifneq ($(CONFIG_DEBUG_RELOC_FIX_ADDR),)
+ALL-y += $(obj)u-boot_r
+endif
 
 # enable combined SPL/u-boot/dtb rules for tegra
 ifeq ($(SOC),tegra20)
@@ -540,10 +543,10 @@ GEN_UBOOT = \
 		cd $(LNDIR) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) \
 			$$UNDEF_LST $(__OBJS) \
 			--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-			-Map u-boot.map -o u-boot
+			-Map u-boot.map -o $(notdir $@)
 endif
 
-$(obj)u-boot:	depend \
+$(obj)u-boot $(obj)u-boot_r:	depend \
 		$(SUBDIR_TOOLS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds
 		$(GEN_UBOOT)
 ifeq ($(CONFIG_KALLSYMS),y)
diff --git a/config.mk b/config.mk
index b7cd481..99b3b11 100644
--- a/config.mk
+++ b/config.mk
@@ -269,9 +269,14 @@ LDFLAGS += $(PLATFORM_LDFLAGS)
 LDFLAGS_FINAL += -Bstatic
 
 LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)
+LDFLAGS_u-boot_r := $(LDFLAGS_u-boot)
+
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
 LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
+ifneq ($(CONFIG_DEBUG_RELOC_FIX_ADDR),)
+LDFLAGS_u-boot_r += -Ttext $(CONFIG_DEBUG_RELOC_FIX_ADDR)
+endif
 
 LDFLAGS_u-boot-spl += -T $(obj)u-boot-spl.lds $(LDFLAGS_FINAL)
 ifneq ($(CONFIG_SPL_TEXT_BASE),)
-- 
1.7.9.5

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Wolfgang Denk]

Dear Tetsuyuki Kobayashi,

In message <1353476660-18018-1-git-send-email-koba@kmckk.co.jp> you wrote:
> 
> U-Boot from NOR flash relocates itself to RAM erea. The relocation address is
> calaculated at runtime to get maxium contiguous space to load kernel. So it may
> vary after code changed. In the early debug phase it would be easier to handle
> if the relocation address does not change per build.

No, it is not.  You still need to determine where it gets relocated to,
and iot makes no difference for debugging wehter you enter one number
or another one.

Any debugger out there today allows you to automatemost such
operations by scripts or functions or macros you can define to help
you doing that.

> My idea is define fixed address as CONFIG_DEBUG_RELOC_FIX_ADDR in config file
> and relocate to the address. Then you don't need to execute 'bdinfo' command to
> get actual relocated address. It is done by the first patch.

I'm not willing to accept such change.  It appears to ad a (minimal)
easement at first glance, but at the same time it bears potential to
break a large number of other things, and not unlikely in areas which
are why you need to run a debugger in the first place.

This makes no sense.

> The second patch is for u-boot_r, which is linked for fixed relocation address.
> When you want to symbolic debug after relocation, flash 'u-boot.bin' and
> load symbol from 'u-boot_r' to debugger.
> (CF. When you want to symblic debug before relocation, load symbol from 'u-boot'
>  to debugger.)

Why would that be needed?  The standard ELF file has all debug
information you ever may need.

Just to save the "load symbol table" command?   Again, this is not
worth the effort on one side, and likely to break things in other
places.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The net result is a system that is not only binary  compatible  with
4.3  BSD, but is even bug for bug compatible in almost all features."
- Avadit  Tevanian,  Jr.,  "Architecture-Independent  Virtual  Memory
Management  for  Parallel  and  Distributed  Environments:  The  Mach
Approach"

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Scott Wood]

On 11/21/2012 02:22:32 AM, Wolfgang Denk wrote:
> Dear Tetsuyuki Kobayashi,
> 
> In message <1353476660-18018-1-git-send-email-koba@kmckk.co.jp> you  
> wrote:
> >
> > U-Boot from NOR flash relocates itself to RAM erea. The relocation  
> address is
> > calaculated at runtime to get maxium contiguous space to load  
> kernel. So it may
> > vary after code changed. In the early debug phase it would be  
> easier to handle
> > if the relocation address does not change per build.
> 
> No, it is not.

Maybe not for you, but for some of us it definitely would make things  
easier.  I usually end up randomly peeking at some likely destinations  
until I find the expected content.

> You still need to determine where it gets relocated to,
> and iot makes no difference for debugging wehter you enter one number
> or another one.
> 
> Any debugger out there today allows you to automatemost such
> operations by scripts or functions or macros you can define to help
> you doing that.

Just because you've managed to compensate for it doesn't mean it isn't  
annoying.

How am I going to script gdb to figure out the relocation address when  
I'm just running it on the image to get symbols, not actually  
connecting to the target?

Is such a script published anywhere?

> > My idea is define fixed address as CONFIG_DEBUG_RELOC_FIX_ADDR in  
> config file
> > and relocate to the address. Then you don't need to execute  
> 'bdinfo' command to
> > get actual relocated address. It is done by the first patch.
> 
> I'm not willing to accept such change.  It appears to ad a (minimal)
> easement at first glance, but at the same time it bears potential to
> break a large number of other things, and not unlikely in areas which
> are why you need to run a debugger in the first place.
> 
> This makes no sense.
> 
> > The second patch is for u-boot_r, which is linked for fixed  
> relocation address.
> > When you want to symbolic debug after relocation, flash  
> 'u-boot.bin' and
> > load symbol from 'u-boot_r' to debugger.
> > (CF. When you want to symblic debug before relocation, load symbol  
> from 'u-boot'
> >  to debugger.)
> 
> Why would that be needed?  The standard ELF file has all debug
> information you ever may need.

If the symbols in the ELF ?file match where U-Boot is actually located,  
that avoids the need to manually apply the relocation offset every time  
you want to look at something.

> Just to save the "load symbol table" command?

Where would you get the symbol table to load that matches U-Boot  
post-relocation?

-Scott

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Henrik Nordström]

tis 2012-11-27 klockan 16:22 -0600 skrev Scott Wood:

> How am I going to script gdb to figure out the relocation address when  
> I'm just running it on the image to get symbols, not actually  
> connecting to the target?

It can be calculated from ram size and size of your u-boot binary
including bss (reported by size on the elf binary).

If you have u-boot running then bdinfo shows the address.

Hm.. wasn't there talk about a non-relocating u-boot binary for
debugging? Isn't that more appropriate for what you are trying to
accomplish?

> Where would you get the symbol table to load that matches U-Boot  
> post-relocation?

GDB supports symbol table relocation using add-symbol-file command.

Regards
Henrik

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Wolfgang Denk]

Dear Henrik Nordstr?m,

In message <1354059376.5475.6.camel@home.hno.se> you wrote:
> 
> > How am I going to script gdb to figure out the relocation address when  
> > I'm just running it on the image to get symbols, not actually  
> > connecting to the target?
> 
> It can be calculated from ram size and size of your u-boot binary
> including bss (reported by size on the elf binary).

This works only in very basic configurations of U-Boot.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A UNIX saleslady, Lenore,
Enjoys work, but she likes the beach more.
        She found a good way
        To combine work and play:
She sells C shells by the seashore.

[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

[Wolfgang Denk]

Dear Scott,

In message <1354054951.2317.14@tyr> you wrote:
>
> > > vary after code changed. In the early debug phase it would be  
> > easier to handle
> > > if the relocation address does not change per build.
> > 
> > No, it is not.
>
> Maybe not for you, but for some of us it definitely would make things  
> easier.  I usually end up randomly peeking at some likely destinations  
> until I find the expected content.

We have an entry with the relocation address in the global data
structure.  All you need to do is read that.  You can even do this
using a macro definition in GDB.  There is no magic involved.

> > Any debugger out there today allows you to automatemost such
> > operations by scripts or functions or macros you can define to help
> > you doing that.
>
> Just because you've managed to compensate for it doesn't mean it isn't  
> annoying.

You fail to understand, or see only your specific, limited set of use
cases.

> How am I going to script gdb to figure out the relocation address when  
> I'm just running it on the image to get symbols, not actually  
> connecting to the target?

You cannot, and you need not.

If you are just running GDB on the image, without actually running it
on the target, there is no need to consider the relocation at all.
Just use the symbols of the ELF file as is.

But _if_ you are running on the target, then in general the relocation
address is NOT known in advance, as it is computed dynamically, and
even on the same system it may change from one run to the next, for
example depending on settings of environment variables (like pram),
etc.

> Is such a script published anywhere?

You are long enough in this business that I simply don't believe you
if you claim you don't know how to read and print gd->relocaddr in
GDB...  Did you ever have a look at the documentation [1] ?

> If the symbols in the ELF file match where U-Boot is actually located,  
> that avoids the need to manually apply the relocation offset every time  
> you want to look at something.

Typically, you run a debugger because soimething is not working as
expected. In such a situation you want to debug the system that shows
the problem, not something completely different. [If you have a
generic problem that does not depend on specific settings, then just
debug it in the sandbox.] In my experience there are more cases where
a modified system (like one without relocation) just adds to the
problems and is actually counter-productive.

> Where would you get the symbol table to load that matches U-Boot  
> post-relocation?

Well, if you really don't know all this after all the years, then
maybe you might find it instructive to read the documentation,
especially section "10.1.2. Debugging of U-Boot After Relocation" [1] ?


[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Things are not as simple as they seem at first.        - Edward Thorp