[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address
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(-)
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
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
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),)
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
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
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
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
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
participants (4)
-
Henrik Nordström -
Scott Wood -
Tetsuyuki Kobayashi -
Wolfgang Denk