Re: [U-Boot] v2010-rc2: OMAP3 broken
Hello Albert, Albert ARIBAUD wrote: > Le 29/11/2010 16:04, Heiko Schocher a écrit : >> Hello Albert, >> >> Albert ARIBAUD wrote: >>> I'll take a look this evening at builds with and without the SORT() from >>> an ELF relocation tables perspective. >> >> I debugged on the beagle board a little bit in this problem, and here >> what I found: [...] >> Why is the rel.dyn Section in the bss section? >> > The .rel.dyn section is not "in" or "out" of the BSS: they are > overlapped, i.e. they should start at the same address. > > As indicated in the documentation, BSS should never be used before > relocation; it actually *cannot* be written into by boards which start > from NOR, and is set to zero for all boards right after relocation. Yep. > Since BSS does not exist before relocation, and .rel.dyn does not exist > after relocation, they can use the same location: overlaying them is the > best approach in order to get the smallest binary in Flash *and* the > smallest image in RAM. Ah, thats what I missed, thanks! > We can add code to try and catch the most obvious corruption of the > relocation tables due to BSS being accessed before relocation, but we > can't be sure to catch them all. The real solution is to fix the BSS usage. Yep. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Hello Andreas
Andreas Bießmann wrote:
> Am 29.11.2010 16:04, schrieb Heiko Schocher:
> [snip]
>> So it seems to me the "sort" version intermix the "rel dyn"
>> section entries with "normal" vars in bss ... Which raises
>> the question:
>>
>> Why is the rel.dyn Section in the bss section?
>
> cause of the
> ---8<---
> .bss __rel_dyn_start (OVERLAY) : {
> --->8---
> in u-boot.lds
>
> But the error is to use bss variables before setting up the bss section,
> isn't it?
Yep, thats right.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Dear all, Am 29.11.2010 16:19, schrieb Albert ARIBAUD: [snip] > The real solution is to fix the BSS usage. I'd like to mention old thread facing this issue for timestamp/lastinc values in arch/arm/cpu/*/timer.c http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88545 and http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/88383/focus=88551 regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko Schocher > Sent: Monday, November 29, 2010 8:35 PM > To: Albert ARIBAUD > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] v2010-rc2: OMAP3 broken > [snip] > in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets > timestamp to 0, before relocation is executed, which leads > that the memory @80046d7c gets overwritten to 0, which > results in crashing in the fixrel case ... > > So it seems to me the "sort" version intermix the "rel dyn" > section entries with "normal" vars in bss ... Which raises > the question: > > Why is the rel.dyn Section in the bss section? I have been facing the linker errors due to overlap of these sections. Using git-bisect, I was able to narrow down the failure to commit 6d8962e814c15807dd6ac5757904be2a02d187b8. I had the same question above. See these: http://marc.info/?l=u-boot&m=129043627514796&w=2 http://marc.info/?l=u-boot&m=129041727622164&w=2 ~sanjeev > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Le 29/11/2010 16:04, Heiko Schocher a écrit : > Hello Albert, > > Albert ARIBAUD wrote: >> I'll take a look this evening at builds with and without the SORT() from >> an ELF relocation tables perspective. > > I debugged on the beagle board a little bit in this problem, and here > what I found: > > Hier it goes wrong: > > arch/arm/cpu/armv7/start.S > > fixloop: > ldr r0, [r2]/* r0<- location to fix up, IN > FLASH! */ > 104: e592ldr r0, [r2] > add r0, r0, r9 /* r0<- location to fix up in RAM */ > 108: e089add r0, r0, r9 > > and later here > > fixrel: > /* relative fix: increase location by offset */ > ldr r1, [r0] > > Here the version with sort: > > OMAP35xx>t;r > Core number : 0 > Core state: debug mode (ARM) > Debug entry cause : Single Step > Current PC: 0x80008104 > Current CPSR : 0x21d3 (Supervisor) > GPR00: 80008000 8ff1df84 80046d7c 8004d6ac > GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 > GPR08: 4020ffa0 0ff76000 8004d6ac > GPR12: 8ff1df80 8000aef0 80008104 > PC : 80008104CPSR: 21d3 > OMAP35xx>t;r > Core number : 0 > Core state: debug mode (ARM) > Debug entry cause : Single Step > Current PC: 0x80008108 > Current CPSR : 0x21d3 (Supervisor) > GPR00: 8ff1df84 80046d7c 8004d6ac > > Ups... not good > > GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 > GPR08: 4020ffa0 0ff76000 8004d6ac > GPR12: 8ff1df80 8000aef0 80008108 > PC : 80008108CPSR: 21d3 > OMAP35xx>t;r > > > Here without sort: > > GPR00: 80008000 8ff1df84 80046d74 8004d6a4 > GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 > GPR08: 4020ffa0 0ff76000 8004d6a4 > GPR12: 8ff1df80 80010730 80008104 > PC : 80008104CPSR: 21d3 > OMAP35xx>ti;r > Core number : 0 > Core state: debug mode (ARM) > Debug entry cause : Single Step > Current PC: 0x80008108 > Current CPSR : 0x21d3 (Supervisor) > GPR00: 80008020 8ff1df84 80046d74 8004d6a4 > > Yep, thats better > GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 > GPR08: 4020ffa0 0ff76000 8004d6a4 > GPR12: 8ff1df80 80010730 80008108 > PC : 80008108CPSR: 21d3 > OMAP35xx>ti;r > Core number : 0 > Core state: debug mode (ARM) > Debug entry cause : Single Step > Current PC: 0x8000810c > Current CPSR : 0x21d3 (Supervisor) > > > System Map: > > with sort: > > 80046d7c B __bss_start > 80046d7c R __rel_dyn_start > 80046d7c b timestamp > 80046d80 b lastinc > 80046d84 B gpmc_cfg > > without sort: > > 80046d74 R __rel_dyn_start > 80046d78 b htab > 80046d84 B ___strtok > 80046d88 B z_verbose > > timestamp comes after the "__rel_dyn_end" entry in this case! > > Further debugging pointed my that in: > > in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets > timestamp to 0, before relocation is executed, which leads > that the memory @80046d7c gets overwritten to 0, which > results in crashing in the fixrel case ... > > So it seems to me the "sort" version intermix the "rel dyn" > section entries with "normal" vars in bss ... Which raises > the question: > > Why is the rel.dyn Section in the bss section? > The .rel.dyn section is not "in" or "out" of the BSS: they are overlapped, i.e. they should start at the same address. As indicated in the documentation, BSS should never be used before relocation; it actually *cannot* be written into by boards which start from NOR, and is set to zero for all boards right after relocation. Since BSS does not exist before relocation, and .rel.dyn does not exist after relocation, they can use the same location: overlaying them is the best approach in order to get the smallest binary in Flash *and* the smallest image in RAM. We can add code to try and catch the most obvious corruption of the relocation tables due to BSS being accessed before relocation, but we can't be sure to catch them all. The real solution is to fix the BSS usage. > bye, > Heiko Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Dear Heiko Schocher,
Am 29.11.2010 16:04, schrieb Heiko Schocher:
[snip]
> So it seems to me the "sort" version intermix the "rel dyn"
> section entries with "normal" vars in bss ... Which raises
> the question:
>
> Why is the rel.dyn Section in the bss section?
cause of the
---8<---
.bss __rel_dyn_start (OVERLAY) : {
--->8---
in u-boot.lds
But the error is to use bss variables before setting up the bss section,
isn't it?
regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Hello Albert, Albert ARIBAUD wrote: > I'll take a look this evening at builds with and without the SORT() from > an ELF relocation tables perspective. I debugged on the beagle board a little bit in this problem, and here what I found: Hier it goes wrong: arch/arm/cpu/armv7/start.S fixloop: ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! */ 104: e592ldr r0, [r2] add r0, r0, r9 /* r0 <- location to fix up in RAM */ 108: e089add r0, r0, r9 and later here fixrel: /* relative fix: increase location by offset */ ldr r1, [r0] Here the version with sort: OMAP35xx>t;r Core number : 0 Core state: debug mode (ARM) Debug entry cause : Single Step Current PC: 0x80008104 Current CPSR : 0x21d3 (Supervisor) GPR00: 80008000 8ff1df84 80046d7c 8004d6ac GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6ac GPR12: 8ff1df80 8000aef0 80008104 PC : 80008104CPSR: 21d3 OMAP35xx>t;r Core number : 0 Core state: debug mode (ARM) Debug entry cause : Single Step Current PC: 0x80008108 Current CPSR : 0x21d3 (Supervisor) GPR00: 8ff1df84 80046d7c 8004d6ac Ups... not good GPR04: 8ff1df80 8ff1df84 8ffbcd80 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6ac GPR12: 8ff1df80 8000aef0 80008108 PC : 80008108CPSR: 21d3 OMAP35xx>t;r Here without sort: GPR00: 80008000 8ff1df84 80046d74 8004d6a4 GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6a4 GPR12: 8ff1df80 80010730 80008104 PC : 80008104CPSR: 21d3 OMAP35xx>ti;r Core number : 0 Core state: debug mode (ARM) Debug entry cause : Single Step Current PC: 0x80008108 Current CPSR : 0x21d3 (Supervisor) GPR00: 80008020 8ff1df84 80046d74 8004d6a4 Yep, thats better GPR04: 8ff1df80 8ff1df84 8ffbcd78 8ff7e000 GPR08: 4020ffa0 0ff76000 8004d6a4 GPR12: 8ff1df80 80010730 80008108 PC : 80008108CPSR: 21d3 OMAP35xx>ti;r Core number : 0 Core state: debug mode (ARM) Debug entry cause : Single Step Current PC: 0x8000810c Current CPSR : 0x21d3 (Supervisor) System Map: with sort: 80046d7c B __bss_start 80046d7c R __rel_dyn_start 80046d7c b timestamp 80046d80 b lastinc 80046d84 B gpmc_cfg without sort: 80046d74 R __rel_dyn_start 80046d78 b htab 80046d84 B ___strtok 80046d88 B z_verbose timestamp comes after the "__rel_dyn_end" entry in this case! Further debugging pointed my that in: in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets timestamp to 0, before relocation is executed, which leads that the memory @80046d7c gets overwritten to 0, which results in crashing in the fixrel case ... So it seems to me the "sort" version intermix the "rel dyn" section entries with "normal" vars in bss ... Which raises the question: Why is the rel.dyn Section in the bss section? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Dear all, Am 29.11.2010 14:23, schrieb Hiremath, Vaibhav: >> The system is hanging at >> >> fixrel: >> /* relative fix: increase location by offset */ >> ldr r1, [r0] >> > [Hiremath, Vaibhav] pasting error, the actual place is > > fixnext: > str r1, [r0] > Here the value of r0 is relocation offset and not an address. I do have this error on at92rm9200ek too. I got it down to corrupted .rel.dyn table by setting two bss values in arch/arm/cpu/at91/timer.c. Can you try to change your linker script to _not_ overlay _rel_dyn_start with with .bss? The other way is to break on board_init_f, display the relevant (defective) locations in .rel.dyn and step through the for loop for init_sequence if one destroys the relevant part in .rel.dyn regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
Hi all, I'll take a look this evening at builds with and without the SORT() from an ELF relocation tables perspective. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Hiremath, Vaibhav > Sent: Monday, November 29, 2010 6:50 PM > To: Wolfgang Denk; u-boot@lists.denx.de > Subject: Re: [U-Boot] v2010-rc2: OMAP3 broken > > > > -Original Message- > > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > > On Behalf Of Wolfgang Denk > > Sent: Monday, November 29, 2010 6:19 PM > > To: u-boot@lists.denx.de > > Subject: [U-Boot] v2010-rc2: OMAP3 broken > > > > Hi, > > > > it seems that commit 566d49a3f has broken OMAP3 - at least beagle and > > devkit8000 hang in or after relocation. > > > [Hiremath, Vaibhav] AM3517 also used to hangs in relocate_code function. > > > > > The culprit is this the "$(sort $(LIBS)) in Makefile, i. e. the > > following change will unbreak the boards: > > > > @@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx) > > LIBS += $(CPUDIR)/s5p-common/libs5p-common.o > > endif > > > > -LIBS := $(addprefix $(obj),$(sort $(LIBS))) > > +LIBS := $(addprefix $(obj),$(LIBS)) > > .PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE) > > > > LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o > > > > > [Hiremath, Vaibhav] The above patch works for me as well. > > > Unfortunately we need the sort to avoild duplicate listing of libs / > > objects on PowerPC. And I don;t understand yet how this change can > > cause such an affect. > > > > Any help welcome. > > > [Hiremath, Vaibhav] I can put my debug observations here, > > > The system is hanging at > > fixrel: > /* relative fix: increase location by offset */ > ldr r1, [r0] > [Hiremath, Vaibhav] pasting error, the actual place is fixnext: str r1, [r0] Thanks, Vaibhav > Here the value of r0 is relocation offset and not an address. > > fixloop: > ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! */ > add r0, r0, r9 /* r0 <- location to fix up in RAM */ > > In the above two instructions, load from [r2] is coming as 0, causing > reference to invalid address (relocation offset). > > After applying your patch, the value from above load instruction comes as > 0x80008020, which further gets added to offset (valid address). > > > I hope this might give you some pointers, and I am not an expert on > makefile, so not sure about relation between library sort and above > finding. > > Thanks, > Vaibhav > > 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: w...@denx.de > > It seems intuitively obvious to me, which means that it might be > > wrong. -- Chris Torek > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] v2010-rc2: OMAP3 broken
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Wolfgang Denk > Sent: Monday, November 29, 2010 6:19 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] v2010-rc2: OMAP3 broken > > Hi, > > it seems that commit 566d49a3f has broken OMAP3 - at least beagle and > devkit8000 hang in or after relocation. > [Hiremath, Vaibhav] AM3517 also used to hangs in relocate_code function. > The culprit is this the "$(sort $(LIBS)) in Makefile, i. e. the > following change will unbreak the boards: > > @@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx) > LIBS += $(CPUDIR)/s5p-common/libs5p-common.o > endif > > -LIBS := $(addprefix $(obj),$(sort $(LIBS))) > +LIBS := $(addprefix $(obj),$(LIBS)) > .PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE) > > LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o > > [Hiremath, Vaibhav] The above patch works for me as well. > Unfortunately we need the sort to avoild duplicate listing of libs / > objects on PowerPC. And I don;t understand yet how this change can > cause such an affect. > > Any help welcome. > [Hiremath, Vaibhav] I can put my debug observations here, The system is hanging at fixrel: /* relative fix: increase location by offset */ ldr r1, [r0] Here the value of r0 is relocation offset and not an address. fixloop: ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! */ add r0, r0, r9 /* r0 <- location to fix up in RAM */ In the above two instructions, load from [r2] is coming as 0, causing reference to invalid address (relocation offset). After applying your patch, the value from above load instruction comes as 0x80008020, which further gets added to offset (valid address). I hope this might give you some pointers, and I am not an expert on makefile, so not sure about relation between library sort and above finding. Thanks, Vaibhav > 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: w...@denx.de > It seems intuitively obvious to me, which means that it might be > wrong. -- Chris Torek > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] v2010-rc2: OMAP3 broken
Hi, it seems that commit 566d49a3f has broken OMAP3 - at least beagle and devkit8000 hang in or after relocation. The culprit is this the "$(sort $(LIBS)) in Makefile, i. e. the following change will unbreak the boards: @@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx) LIBS += $(CPUDIR)/s5p-common/libs5p-common.o endif -LIBS := $(addprefix $(obj),$(sort $(LIBS))) +LIBS := $(addprefix $(obj),$(LIBS)) .PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE) LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o Unfortunately we need the sort to avoild duplicate listing of libs / objects on PowerPC. And I don;t understand yet how this change can cause such an affect. Any help welcome. 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: w...@denx.de It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
