arm: provide a CONFIG flag for disabling relocation
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Relocation may not be needed and desirable in many cases:
* For many boards the amount of SDRAM is fixed.
So relocation is not needed.
* Relocation adds un-necessary additional overhead when it's not needed. This delay is singificant on slower platforms such as FPGA
* Many boards have ample memory. So reserving enough memory for Linux in the first half is not a challenge even without relocation
Add a CONFIG option to disable relocation on platforms that do not need it. When this flag is enabled allocate memory for stack heap etc at the end of memory as usual, but U-Boot itself is not moved from TEXT_BASE.
Additionally, -pie is removed from the final link step because it was causing the absolute value of all symbols coming from the linker script to be 0. This affects find_cmd()
Tested on OMAP4430 SDP
--- arch/arm/config.mk | 2 ++ arch/arm/lib/board.c | 5 +++++ board/ti/sdp4430/config.mk | 9 +++++++-- include/configs/omap4_sdp4430.h | 2 ++ 4 files changed, 16 insertions(+), 2 deletions(-)
arch/arm/config.mk +2 -0
@@ -71,5 +71,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds # needed for relocation ifndef CONFIG_NAND_SPL +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION LDFLAGS_u-boot += -pie endif +endif
arch/arm/lib/board.c +5 -0
@@ -361,6 +361,7 @@ void board_init_f (ulong bootflag) gd->fb_base = addr;#endif /* CONFIG_LCD */ +#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION /* * reserve memory for U-Boot code, data & bss * round down to next 4 kB limit
@@ -369,6 +370,7 @@ void board_init_f (ulong bootflag) addr &= ~(4096 -1 );debug ("Reserving %ldk for U-Boot at: %08lx\n" , gd->mon_len >>10 , addr); +#endif #ifndef CONFIG_PRELOADER /*
@@ -420,6 +422,9 @@ void board_init_f (ulong bootflag)dram_init_banksize ();display_dram_config ();/* and display it */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + addr = _TEXT_BASE; +#endif gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - _TEXT_BASE;
board/ti/sdp4430/config.mk +7 -2
@@ -28,5 +28,10 @@ # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 # (mem base + reserved) -# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM -CONFIG_SYS_TEXT_BASE = 0x80100000 +# 64MB into the SDRAM +# Assuming a minimum of 128 MB on the board: +# - 64MB before U-Boot is more than enough for Linux when relocation is +# disabled +# - ~63MB after the U-Boot is more than enough for U-Boot to relocate +# itself without stepping on itself +CONFIG_SYS_TEXT_BASE = 0x84000000
include/configs/omap4_sdp4430.h +2 -0
@@ -278,4 +278,6 @@#define CONFIG_SYS_SPL_BSS_MAX_SIZE 0x80000/* 512 KB */ #define CONFIG_SYS_THUMB_BUILD + +#define CONFIG_SYS_SKIP_ARM_RELOCATION #endif /* __CONFIG_H */
Signature · 1 line
1.7.0.4
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Forgot to mention that this patch depends on my previous series for MMC spl:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/96352
This one was anyway intended to initiate the discussion. If approved, I shall create a cleaner patch.
Quoted 102 lines · Aneesh V
Relocation may not be needed and desirable in many cases:
* For many boards the amount of SDRAM is fixed.
So relocation is not needed.
* Relocation adds un-necessary additional overhead when it's not needed. This delay is singificant on slower platforms such as FPGA
* Many boards have ample memory. So reserving enough memory for Linux in the first half is not a challenge even without relocationAdd a CONFIG option to disable relocation on platforms that do not need it. When this flag is enabled allocate memory for stack heap etc at the end of memory as usual, but U-Boot itself is not moved from
TEXT_BASE.Additionally, -pie is removed from the final link step because it was causing the absolute value of all symbols coming from the linker script to be 0. This affects
find_cmd()Tested on OMAP4430 SDP
Cc Albert Aribaud<[email protected]>Cc Wolfgang Denk<[email protected]>Signed-off-by Aneesh V<[email protected]>--- arch/arm/config.mk | 2 ++ arch/arm/lib/board.c | 5 +++++ board/ti/sdp4430/config.mk | 9 +++++++-- include/configs/omap4_sdp4430.h | 2 ++ 4 files changed, 16 insertions(+), 2 deletions(-)arch/arm/config.mk +2
-0@@ -71,5 +71,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds # needed for relocation ifndef CONFIG_NAND_SPL +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION LDFLAGS_u-boot += -pie endif +endifarch/arm/lib/board.c +5
-0@@ -361,6 +361,7 @@ void board_init_f (ulong bootflag) gd->fb_base = addr;#endif /* CONFIG_LCD */ +#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION /* * reserve memory for U-Boot code, data& bss * round down to next 4 kB limit @@ -369,6 +370,7 @@ void board_init_f (ulong bootflag) addr&= ~(4096 -1 );debug ("Reserving %ldk for U-Boot at: %08lx\n" , gd->mon_len>>10 , addr); +#endif #ifndef CONFIG_PRELOADER /* @@ -420,6 +422,9 @@ void board_init_f (ulong bootflag)dram_init_banksize ();display_dram_config ();/* and display it */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + addr = _TEXT_BASE; +#endif gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - _TEXT_BASE;board/ti/sdp4430/config.mk +7
-2@@ -28,5 +28,10 @@ # Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 # (mem base + reserved) -# 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM -CONFIG_SYS_TEXT_BASE = 0x80100000 +# 64MB into the SDRAM +# Assuming a minimum of 128 MB on the board: +# - 64MB before U-Boot is more than enough for Linux when relocation is +# disabled +# - ~63MB after the U-Boot is more than enough for U-Boot to relocate +# itself without stepping on itself +CONFIG_SYS_TEXT_BASE = 0x84000000include/configs/omap4_sdp4430.h +2
-0@@ -278,4 +278,6 @@#define CONFIG_SYS_SPL_BSS_MAX_SIZE 0x80000/* 512 KB */ #define CONFIG_SYS_THUMB_BUILD + +#define CONFIG_SYS_SKIP_ARM_RELOCATION #endif /* __CONFIG_H */
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
In reply to Aneesh VDear Aneesh V,
Quoted 3 lines · In message <[email protected]> you wrote:
Relocation may not be needed and desirable in many cases:
* For many boards the amount of SDRAM is fixed. So relocation is not needed.
This is plain wrong. This has been explained a couple of times before. Please read the archives.
Quoted 3 lines
* Relocation adds un-necessary additional overhead when it's not needed. This delay is singificant on slower platforms such as FPGA
Do you have numbers? How much delay do you see caused by the relocation of U-Boot?
Quoted 3 lines
* Many boards have ample memory. So reserving enough memory for Linux in the first half is not a challenge even without relocation
You appear not to understand what relocation is needed for.
I tend to reject your patch, unless you can come up with really convincing arguments. Also, your patch should then work for all boards - not only ARM, but also PowerPC (one of the arguments for relocation was that we want to unify the code).
Best regards,
Wolfgang Denk
Signature · 5 lines
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 "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Dear Wolfgang,
Quoted 10 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 3 lines · In message<[email protected]> you wrote:
Relocation may not be needed and desirable in many cases:
* For many boards the amount of SDRAM is fixed. So relocation is not needed.This is plain wrong. This has been explained a couple of times before. Please read the archives.
I read this one:
http://tree.celinuxforum.org/pipermail/celinux-dev/2009-December/001916.html
I also read again this discussion I had started sometime back:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262
I don't think any of these features will suffer due to my change. Please note that the memory for pRAM, frame buffer etc would still be allocated at the end of available memory. I am preventing only code relocation.
My strategy is to leave enough space before and after the U-boot in the non-relocation case. Before the U-Boot for Linux, after U-boot for stack, heap and all other dynamic needs. Wouldn't that work? Am I missing something?
Quoted 6 lines
Quoted 3 lines
* Relocation adds un-necessary additional overhead when it's not needed. This delay is singificant on slower platforms such as FPGA
Do you have numbers? How much delay do you see caused by the relocation of U-Boot?
No, I don't have any numbers. In fact, if I enable relocation I get into some issues on the FPGA platform I am working on currently. But that seems to be a problem with the platform (For some reason, it doesn't work well when some code is copied to a new area and executed from there - maybe some issue with the memory model).
But the platform is so slow that booting U-boot itself takes couple of minutes. The overhead due to relocation will surely get magnified in such cases.
Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging.
Quoted 5 lines
Quoted 4 lines
* Many boards have ample memory. So reserving enough memory for Linux in the first half is not a challenge even without relocation
Quoted 7 lines
You appear not to understand what relocation is needed for.
I tend to reject your patch, unless you can come up with really convincing arguments. Also, your patch should then work for all boards - not only ARM, but also PowerPC (one of the arguments for relocation was that we want to unify the code).
I am afraid I will not be able to do that for all the archs primarily because I will not be able to test anything other than armv7 and also I do not understand their assembly languages. Sometimes, fixes in relocate_code() will be needed to make sure the special case of relocation offset = 0 works well. I had to do that for armv7(It's part of the SPL series). However, the same principles as in this patch should apply everywhere it shouldn't be very difficult to make it work for any architecture when there is a need.
best regards,
Aneesh
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Le 25/03/2011 17:12, Aneesh V a ?crit :
Quoted 6 lines
Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging.
Actually you don't need recompiling: simply set a breakpoint at the entry of relocate_code and once you hit the bp, look up r2: it contains the destination. If you want the offset rather than the absolute address, set the breakpoint right after the 'sub r9, r6, r0' round line 222: r9 will then give you the offset. Unload the current symbols, reload the symbols with the relevant offset, and there you go.
Amicalement,
Signature · 1 line
Albert.
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Quoted 9 lines · Albert ARIBAUD
Le 25/03/2011 17:12, Aneesh V a ?crit :
Quoted 6 lines
Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging.
Quoted 6 lines
Actually you don't need recompiling: simply set a breakpoint at the entry of
relocate_codeand once you hit the bp, look up r2: it contains the destination. If you want the offset rather than the absolute address, set the breakpoint right after the 'sub r9, r6, r0' round line 222: r9 will then give you the offset. Unload the current symbols, reload the symbols with the relevant offset, and there you go.
I would like to revisit this thread. I'm not sure how other people do development in U-Boot but I like to use an ICE and a source-level debugger for any significant effort. I think it should be possible to use a JTAG debugging just by loading the u-boot ELF file and running.
With this patch (or something similar) this is possible. Without it, it is painful.
To be clear, we are not talking here about creating a platform that doesn't use relocation, just that for development purposes it is convenient to be able to disable it.
Looking at the December thread
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262
Aneesh:
Quoted 2 lines
Quoted 2 lines
Shouldn't we provide a CONFIG option by which users can disable Elf relocation?
Wolfgang:
Quoted 2 lines
Why should we? It would just make the code even more complicated, and require a lot of additional test cases.
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Hi Simon, Wolfgang,
Quoted 22 lines · Simon Glass
Quoted 9 lines · Albert ARIBAUD
Le 25/03/2011 17:12, Aneesh V a ?crit :
Quoted 6 lines
Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging.
Quoted 6 lines
Actually you don't need recompiling: simply set a breakpoint at the entry of
relocate_codeand once you hit the bp, look up r2: it contains the destination. If you want the offset rather than the absolute address, set the breakpoint right after the 'sub r9, r6, r0' round line 222: r9 will then give you the offset. Unload the current symbols, reload the symbols with the relevant offset, and there you go.I would like to revisit this thread. I'm not sure how other people do development in U-Boot but I like to use an ICE and a source-level debugger for any significant effort. I think it should be possible to use a JTAG debugging just by loading the u-boot ELF file and running.
Quoted 6 lines
With this patch (or something similar) this is possible. Without it, it is painful.
To be clear, we are not talking here about creating a platform that doesn't use relocation, just that for development purposes it is convenient to be able to disable it.
Actually, I am not even sure why relocation shouldn't be disabled in my platform for good. It may be useful to have things such as the frame buffer at the end of available memory. But, IMHO, that can still be done without relocating u-boot. That's what the patch does.Am I missing something?
Quoted 32 lines
Looking at the December thread
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262Aneesh:
Quoted 2 lines
Quoted 2 lines
Shouldn't we provide a CONFIG option by which users can disable Elf relocation?
Wolfgang:
Quoted 2 lines
Why should we? It would just make the code even more complicated, and require a lot of additional test cases.
From what I can see this is a new CONFIG option, two ifdefs in the
board.cfile, and optionally disabling the -pie position-independent executable option to reduce size. It is pretty trivial:arch/arm/config.mk | 2 ++ arch/arm/lib/board.c | 5 +++++ 2 files changed, 7 insertions(+), 0 deletions(-)Regards,
SimonQuoted 9 lines
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
RFC PATCH 1/1 arm: provide a CONFIG flag for disabling relocation
Quoted 35 lines · Aneesh V
Hi Simon, Wolfgang,
Quoted 25 lines · Simon Glass
Quoted 10 lines · On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD<[email protected]> ?wrote:
Le 25/03/2011 17:12, Aneesh V a ?crit :
Quoted 6 lines
Another problem I have with relocation is that it makes debugging with JTAG debugers more difficult. The addresses of symbols in the ELF target are no longer valid. Of course, you can load the symbols at an offset from the original location. But one has to first enable debug prints, find the relocation offset, use it while loading the symbols before you can do source level debugging.
Quoted 6 lines
Actually you don't need recompiling: simply set a breakpoint at the entry of
relocate_codeand once you hit the bp, look up r2: it contains the destination. If you want the offset rather than the absolute address, set the breakpoint right after the 'sub r9, r6, r0' round line 222: r9 will then give you the offset. Unload the current symbols, reload the symbols with the relevant offset, and there you go.I would like to revisit this thread. I'm not sure how other people do development in U-Boot but I like to use an ICE and a source-level debugger for any significant effort. I think it should be possible to use a JTAG debugging just by loading the u-boot ELF file and running.
Quoted 6 lines
With this patch (or something similar) this is possible. Without it, it is painful.
To be clear, we are not talking here about creating a platform that doesn't use relocation, just that for development purposes it is convenient to be able to disable it.
Quoted 5 lines
Actually, I am not even sure why relocation shouldn't be disabled in my platform for good. It may be useful to have things such as the frame buffer at the end of available memory. But, IMHO, that can still be done without relocating u-boot. That's what the patch does.Am I missing something?
Well relocation does remove a lot of this ad-hoc positioning of things at compile time. I think it is desirable. My point is that it is not engineer-friendly during development, and we should have an easy way to disable it for debugging / JTAG purposes.
Regards,
Simon
Quoted 36 lines
Quoted 35 lines
Looking at the December thread
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262Aneesh:
Quoted 3 lines
Quoted 3 lines
Shouldn't we provide a CONFIG option by which users can disable Elf relocation?
Wolfgang:
Quoted 3 lines
Why should we? ?It would just make the code even more complicated, and require a lot of additional test cases.
?From what I can see this is a new CONFIG option, two ifdefs in the
board.cfile, and optionally disabling the -pie position-independent executable option to reduce size. It is pretty trivial:?arch/arm/config.mk ? | ? ?2 ++
?arch/arm/lib/board.c | ? ?5 +++++
?2 files changed, 7 insertions(+), 0 deletions(-)Regards,
SimonQuoted 9 lines
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot