[U-Boot] v2010-rc2: OMAP3 broken

2010-11-29 Thread Wolfgang Denk 
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

Re: [U-Boot] v2010-rc2: OMAP3 broken

2010-11-29 Thread Hiremath, Vaibhav 

 -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

Re: [U-Boot] v2010-rc2: OMAP3 broken

2010-11-29 Thread Hiremath, Vaibhav 

 -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

2010-11-29 Thread Albert ARIBAUD 
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

2010-11-29 Thread Andreas Bießmann 
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

2010-11-29 Thread Heiko Schocher 
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:

OMAP35xxt;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
OMAP35xxt;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
OMAP35xxt;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
OMAP35xxti;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
OMAP35xxti;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

2010-11-29 Thread Andreas Bießmann 
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

2010-11-29 Thread Albert ARIBAUD 
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:

 OMAP35xxt;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
 OMAP35xxt;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
 OMAP35xxt;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
 OMAP35xxti;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
 OMAP35xxti;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

2010-11-29 Thread Premi, Sanjeev 
 -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-bootm=129043627514796w=2
  http://marc.info/?l=u-bootm=129041727622164w=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

2010-11-29 Thread Andreas Bießmann 
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

2010-11-29 Thread Heiko Schocher 
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

2010-11-29 Thread Heiko Schocher 
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