| Message ID | 1301058732-30898-1-git-send-email-aneesh@ti.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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. On Friday 25 March 2011 06:42 PM, Aneesh V 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. > * 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 > > Cc: Albert Aribaud<albert.aribaud@free.fr> > Cc: Wolfgang Denk<wd@denx.de> > > Signed-off-by: Aneesh V<aneesh@ti.com> > --- > 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(-) > > diff --git a/arch/arm/config.mk b/arch/arm/config.mk > index 1785e73..2315bcb 100644 > --- a/arch/arm/config.mk > +++ b/arch/arm/config.mk > @@ -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 > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c > index 72ee108..ed3898f 100644 > --- a/arch/arm/lib/board.c > +++ b/arch/arm/lib/board.c > @@ -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; > diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk > index c62965d..8846732 100644 > --- a/board/ti/sdp4430/config.mk > +++ b/board/ti/sdp4430/config.mk > @@ -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 > diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h > index fff67d8..e9f76d3 100644 > --- a/include/configs/omap4_sdp4430.h > +++ b/include/configs/omap4_sdp4430.h > @@ -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 */
Dear Aneesh V, In message <1301058732-30898-1-git-send-email-aneesh@ti.com> 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. > * 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? > * 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
Dear Wolfgang, On Friday 25 March 2011 07:42 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1301058732-30898-1-git-send-email-aneesh@ti.com> 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? >> * 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. > >> * 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). 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
Le 25/03/2011 17:12, Aneesh V a écrit : > 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,
On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD <albert.aribaud@free.fr> wrote: > Le 25/03/2011 17:12, Aneesh V a écrit : > >> 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. 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: > > Shouldn't we provide a CONFIG option by which users can disable > > Elf relocation? Wolfgang: > 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.c file, 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, Simon > > Amicalement, > -- > Albert. > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
Hi Simon, Wolfgang, On Thursday 21 April 2011 12:04 AM, Simon Glass wrote: > On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD<albert.aribaud@free.fr> wrote: >> Le 25/03/2011 17:12, Aneesh V a écrit : >> >>> 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. > > 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. 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? > > Looking at the December thread > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262 > > Aneesh: >>> Shouldn't we provide a CONFIG option by which users can disable >>> Elf relocation? > > Wolfgang: >> 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.c file, 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, > Simon > >> >> Amicalement, >> -- >> Albert. >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >>
On Wed, Apr 20, 2011 at 11:56 PM, Aneesh V <aneesh@ti.com> wrote: > Hi Simon, Wolfgang, > > On Thursday 21 April 2011 12:04 AM, Simon Glass wrote: >> >> On Fri, Mar 25, 2011 at 11:35 AM, Albert ARIBAUD<albert.aribaud@free.fr> >> wrote: >>> >>> Le 25/03/2011 17:12, Aneesh V a écrit : >>> >>>> 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. >> >> 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. > > 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 > >> >> Looking at the December thread >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88067/focus=88262 >> >> Aneesh: >>>> >>>> Shouldn't we provide a CONFIG option by which users can disable >>>> Elf relocation? >> >> Wolfgang: >>> >>> 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.c file, 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, >> Simon >> >>> >>> Amicalement, >>> -- >>> Albert. >>> _______________________________________________ >>> U-Boot mailing list >>> U-Boot@lists.denx.de >>> http://lists.denx.de/mailman/listinfo/u-boot >>> >
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 1785e73..2315bcb 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -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 diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 72ee108..ed3898f 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -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; diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk index c62965d..8846732 100644 --- a/board/ti/sdp4430/config.mk +++ b/board/ti/sdp4430/config.mk @@ -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 diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h index fff67d8..e9f76d3 100644 --- a/include/configs/omap4_sdp4430.h +++ b/include/configs/omap4_sdp4430.h @@ -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 */
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 Cc: Albert Aribaud <albert.aribaud@free.fr> Cc: Wolfgang Denk <wd@denx.de> Signed-off-by: Aneesh V <aneesh@ti.com> --- 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(-)