public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] Relocation issue - need help!
@ 2014-10-22 12:39 Wolfgang Denk
  2014-10-22 13:29 ` Dirk Eibach
  0 siblings, 1 reply; 32+ messages in thread
From: Wolfgang Denk @ 2014-10-22 12:39 UTC (permalink / raw)
  To: u-boot

Hi,

I'm trying to track down a "syntax error" issue that gets triggered
when erasing the U-Boot image in NOR flash.  Symptoms look like this:

	=> print update
	update=protect off 0xfc000000 +${filesize};erase 0xfc000000 +${filesize};cp.b 200000 0xfc000000 ${filesize};protect on 0xfc000000 +${filesize}
	=> run update
	Un-Protected 2 sectors

	.. done
	Erased 2 sectors
	syntax error
	Protected 2 sectors
	=> run update
	syntax error

git bisect found commit 199adb6 "common/misc: sparse fixes" as
culprit; breaking this down further showed a single line in
common/cli_hush.c to trigger the problem. This patch fixes it:

---
 common/cli_hush.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cli_hush.c b/common/cli_hush.c
index 38da5a0..5bbcfe6 100644
--- a/common/cli_hush.c
+++ b/common/cli_hush.c
@@ -3127,7 +3127,7 @@ static void mapset(const unsigned char *set, int code)
 	for (s=set; *s; s++) map[*s] = code;
 }
 
-static void update_ifs_map(void)
+void update_ifs_map(void)
 {
 	/* char *ifs and char map[256] are both globals. */
 	ifs = (uchar *)getenv("IFS");
-- 
1.8.3.1

But I still have bad feelings - symptoms indicate that this is
actually a relocation issue, as it only gets triggered when erasing
the U-Boot image in NOR flash, so probably there are still pointers to
data in NOR being used.  This patch here is not suited to fix the
original cause of this issue.  But then, I do not see where there
might be a relocation problem.  To be sure I even verified that "ifs"
and "map[]" are really in RAM all the time.

Has anybody an idea how to further track this down?  Or is the patch
above actually a real fix?  If so, why?

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: wd at denx.de
Old programmers never die, they just branch to a new address.

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 12:39 [U-Boot] Relocation issue - need help! Wolfgang Denk
@ 2014-10-22 13:29 ` Dirk Eibach
  2014-10-22 16:56   ` Wolfgang Denk
  0 siblings, 1 reply; 32+ messages in thread
From: Dirk Eibach @ 2014-10-22 13:29 UTC (permalink / raw)
  To: u-boot

I had exactly the same behaviour some time ago and tracked it down to
this (and posted it on the mailing list, but sadly got no feedback):

In my latest u-boot builds I had some strange behaviour that I finally
tracked down to not fixed up flash addresses in relocated u-boot.
These addresses come from symbols in the .data.rel.ro.local section
that is not handled by u-boot linker scripts at the moment.

Some background on relro: http://www.airs.com/blog/archives/189

Joerg Albert already inquired about this on the gcc ML:
https://gcc.gnu.org/ml/gcc-help/2014-02/msg00017.html and he already
suggested a solution:
https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html

So there a three things to notice:
1. Do not use gcc 4.8 and u-boot at the moment.
2. You might not notice that you have a problem until you erase u-boot
from flash (and get your cache flushed).
3. Handling relro properly should be on the TODO-List

Maybe this is already common knowledge an maybe somebody is already
working on this - but I did not notice yet. So in this case: sorry for
the noise :)

2014-10-22 14:39 GMT+02:00 Wolfgang Denk <wd@denx.de>:
> Hi,
>
> I'm trying to track down a "syntax error" issue that gets triggered
> when erasing the U-Boot image in NOR flash.  Symptoms look like this:
>
>         => print update
>         update=protect off 0xfc000000 +${filesize};erase 0xfc000000 +${filesize};cp.b 200000 0xfc000000 ${filesize};protect on 0xfc000000 +${filesize}
>         => run update
>         Un-Protected 2 sectors
>
>         .. done
>         Erased 2 sectors
>         syntax error
>         Protected 2 sectors
>         => run update
>         syntax error
>
> git bisect found commit 199adb6 "common/misc: sparse fixes" as
> culprit; breaking this down further showed a single line in
> common/cli_hush.c to trigger the problem. This patch fixes it:
>
> ---
>  common/cli_hush.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/cli_hush.c b/common/cli_hush.c
> index 38da5a0..5bbcfe6 100644
> --- a/common/cli_hush.c
> +++ b/common/cli_hush.c
> @@ -3127,7 +3127,7 @@ static void mapset(const unsigned char *set, int code)
>         for (s=set; *s; s++) map[*s] = code;
>  }
>
> -static void update_ifs_map(void)
> +void update_ifs_map(void)
>  {
>         /* char *ifs and char map[256] are both globals. */
>         ifs = (uchar *)getenv("IFS");
> --
> 1.8.3.1
>
> But I still have bad feelings - symptoms indicate that this is
> actually a relocation issue, as it only gets triggered when erasing
> the U-Boot image in NOR flash, so probably there are still pointers to
> data in NOR being used.  This patch here is not suited to fix the
> original cause of this issue.  But then, I do not see where there
> might be a relocation problem.  To be sure I even verified that "ifs"
> and "map[]" are really in RAM all the time.
>
> Has anybody an idea how to further track this down?  Or is the patch
> above actually a real fix?  If so, why?
>
> 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: wd at denx.de
> Old programmers never die, they just branch to a new address.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 13:29 ` Dirk Eibach
@ 2014-10-22 16:56   ` Wolfgang Denk
  2014-10-22 17:26     ` Fabio Estevam
                       ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Wolfgang Denk @ 2014-10-22 16:56 UTC (permalink / raw)
  To: u-boot

Dear Dirk,

In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com> you wrote:
> I had exactly the same behaviour some time ago and tracked it down to
> this (and posted it on the mailing list, but sadly got no feedback):

Thanks a lot for this pointer.

> So there a three things to notice:
> 1. Do not use gcc 4.8 and u-boot at the moment.
> 2. You might not notice that you have a problem until you erase u-boot
> from flash (and get your cache flushed).
> 3. Handling relro properly should be on the TODO-List

I confirm that the problem is in my case with gcc 4.8.1, too.  I did
not try another compiler yet.

> Maybe this is already common knowledge an maybe somebody is already
> working on this - but I did not notice yet. So in this case: sorry for
> the noise :)

I highly appreciate your hint, it was definitely very useful. Thanks!

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: wd at denx.de
The ultimate barrier is one's viewpoint.
                        - Terry Pratchett, _The Dark Side of the Sun_

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 16:56   ` Wolfgang Denk
@ 2014-10-22 17:26     ` Fabio Estevam
  2014-10-22 17:28     ` Tom Rini
  2014-10-23  6:01     ` Dirk Eibach
  2 siblings, 0 replies; 32+ messages in thread
From: Fabio Estevam @ 2014-10-22 17:26 UTC (permalink / raw)
  To: u-boot

On Wed, Oct 22, 2014 at 2:56 PM, Wolfgang Denk <wd@denx.de> wrote:

>> So there a three things to notice:
>> 1. Do not use gcc 4.8 and u-boot at the moment.
>> 2. You might not notice that you have a problem until you erase u-boot
>> from flash (and get your cache flushed).
>> 3. Handling relro properly should be on the TODO-List
>
> I confirm that the problem is in my case with gcc 4.8.1, too.  I did
> not try another compiler yet.

Yes, there have been reported issues when using gcc 4.8.1 for building
an ARM kernel as well:
https://lkml.org/lkml/2014/10/10/272

Regards,

Fabio Estevam

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 16:56   ` Wolfgang Denk
  2014-10-22 17:26     ` Fabio Estevam
@ 2014-10-22 17:28     ` Tom Rini
  2014-10-22 17:39       ` Wolfgang Denk
  2014-10-22 21:27       ` Pavel Machek
  2014-10-23  6:01     ` Dirk Eibach
  2 siblings, 2 replies; 32+ messages in thread
From: Tom Rini @ 2014-10-22 17:28 UTC (permalink / raw)
  To: u-boot

On Wed, Oct 22, 2014 at 06:56:11PM +0200, Wolfgang Denk wrote:
> Dear Dirk,
> 
> In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com> you wrote:
> > I had exactly the same behaviour some time ago and tracked it down to
> > this (and posted it on the mailing list, but sadly got no feedback):
> 
> Thanks a lot for this pointer.
> 
> > So there a three things to notice:
> > 1. Do not use gcc 4.8 and u-boot at the moment.
> > 2. You might not notice that you have a problem until you erase u-boot
> > from flash (and get your cache flushed).
> > 3. Handling relro properly should be on the TODO-List
> 
> I confirm that the problem is in my case with gcc 4.8.1, too.  I did
> not try another compiler yet.
> 
> > Maybe this is already common knowledge an maybe somebody is already
> > working on this - but I did not notice yet. So in this case: sorry for
> > the noise :)
> 
> I highly appreciate your hint, it was definitely very useful. Thanks!

Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
some cases, and this may or may not be related (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141022/e02b7832/attachment.pgp>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 17:28     ` Tom Rini
@ 2014-10-22 17:39       ` Wolfgang Denk
  2014-10-22 21:27       ` Pavel Machek
  1 sibling, 0 replies; 32+ messages in thread
From: Wolfgang Denk @ 2014-10-22 17:39 UTC (permalink / raw)
  To: u-boot

Dear Tom,

In message <20141022172811.GD25506@bill-the-cat> you wrote:
> 
> Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
> some cases, and this may or may not be related (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D58854)

This is on PowerPC (MPC5200, i. e. the TQM5200S board I've had in my
fingers yesterday for other reasons).

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: wd at denx.de
In accord with UNIX philosophy, Perl gives you enough  rope  to  hang
yourself.              - L. Wall & R. L. Schwartz, _Programming Perl_

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 17:28     ` Tom Rini
  2014-10-22 17:39       ` Wolfgang Denk
@ 2014-10-22 21:27       ` Pavel Machek
  2014-10-22 21:46         ` Marek Vasut
  1 sibling, 1 reply; 32+ messages in thread
From: Pavel Machek @ 2014-10-22 21:27 UTC (permalink / raw)
  To: u-boot

Hi!

> > In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com> you wrote:
> > > I had exactly the same behaviour some time ago and tracked it down to
> > > this (and posted it on the mailing list, but sadly got no feedback):
> > 
> > Thanks a lot for this pointer.
> > 
> > > So there a three things to notice:
> > > 1. Do not use gcc 4.8 and u-boot at the moment.
> > > 2. You might not notice that you have a problem until you erase u-boot
> > > from flash (and get your cache flushed).
> > > 3. Handling relro properly should be on the TODO-List
> > 
> > I confirm that the problem is in my case with gcc 4.8.1, too.  I did
> > not try another compiler yet.
> > 
> > > Maybe this is already common knowledge an maybe somebody is already
> > > working on this - but I did not notice yet. So in this case: sorry for
> > > the noise :)
> > 
> > I highly appreciate your hint, it was definitely very useful. Thanks!
> 
> Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
> some cases, and this may or may not be related (see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854)

Just for the record, I also stree strange issues with 4.8.1 on
arm/socfpga. u-boot works ok when compiled with 4.7.2, and behaviour
on 4.8.1 seems to change based on compiler flags (-Os vs. -O2).

If anyone knows some kind of workaround, that would be nice... I'm
using bitbake with eldk-5.5, and changing that would not be too easy
:-(.

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 21:27       ` Pavel Machek
@ 2014-10-22 21:46         ` Marek Vasut
  2014-10-22 21:57           ` Pavel Machek
  0 siblings, 1 reply; 32+ messages in thread
From: Marek Vasut @ 2014-10-22 21:46 UTC (permalink / raw)
  To: u-boot

On Wednesday, October 22, 2014 at 11:27:42 PM, Pavel Machek wrote:
> Hi!
> 
> > > In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-
tsCApi7WVxQAHg@mail.gmail.com> you wrote:
> > > > I had exactly the same behaviour some time ago and tracked it down to
> > > 
> > > > this (and posted it on the mailing list, but sadly got no feedback):
> > > Thanks a lot for this pointer.
> > > 
> > > > So there a three things to notice:
> > > > 1. Do not use gcc 4.8 and u-boot at the moment.
> > > > 2. You might not notice that you have a problem until you erase
> > > > u-boot from flash (and get your cache flushed).
> > > > 3. Handling relro properly should be on the TODO-List
> > > 
> > > I confirm that the problem is in my case with gcc 4.8.1, too.  I did
> > > not try another compiler yet.
> > > 
> > > > Maybe this is already common knowledge an maybe somebody is already
> > > > working on this - but I did not notice yet. So in this case: sorry
> > > > for the noise :)
> > > 
> > > I highly appreciate your hint, it was definitely very useful. Thanks!
> > 
> > Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
> > some cases, and this may or may not be related (see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854)
> 
> Just for the record, I also stree strange issues with 4.8.1 on
> arm/socfpga. u-boot works ok when compiled with 4.7.2, and behaviour
> on 4.8.1 seems to change based on compiler flags (-Os vs. -O2).
> 
> If anyone knows some kind of workaround, that would be nice... I'm
> using bitbake with eldk-5.5, and changing that would not be too easy

What is the issue that you do see and I do not see ? What are the symptoms?

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 21:46         ` Marek Vasut
@ 2014-10-22 21:57           ` Pavel Machek
  2014-10-22 22:06             ` Marek Vasut
  0 siblings, 1 reply; 32+ messages in thread
From: Pavel Machek @ 2014-10-22 21:57 UTC (permalink / raw)
  To: u-boot

On Wed 2014-10-22 23:46:45, Marek Vasut wrote:
> On Wednesday, October 22, 2014 at 11:27:42 PM, Pavel Machek wrote:
> > Hi!
> > 
> > > > In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-
> tsCApi7WVxQAHg at mail.gmail.com> you wrote:
> > > > > I had exactly the same behaviour some time ago and tracked it down to
> > > > 
> > > > > this (and posted it on the mailing list, but sadly got no feedback):
> > > > Thanks a lot for this pointer.
> > > > 
> > > > > So there a three things to notice:
> > > > > 1. Do not use gcc 4.8 and u-boot at the moment.
> > > > > 2. You might not notice that you have a problem until you erase
> > > > > u-boot from flash (and get your cache flushed).
> > > > > 3. Handling relro properly should be on the TODO-List
> > > > 
> > > > I confirm that the problem is in my case with gcc 4.8.1, too.  I did
> > > > not try another compiler yet.
> > > > 
> > > > > Maybe this is already common knowledge an maybe somebody is already
> > > > > working on this - but I did not notice yet. So in this case: sorry
> > > > > for the noise :)
> > > > 
> > > > I highly appreciate your hint, it was definitely very useful. Thanks!
> > > 
> > > Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
> > > some cases, and this may or may not be related (see
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854)
> > 
> > Just for the record, I also stree strange issues with 4.8.1 on
> > arm/socfpga. u-boot works ok when compiled with 4.7.2, and behaviour
> > on 4.8.1 seems to change based on compiler flags (-Os vs. -O2).
> > 
> > If anyone knows some kind of workaround, that would be nice... I'm
> > using bitbake with eldk-5.5, and changing that would not be too easy
> 
> What is the issue that you do see and I do not see ? What are the symptoms?

I'm not sure if you should be seing this issue, are you using gcc
4.8.1?

I get hang during MMC init. If I comment it out, it hangs at setenv of
random variable. With changed compiler flags, commenting out MMC init
does not get me to prompt.

I'll try to update to gcc-4.8.3 as gcc-4.8.1 has known issues.
									Pavel 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 21:57           ` Pavel Machek
@ 2014-10-22 22:06             ` Marek Vasut
  0 siblings, 0 replies; 32+ messages in thread
From: Marek Vasut @ 2014-10-22 22:06 UTC (permalink / raw)
  To: u-boot

On Wednesday, October 22, 2014 at 11:57:39 PM, Pavel Machek wrote:
> On Wed 2014-10-22 23:46:45, Marek Vasut wrote:
> > On Wednesday, October 22, 2014 at 11:27:42 PM, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-
> > 
> > tsCApi7WVxQAHg at mail.gmail.com> you wrote:
> > > > > > I had exactly the same behaviour some time ago and tracked it
> > > > > > down to
> > > > > 
> > > > > > this (and posted it on the mailing list, but sadly got no feedback):
> > > > > Thanks a lot for this pointer.
> > > > > 
> > > > > > So there a three things to notice:
> > > > > > 1. Do not use gcc 4.8 and u-boot at the moment.
> > > > > > 2. You might not notice that you have a problem until you erase
> > > > > > u-boot from flash (and get your cache flushed).
> > > > > > 3. Handling relro properly should be on the TODO-List
> > > > > 
> > > > > I confirm that the problem is in my case with gcc 4.8.1, too.  I
> > > > > did not try another compiler yet.
> > > > > 
> > > > > > Maybe this is already common knowledge an maybe somebody is
> > > > > > already working on this - but I did not notice yet. So in this
> > > > > > case: sorry for the noise :)
> > > > > 
> > > > > I highly appreciate your hint, it was definitely very useful.
> > > > > Thanks!
> > > > 
> > > > Is this ARM or PowerPC?  The kernel has blacklisted 4.8.x for ARM in
> > > > some cases, and this may or may not be related (see
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854)
> > > 
> > > Just for the record, I also stree strange issues with 4.8.1 on
> > > arm/socfpga. u-boot works ok when compiled with 4.7.2, and behaviour
> > > on 4.8.1 seems to change based on compiler flags (-Os vs. -O2).
> > > 
> > > If anyone knows some kind of workaround, that would be nice... I'm
> > > using bitbake with eldk-5.5, and changing that would not be too easy
> > 
> > What is the issue that you do see and I do not see ? What are the
> > symptoms?
> 
> I'm not sure if you should be seing this issue, are you using gcc
> 4.8.1?
> 
> I get hang during MMC init. If I comment it out, it hangs at setenv of
> random variable. With changed compiler flags, commenting out MMC init
> does not get me to prompt.
> 
> I'll try to update to gcc-4.8.3 as gcc-4.8.1 has known issues.

Actually 4.8.2 from ELDK 5.6 . I recall there were some fixes for GCC , but this 
should be fixed in ELDK 5.5.2 . See:
https://www.mail-archive.com/eldk at lists.denx.de/msg00908.html

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-22 16:56   ` Wolfgang Denk
  2014-10-22 17:26     ` Fabio Estevam
  2014-10-22 17:28     ` Tom Rini
@ 2014-10-23  6:01     ` Dirk Eibach
  2014-10-23  6:42       ` Joakim Tjernlund
  2 siblings, 1 reply; 32+ messages in thread
From: Dirk Eibach @ 2014-10-23  6:01 UTC (permalink / raw)
  To: u-boot

Hello Wolfgang,

2014-10-22 18:56 GMT+02:00 Wolfgang Denk <wd@denx.de>:
> Dear Dirk,
>
> In message <CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com> you wrote:
>> I had exactly the same behaviour some time ago and tracked it down to
>> this (and posted it on the mailing list, but sadly got no feedback):
>
> Thanks a lot for this pointer.

I am really glad this was helpful. It was very nasty to track down, so
I was really concerned when I found it. For that reson I chose "u-boot
ppc does not work with gcc 4.8" as a topic when I reported it to
U-Boot mailing list and put you on CC on august 5th. But maybe I
should have been more explicit, something like "APOCALYPSE NOW: u-boot
ppc does not work with gcc 4.8" ;)

This problem is *not* fixed by the links Marek addressed.

Just a quick explanation of what is going on:
Since gcc 4.8 we have new sections .data.rel.ro and
.data.rel.ro.local. They contain absolute addresses that should really
be fixed up in our relocation process but are not considered yet.
In your case  you wre running u-boot referencing the not fixed-up
addresses which worked perfectly as long as they still pointed to
valid content. But as soon as you erased flash this was no longer the
case. To make debugging even more fun, behaviour also depends on cache
contents.

In my original mail I referenced this potential solution, at least it
worked for me:
https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html

Cheers
DIrk

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-23  6:01     ` Dirk Eibach
@ 2014-10-23  6:42       ` Joakim Tjernlund
  2014-10-23 13:10         ` Wolfgang Denk
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2014-10-23  6:42 UTC (permalink / raw)
  To: u-boot

> 
> Hello Wolfgang,
> 
> 2014-10-22 18:56 GMT+02:00 Wolfgang Denk <wd@denx.de>:
> > Dear Dirk,
> >
> > In message 
<CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com> you 
wrote:
> >> I had exactly the same behaviour some time ago and tracked it down to
> >> this (and posted it on the mailing list, but sadly got no feedback):
> >
> > Thanks a lot for this pointer.
> 
> I am really glad this was helpful. It was very nasty to track down, so
> I was really concerned when I found it. For that reson I chose "u-boot
> ppc does not work with gcc 4.8" as a topic when I reported it to
> U-Boot mailing list and put you on CC on august 5th. But maybe I
> should have been more explicit, something like "APOCALYPSE NOW: u-boot
> ppc does not work with gcc 4.8" ;)
> 
> This problem is *not* fixed by the links Marek addressed.
> 
> Just a quick explanation of what is going on:
> Since gcc 4.8 we have new sections .data.rel.ro and
> .data.rel.ro.local. They contain absolute addresses that should really
> be fixed up in our relocation process but are not considered yet.
> In your case  you wre running u-boot referencing the not fixed-up
> addresses which worked perfectly as long as they still pointed to
> valid content. But as soon as you erased flash this was no longer the
> case. To make debugging even more fun, behaviour also depends on cache
> contents.

Ouch, that was a nasty surprise.

> 
> In my original mail I referenced this potential solution, at least it
> worked for me:
> https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html

That looks like the correct fix but I presume both .data.rel.ro and
data.rel.ro.local should be added?

 Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-23  6:42       ` Joakim Tjernlund
@ 2014-10-23 13:10         ` Wolfgang Denk
  2014-10-23 13:42           ` Dirk Eibach
                             ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Wolfgang Denk @ 2014-10-23 13:10 UTC (permalink / raw)
  To: u-boot

Dear Joakim, dear Dirk,

In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-C1257D7A.0024DEC4@transmode.se> you wrote:
>
> Ouch, that was a nasty surprise.

Indeed.

> > In my original mail I referenced this potential solution, at least it
> > worked for me:
> > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> 
> That looks like the correct fix but I presume both .data.rel.ro and
> data.rel.ro.local should be added?

I can confirm:

1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
   5.5.x].

2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
   problem go away.

3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
   the problem go away.

4) For the problemativ 4.8.x versions of GCC, the following patch
   apparently solves the problem for my (MPC5200 based) board - guess
   this would have to be applied to all .lds files...

diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
index cd9e23f..82c86d7 100644
--- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
@@ -27,6 +27,8 @@ SECTIONS
   {
     _GOT2_TABLE_ = .;
     KEEP(*(.got2))
+    KEEP(*(.data.rel.ro))
+    KEEP(*(.data.rel.ro.local))
     KEEP(*(.got))
     PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
     _FIXUP_TABLE_ = .;

Given that GCC 4.9.1 apparently solves this issue I wonder which
approach we should take?

Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
doing [1] ?

[1] https://lkml.org/lkml/2014/10/10/272

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: wd at denx.de
I mean, I . . . think to understand you, I just don't know  what  you
are saying ...                        - Terry Pratchett, _Soul Music_

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-23 13:10         ` Wolfgang Denk
@ 2014-10-23 13:42           ` Dirk Eibach
  2014-10-24 14:14           ` Bill Pringlemeir
  2015-09-30 18:24           ` Andy Fleming
  2 siblings, 0 replies; 32+ messages in thread
From: Dirk Eibach @ 2014-10-23 13:42 UTC (permalink / raw)
  To: u-boot

Hello Wolfgang,

2014-10-23 15:10 GMT+02:00 Wolfgang Denk <wd@denx.de>:
> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?
>
> Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> doing [1] ?
>
> [1] https://lkml.org/lkml/2014/10/10/272

question is: what are the gcc folks going to do with the relro stuff?
It seems the sections are not used in 4.9.1, but will this be true for
future releases? If we are not absolutely sure they will not be used
anymore, adding them to the linker scripts is probably the best
option. Anybody with deeper gcc insights following this thread?

Cheers
Dirk

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-23 13:10         ` Wolfgang Denk
  2014-10-23 13:42           ` Dirk Eibach
@ 2014-10-24 14:14           ` Bill Pringlemeir
  2015-09-30 18:24           ` Andy Fleming
  2 siblings, 0 replies; 32+ messages in thread
From: Bill Pringlemeir @ 2014-10-24 14:14 UTC (permalink / raw)
  To: u-boot

On 23 Oct 2014, wd at denx.de wrote:

> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?
>
> Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> doing [1] ?
>
> [1] https://lkml.org/lkml/2014/10/10/272

My understanding is this is for a completely different issue.  The
proposed patch is,

+# if ((GCC_VERSION >= 40800 && GCC_VERSION <= 40802) || GCC_VERSION == 40900) \
+	&& defined(__arm__) && defined(CONFIG_FRAME_POINTER)
+#  error Your version of gcc miscompiles stack frames
+# endif

So, the proposed patch was blacklist gcc v4.8.[012] and 4.9.0 on the
*ARM* when frame pointer tracing is enabled.  This thread refers to a
different bug where 'sp' is adjusted for a return while the 'fp' will
still be references (for instance in a return calculation) above the
'sp'.  It is a completely different issue than the '.data.rel.ro' which
is on all architectures.

Also, if you read further in the thread, it seems that 4.9.0 does not
exhibit this problem.  The 4.9.0 was only suggested as the 'Known to
fail' of bug 58854 shows '4.9.0'.

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854

Apparently this was added during the 4.9.0 release process, but didn't
make it to the official release.  In any case, unless u-boot uses
signals and/or an interrupt stack common to the mainline, this bug would
not even affect the ARM cpus with U-boot.

On 23 Oct 2014, wd@denx.de wrote:

> 4) For the problemativ 4.8.x versions of GCC, the following patch
>   apparently solves the problem for my (MPC5200 based) board - guess
>   this would have to be applied to all .lds files...

>diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>index cd9e23f..82c86d7 100644
>--- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>+++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>@@ -27,6 +27,8 @@ SECTIONS
>   {
>     _GOT2_TABLE_ = .;
>     KEEP(*(.got2))
>+    KEEP(*(.data.rel.ro))
>+    KEEP(*(.data.rel.ro.local))
>     KEEP(*(.got))
>     PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
>     _FIXUP_TABLE_ = .;

> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?

From my perspective and reading the blog below this patch seems sensible. 

 http://www.airs.com/blog/archives/189

I assume u-boot has no MMU enabled, then all the relocations should be
similar.  This would be for all architectures though?

Fwiw,
Bill Pringlemeir.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2014-10-23 13:10         ` Wolfgang Denk
  2014-10-23 13:42           ` Dirk Eibach
  2014-10-24 14:14           ` Bill Pringlemeir
@ 2015-09-30 18:24           ` Andy Fleming
  2015-09-30 19:35             ` Marek Vasut
  2015-10-01 14:18             ` Wolfgang Denk
  2 siblings, 2 replies; 32+ messages in thread
From: Andy Fleming @ 2015-09-30 18:24 UTC (permalink / raw)
  To: u-boot

On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Joakim, dear Dirk,
>
> In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-C1257D7A.0024DEC4@transmode.se> you wrote:
>>
>> Ouch, that was a nasty surprise.
>
> Indeed.
>
>> > In my original mail I referenced this potential solution, at least it
>> > worked for me:
>> > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
>>
>> That looks like the correct fix but I presume both .data.rel.ro and
>> data.rel.ro.local should be added?
>
> I can confirm:
>
> 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
>    5.5.x].
>
> 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
>    problem go away.
>
> 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
>    the problem go away.
>
> 4) For the problemativ 4.8.x versions of GCC, the following patch
>    apparently solves the problem for my (MPC5200 based) board - guess
>    this would have to be applied to all .lds files...
>
> diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> index cd9e23f..82c86d7 100644
> --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> @@ -27,6 +27,8 @@ SECTIONS
>    {
>      _GOT2_TABLE_ = .;
>      KEEP(*(.got2))
> +    KEEP(*(.data.rel.ro))
> +    KEEP(*(.data.rel.ro.local))
>      KEEP(*(.got))
>      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
>      _FIXUP_TABLE_ = .;
>
> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?
>
> Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> doing [1] ?
>
> [1] https://lkml.org/lkml/2014/10/10/272

Was there a resolution to this thread? I just spent a bunch of time
trying to figure out why u-boot was crashing, and eventually
determined that switching from 4.9.0 to 4.6.3 solved the problem.
Should I submit a patch to do what was suggested above? Or add the
"blacklist" patch? If so, it should be noted that 4.9.0 is the current
default installed when you ask buildman to install a powerpc cross
compiler...

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-09-30 18:24           ` Andy Fleming
@ 2015-09-30 19:35             ` Marek Vasut
  2015-10-01  8:57               ` Joakim Tjernlund
  2015-10-01 14:18             ` Wolfgang Denk
  1 sibling, 1 reply; 32+ messages in thread
From: Marek Vasut @ 2015-09-30 19:35 UTC (permalink / raw)
  To: u-boot

On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:

Hi!

> On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Joakim, dear Dirk,
> > 
> > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
C1257D7A.0024DEC4@transmode.se> you wrote:
> >> Ouch, that was a nasty surprise.
> > 
> > Indeed.
> > 
> >> > In my original mail I referenced this potential solution, at least it
> >> > worked for me:
> >> > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> >> 
> >> That looks like the correct fix but I presume both .data.rel.ro and
> >> data.rel.ro.local should be added?
> > 
> > I can confirm:
> > 
> > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > 
> >    5.5.x].
> > 
> > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > 
> >    problem go away.
> > 
> > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > 
> >    the problem go away.
> > 
> > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > 
> >    apparently solves the problem for my (MPC5200 based) board - guess
> >    this would have to be applied to all .lds files...
> > 
> > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > @@ -27,6 +27,8 @@ SECTIONS
> > 
> >    {
> >    
> >      _GOT2_TABLE_ = .;
> >      KEEP(*(.got2))
> > 
> > +    KEEP(*(.data.rel.ro))
> > +    KEEP(*(.data.rel.ro.local))
> > 
> >      KEEP(*(.got))
> >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> >      _FIXUP_TABLE_ = .;
> > 
> > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > approach we should take?
> > 
> > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > doing [1] ?
> > 
> > [1] https://lkml.org/lkml/2014/10/10/272
> 
> Was there a resolution to this thread? I just spent a bunch of time
> trying to figure out why u-boot was crashing, and eventually
> determined that switching from 4.9.0 to 4.6.3 solved the problem.
> Should I submit a patch to do what was suggested above? Or add the
> "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> default installed when you ask buildman to install a powerpc cross
> compiler...

Blacklist patch please, thank you!

Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-09-30 19:35             ` Marek Vasut
@ 2015-10-01  8:57               ` Joakim Tjernlund
  2015-10-06 11:17                 ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-01  8:57 UTC (permalink / raw)
  To: u-boot

On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> 
> Hi!
> 
> > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > Dear Joakim, dear Dirk,
> > > 
> > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > Ouch, that was a nasty surprise.
> > > 
> > > Indeed.
> > > 
> > > > > In my original mail I referenced this potential solution, at least it
> > > > > worked for me:
> > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > 
> > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > data.rel.ro.local should be added?
> > > 
> > > I can confirm:
> > > 
> > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > 
> > >    5.5.x].
> > > 
> > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > 
> > >    problem go away.
> > > 
> > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > 
> > >    the problem go away.
> > > 
> > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > 
> > >    apparently solves the problem for my (MPC5200 based) board - guess
> > >    this would have to be applied to all .lds files...
> > > 
> > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > @@ -27,6 +27,8 @@ SECTIONS
> > > 
> > >    {
> > >    
> > >      _GOT2_TABLE_ = .;
> > >      KEEP(*(.got2))
> > > 
> > > +    KEEP(*(.data.rel.ro))
> > > +    KEEP(*(.data.rel.ro.local))
> > > 
> > >      KEEP(*(.got))
> > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > >      _FIXUP_TABLE_ = .;
> > > 
> > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > approach we should take?
> > > 
> > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > doing [1] ?
> > > 
> > > [1] https://lkml.org/lkml/2014/10/10/272
> > 
> > Was there a resolution to this thread? I just spent a bunch of time
> > trying to figure out why u-boot was crashing, and eventually
> > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > Should I submit a patch to do what was suggested above? Or add the
> > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > default installed when you ask buildman to install a powerpc cross
> > compiler...
> 
> Blacklist patch please, thank you!

Yes, but all gcc 4.8.x versions?

There is a fix here 
  https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
but I don't know if it got committed or not or which version.

I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
after relocation, u-boot misbehavex or crashes so there is something off still.

Does it work for all but me to erase u-boot after relocation?
Using T1040(mpc85xx family)

 Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-09-30 18:24           ` Andy Fleming
  2015-09-30 19:35             ` Marek Vasut
@ 2015-10-01 14:18             ` Wolfgang Denk
  2015-10-02 22:51               ` Andy Fleming
  1 sibling, 1 reply; 32+ messages in thread
From: Wolfgang Denk @ 2015-10-01 14:18 UTC (permalink / raw)
  To: u-boot

Dear Andy,

In message <CAKWjMd71hXW9-ahCUQm_rWS6z5Srd3My4TJ4x3KDRTdsHXHb=A@mail.gmail.com> you wrote:
>
> > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > approach we should take?
...
> Was there a resolution to this thread?

No, there was no real resolution.

My understanding was that there was an (unwritten) agreement that we
should avoid the broken GCC versions and switch to GCC 4.9.1 or later.

> I just spent a bunch of time
> trying to figure out why u-boot was crashing, and eventually
> determined that switching from 4.9.0 to 4.6.3 solved the problem.

Switching to GCC 4.9.1 is also supposed to work...

> Should I submit a patch to do what was suggested above? Or add the
> "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> default installed when you ask buildman to install a powerpc cross
> compiler...

In my opinion, we should blacklist the versions. 

But I am well aware that this would upset quite a lot of people as
their favorite toolchains would stop working, and not everybody is
really flexible here.

So perhaps a patch would be better - but how to test this? It is
probably not sufficient to fix the problem in
arch/powerpc/cpu/mpc5xxx/u-boot.lds - all the other linker sripts in
arch/powerpc/ look the same, so they probably need fixing, too.  And
what about the other architectures?  Should we fix ALL linker
scripts, even if we have no indication of breakage?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
To program is to be.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-01 14:18             ` Wolfgang Denk
@ 2015-10-02 22:51               ` Andy Fleming
  2015-10-03  8:33                 ` Wolfgang Denk
  0 siblings, 1 reply; 32+ messages in thread
From: Andy Fleming @ 2015-10-02 22:51 UTC (permalink / raw)
  To: u-boot

On Thu, Oct 1, 2015 at 9:18 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Andy,
>
> In message <CAKWjMd71hXW9-ahCUQm_rWS6z5Srd3My4TJ4x3KDRTdsHXHb=A@mail.gmail.com> you wrote:
>>
>> > Given that GCC 4.9.1 apparently solves this issue I wonder which
>> > approach we should take?
> ...
>> Was there a resolution to this thread?
>
> No, there was no real resolution.
>
> My understanding was that there was an (unwritten) agreement that we
> should avoid the broken GCC versions and switch to GCC 4.9.1 or later.
>
>> I just spent a bunch of time
>> trying to figure out why u-boot was crashing, and eventually
>> determined that switching from 4.9.0 to 4.6.3 solved the problem.
>
> Switching to GCC 4.9.1 is also supposed to work...

I haven't tried GCC 4.9.1, but I can now report that 4.6.3 didn't
totally work. There was a constant string whose address was not being
relocated. The result was that when I tried to boot, an sprintf
crashed while trying to find its "%s:%d" at the unrelocated address.
My familiarity with the relocation code is pretty weak, so I'm not
sure if there's a bug in the code or in the compiler.

However, I can note that adding the extra KEEP lines to the lds made
the crash go away:

--- a/arch/powerpc/cpu/mpc85xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot.lds
@@ -49,6 +49,8 @@ SECTIONS
   {
     _GOT2_TABLE_ = .;
     KEEP(*(.got2))
+    KEEP(*(.data.rel.ro))
+    KEEP(*(.data.rel.ro.local))
     KEEP(*(.got))
     PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
     _FIXUP_TABLE_ = .;


>
>> Should I submit a patch to do what was suggested above? Or add the
>> "blacklist" patch? If so, it should be noted that 4.9.0 is the current
>> default installed when you ask buildman to install a powerpc cross
>> compiler...
>
> In my opinion, we should blacklist the versions.
>
> But I am well aware that this would upset quite a lot of people as
> their favorite toolchains would stop working, and not everybody is
> really flexible here.

I'd be fine with blacklisting, but if we blacklist 4.9.0, it shouldn't
be the compiler that gets installed when you run buildman --fetch-arch
powerpc.

>
> So perhaps a patch would be better - but how to test this? It is
> probably not sufficient to fix the problem in
> arch/powerpc/cpu/mpc5xxx/u-boot.lds - all the other linker sripts in
> arch/powerpc/ look the same, so they probably need fixing, too.  And
> what about the other architectures?  Should we fix ALL linker
> scripts, even if we have no indication of breakage?

At the very least, I would want the fix in
arch/powerpc/cpu/mpc85xx/u-boot.lds. :)

That said, because the problem also exists in 4.6.3 (though it does
happen in a different place for me with that compiler), I worry that
there's a bug in powerpc relocation. It occurs to me that many systems
would not notice if some read-only values were read from flash instead
of DDR. The system I'm working on keeps its image on an SD card. Also,
the image size for this system is 768K instead of 512K, and I believe
that's mostly because of the data section.

I'm going to dig into it a bit more, but I'm confident the
blacklisting isn't enough.

Andy

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-02 22:51               ` Andy Fleming
@ 2015-10-03  8:33                 ` Wolfgang Denk
  0 siblings, 0 replies; 32+ messages in thread
From: Wolfgang Denk @ 2015-10-03  8:33 UTC (permalink / raw)
  To: u-boot

Dear Andy,

In message <CAKWjMd6f6zv4ZzRhf1WkRbDAN7aO+HULevhX=iSTvUk-r+aDoQ@mail.gmail.com> you wrote:
>
> At the very least, I would want the fix in
> arch/powerpc/cpu/mpc85xx/u-boot.lds. :)

Well, I observed the problems on MPC5200 ...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-01  8:57               ` Joakim Tjernlund
@ 2015-10-06 11:17                 ` Joakim Tjernlund
  2015-10-15 15:56                   ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-06 11:17 UTC (permalink / raw)
  To: u-boot

On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > 
> > Hi!
> > 
> > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > Dear Joakim, dear Dirk,
> > > > 
> > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > Ouch, that was a nasty surprise.
> > > > 
> > > > Indeed.
> > > > 
> > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > worked for me:
> > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > 
> > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > data.rel.ro.local should be added?
> > > > 
> > > > I can confirm:
> > > > 
> > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > 
> > > >    5.5.x].
> > > > 
> > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > 
> > > >    problem go away.
> > > > 
> > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > 
> > > >    the problem go away.
> > > > 
> > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > 
> > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > >    this would have to be applied to all .lds files...
> > > > 
> > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > 
> > > >    {
> > > >    
> > > >      _GOT2_TABLE_ = .;
> > > >      KEEP(*(.got2))
> > > > 
> > > > +    KEEP(*(.data.rel.ro))
> > > > +    KEEP(*(.data.rel.ro.local))
> > > > 
> > > >      KEEP(*(.got))
> > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > >      _FIXUP_TABLE_ = .;
> > > > 
> > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > approach we should take?
> > > > 
> > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > doing [1] ?
> > > > 
> > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > 
> > > Was there a resolution to this thread? I just spent a bunch of time
> > > trying to figure out why u-boot was crashing, and eventually
> > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > Should I submit a patch to do what was suggested above? Or add the
> > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > default installed when you ask buildman to install a powerpc cross
> > > compiler...
> > 
> > Blacklist patch please, thank you!
> 
> Yes, but all gcc 4.8.x versions?
> 
> There is a fix here 
>   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> but I don't know if it got committed or not or which version.
> 
> I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> after relocation, u-boot misbehavex or crashes so there is something off still.
> 
> Does it work for all but me to erase u-boot after relocation?
> Using T1040(mpc85xx family)

Here is a better URL:
http://patchwork.ozlabs.org/patch/342888/

From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
and 4.9.3 (by looking at varasm.c).

Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
correct fix as it is not an .fixup entry?

 Jocke 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-06 11:17                 ` Joakim Tjernlund
@ 2015-10-15 15:56                   ` Joakim Tjernlund
  2015-10-15 21:58                     ` Tom Rini
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-15 15:56 UTC (permalink / raw)
  To: u-boot

On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > 
> > > Hi!
> > > 
> > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > Dear Joakim, dear Dirk,
> > > > > 
> > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > Ouch, that was a nasty surprise.
> > > > > 
> > > > > Indeed.
> > > > > 
> > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > worked for me:
> > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > 
> > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > data.rel.ro.local should be added?
> > > > > 
> > > > > I can confirm:
> > > > > 
> > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > 
> > > > >    5.5.x].
> > > > > 
> > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > 
> > > > >    problem go away.
> > > > > 
> > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > 
> > > > >    the problem go away.
> > > > > 
> > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > 
> > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > >    this would have to be applied to all .lds files...
> > > > > 
> > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > 
> > > > >    {
> > > > >    
> > > > >      _GOT2_TABLE_ = .;
> > > > >      KEEP(*(.got2))
> > > > > 
> > > > > +    KEEP(*(.data.rel.ro))
> > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > 
> > > > >      KEEP(*(.got))
> > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > >      _FIXUP_TABLE_ = .;
> > > > > 
> > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > approach we should take?
> > > > > 
> > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > doing [1] ?
> > > > > 
> > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > 
> > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > trying to figure out why u-boot was crashing, and eventually
> > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > Should I submit a patch to do what was suggested above? Or add the
> > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > default installed when you ask buildman to install a powerpc cross
> > > > compiler...
> > > 
> > > Blacklist patch please, thank you!
> > 
> > Yes, but all gcc 4.8.x versions?
> > 
> > There is a fix here 
> >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > but I don't know if it got committed or not or which version.
> > 
> > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > after relocation, u-boot misbehavex or crashes so there is something off still.
> > 
> > Does it work for all but me to erase u-boot after relocation?
> > Using T1040(mpc85xx family)
> 
> Here is a better URL:
> http://patchwork.ozlabs.org/patch/342888/
> 
> From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> and 4.9.3 (by looking at varasm.c).
> 
> Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> correct fix as it is not an .fixup entry?

After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
throw in -mbss-plt to reduce size

 Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-15 15:56                   ` Joakim Tjernlund
@ 2015-10-15 21:58                     ` Tom Rini
  2015-10-16  6:55                       ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2015-10-15 21:58 UTC (permalink / raw)
  To: u-boot

On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > 
> > > > Hi!
> > > > 
> > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > Dear Joakim, dear Dirk,
> > > > > > 
> > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > Ouch, that was a nasty surprise.
> > > > > > 
> > > > > > Indeed.
> > > > > > 
> > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > worked for me:
> > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > 
> > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > data.rel.ro.local should be added?
> > > > > > 
> > > > > > I can confirm:
> > > > > > 
> > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > 
> > > > > >    5.5.x].
> > > > > > 
> > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > 
> > > > > >    problem go away.
> > > > > > 
> > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > 
> > > > > >    the problem go away.
> > > > > > 
> > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > 
> > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > >    this would have to be applied to all .lds files...
> > > > > > 
> > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > 
> > > > > >    {
> > > > > >    
> > > > > >      _GOT2_TABLE_ = .;
> > > > > >      KEEP(*(.got2))
> > > > > > 
> > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > 
> > > > > >      KEEP(*(.got))
> > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > >      _FIXUP_TABLE_ = .;
> > > > > > 
> > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > approach we should take?
> > > > > > 
> > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > doing [1] ?
> > > > > > 
> > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > 
> > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > default installed when you ask buildman to install a powerpc cross
> > > > > compiler...
> > > > 
> > > > Blacklist patch please, thank you!
> > > 
> > > Yes, but all gcc 4.8.x versions?
> > > 
> > > There is a fix here 
> > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > but I don't know if it got committed or not or which version.
> > > 
> > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > 
> > > Does it work for all but me to erase u-boot after relocation?
> > > Using T1040(mpc85xx family)
> > 
> > Here is a better URL:
> > http://patchwork.ozlabs.org/patch/342888/
> > 
> > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > and 4.9.3 (by looking at varasm.c).
> > 
> > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > correct fix as it is not an .fixup entry?
> 
> After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> throw in -mbss-plt to reduce size

Would something like this fix it then?  Or at least work-around in-field
toolchains?

diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index 83b49b5..2be5b46 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
 LDFLAGS_FINAL += --gc-sections
 LDFLAGS_FINAL += --bss-plt
 PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
--fdata-sections -mcall-linux
+-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
 
 PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
 PLATFORM_LDFLAGS  += -m32 -melf32ppclinux

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151015/a77b95c4/attachment.sig>

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-15 21:58                     ` Tom Rini
@ 2015-10-16  6:55                       ` Joakim Tjernlund
  2015-10-16 11:47                         ` Tom Rini
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-16  6:55 UTC (permalink / raw)
  To: u-boot

On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > Dear Joakim, dear Dirk,
> > > > > > > 
> > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > 
> > > > > > > Indeed.
> > > > > > > 
> > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > worked for me:
> > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > 
> > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > data.rel.ro.local should be added?
> > > > > > > 
> > > > > > > I can confirm:
> > > > > > > 
> > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > 
> > > > > > >    5.5.x].
> > > > > > > 
> > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > 
> > > > > > >    problem go away.
> > > > > > > 
> > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > 
> > > > > > >    the problem go away.
> > > > > > > 
> > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > 
> > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > >    this would have to be applied to all .lds files...
> > > > > > > 
> > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > 
> > > > > > >    {
> > > > > > >    
> > > > > > >      _GOT2_TABLE_ = .;
> > > > > > >      KEEP(*(.got2))
> > > > > > > 
> > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > 
> > > > > > >      KEEP(*(.got))
> > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > 
> > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > approach we should take?
> > > > > > > 
> > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > doing [1] ?
> > > > > > > 
> > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > 
> > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > compiler...
> > > > > 
> > > > > Blacklist patch please, thank you!
> > > > 
> > > > Yes, but all gcc 4.8.x versions?
> > > > 
> > > > There is a fix here 
> > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > but I don't know if it got committed or not or which version.
> > > > 
> > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > 
> > > > Does it work for all but me to erase u-boot after relocation?
> > > > Using T1040(mpc85xx family)
> > > 
> > > Here is a better URL:
> > > http://patchwork.ozlabs.org/patch/342888/
> > > 
> > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > and 4.9.3 (by looking at varasm.c).
> > > 
> > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > correct fix as it is not an .fixup entry?
> > 
> > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > throw in -mbss-plt to reduce size
> 
> Would something like this fix it then?  Or at least work-around in-field
> toolchains?
> 
> diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> index 83b49b5..2be5b46 100644
> --- a/arch/powerpc/config.mk
> +++ b/arch/powerpc/config.mk
> @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
>  LDFLAGS_FINAL += --gc-sections
>  LDFLAGS_FINAL += --bss-plt
>  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> --fdata-sections -mcall-linux
> +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
>  
>  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
>  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> 

In theory yes, that is what the above URLs claim and what my small compile tests supports.
In addition, this works for me now:
=> printenv tftpflash 
tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize


=> run tftpflash 
Using FM1 at DTSEC1 device
TFTP from server 172.20.4.10; our IP address is 172.20.4.13
Filename 'u-boot.bin'.
Load address: 0x1000000
Loading: ######################################################
	 7.4 MiB/s
done
Bytes transferred = 786432 (c0000 hex)
...... done
Un-Protected 6 sectors

...... done
Erased 6 sectors
Copy to Flash... 9....8....7....6....5....4....3....2....1....done
...... done
Protected 6 sectors
Total of 786432 byte(s) were the same

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-16  6:55                       ` Joakim Tjernlund
@ 2015-10-16 11:47                         ` Tom Rini
  2015-10-16 13:14                           ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2015-10-16 11:47 UTC (permalink / raw)
  To: u-boot

On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > > 
> > > > > > Hi!
> > > > > > 
> > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > > Dear Joakim, dear Dirk,
> > > > > > > > 
> > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > > 
> > > > > > > > Indeed.
> > > > > > > > 
> > > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > > worked for me:
> > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > > 
> > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > > data.rel.ro.local should be added?
> > > > > > > > 
> > > > > > > > I can confirm:
> > > > > > > > 
> > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > > 
> > > > > > > >    5.5.x].
> > > > > > > > 
> > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > > 
> > > > > > > >    problem go away.
> > > > > > > > 
> > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > > 
> > > > > > > >    the problem go away.
> > > > > > > > 
> > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > > 
> > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > > >    this would have to be applied to all .lds files...
> > > > > > > > 
> > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > > 
> > > > > > > >    {
> > > > > > > >    
> > > > > > > >      _GOT2_TABLE_ = .;
> > > > > > > >      KEEP(*(.got2))
> > > > > > > > 
> > > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > > 
> > > > > > > >      KEEP(*(.got))
> > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > > 
> > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > > approach we should take?
> > > > > > > > 
> > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > > doing [1] ?
> > > > > > > > 
> > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > > 
> > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > > compiler...
> > > > > > 
> > > > > > Blacklist patch please, thank you!
> > > > > 
> > > > > Yes, but all gcc 4.8.x versions?
> > > > > 
> > > > > There is a fix here 
> > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > > but I don't know if it got committed or not or which version.
> > > > > 
> > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > > 
> > > > > Does it work for all but me to erase u-boot after relocation?
> > > > > Using T1040(mpc85xx family)
> > > > 
> > > > Here is a better URL:
> > > > http://patchwork.ozlabs.org/patch/342888/
> > > > 
> > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > > and 4.9.3 (by looking at varasm.c).
> > > > 
> > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > > correct fix as it is not an .fixup entry?
> > > 
> > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > throw in -mbss-plt to reduce size
> > 
> > Would something like this fix it then?  Or at least work-around in-field
> > toolchains?
> > 
> > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > index 83b49b5..2be5b46 100644
> > --- a/arch/powerpc/config.mk
> > +++ b/arch/powerpc/config.mk
> > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> >  LDFLAGS_FINAL += --gc-sections
> >  LDFLAGS_FINAL += --bss-plt
> >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > --fdata-sections -mcall-linux
> > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> >  
> >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > 
> 
> In theory yes, that is what the above URLs claim and what my small compile tests supports.
> In addition, this works for me now:
> => printenv tftpflash 
> tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize
> 
> 
> => run tftpflash 
> Using FM1 at DTSEC1 device
> TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> Filename 'u-boot.bin'.
> Load address: 0x1000000
> Loading: ######################################################
> 	 7.4 MiB/s
> done
> Bytes transferred = 786432 (c0000 hex)
> ...... done
> Un-Protected 6 sectors
> 
> ...... done
> Erased 6 sectors
> Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> ...... done
> Protected 6 sectors
> Total of 786432 byte(s) were the same

OK.  Do you have some of the broken older toolchains as well?  I think
this will at least correct 4.9 and maybe 4.8, but older toolchains don't
have that option (but if there's another option for making older still
toolchains work, we can do that too on the other side of the cc-option).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151016/d17be53c/attachment.sig>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-16 11:47                         ` Tom Rini
@ 2015-10-16 13:14                           ` Joakim Tjernlund
  2015-10-20 21:06                             ` Andy Fleming
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-16 13:14 UTC (permalink / raw)
  To: u-boot

On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > > > 
> > > > > > > Hi!
> > > > > > > 
> > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > > > Dear Joakim, dear Dirk,
> > > > > > > > > 
> > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > > > 
> > > > > > > > > Indeed.
> > > > > > > > > 
> > > > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > > > worked for me:
> > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > > > 
> > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > > > data.rel.ro.local should be added?
> > > > > > > > > 
> > > > > > > > > I can confirm:
> > > > > > > > > 
> > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > > > 
> > > > > > > > >    5.5.x].
> > > > > > > > > 
> > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > > > 
> > > > > > > > >    problem go away.
> > > > > > > > > 
> > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > > > 
> > > > > > > > >    the problem go away.
> > > > > > > > > 
> > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > > > 
> > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > > > >    this would have to be applied to all .lds files...
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > > > 
> > > > > > > > >    {
> > > > > > > > >    
> > > > > > > > >      _GOT2_TABLE_ = .;
> > > > > > > > >      KEEP(*(.got2))
> > > > > > > > > 
> > > > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > > > 
> > > > > > > > >      KEEP(*(.got))
> > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > > > 
> > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > > > approach we should take?
> > > > > > > > > 
> > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > > > doing [1] ?
> > > > > > > > > 
> > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > > > 
> > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > > > compiler...
> > > > > > > 
> > > > > > > Blacklist patch please, thank you!
> > > > > > 
> > > > > > Yes, but all gcc 4.8.x versions?
> > > > > > 
> > > > > > There is a fix here 
> > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > > > but I don't know if it got committed or not or which version.
> > > > > > 
> > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > > > 
> > > > > > Does it work for all but me to erase u-boot after relocation?
> > > > > > Using T1040(mpc85xx family)
> > > > > 
> > > > > Here is a better URL:
> > > > > http://patchwork.ozlabs.org/patch/342888/
> > > > > 
> > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > > > and 4.9.3 (by looking at varasm.c).
> > > > > 
> > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > > > correct fix as it is not an .fixup entry?
> > > > 
> > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > > throw in -mbss-plt to reduce size
> > > 
> > > Would something like this fix it then?  Or at least work-around in-field
> > > toolchains?
> > > 
> > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > > index 83b49b5..2be5b46 100644
> > > --- a/arch/powerpc/config.mk
> > > +++ b/arch/powerpc/config.mk
> > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> > >  LDFLAGS_FINAL += --gc-sections
> > >  LDFLAGS_FINAL += --bss-plt
> > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > > --fdata-sections -mcall-linux
> > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> > >  
> > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > > 
> > 
> > In theory yes, that is what the above URLs claim and what my small compile tests supports.
> > In addition, this works for me now:
> > => printenv tftpflash 
> > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize &&
> > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr
> > $filesize
> > 
> > 
> > => run tftpflash 
> > Using FM1 at DTSEC1 device
> > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> > Filename 'u-boot.bin'.
> > Load address: 0x1000000
> > Loading: ######################################################
> > 	 7.4 MiB/s
> > done
> > Bytes transferred = 786432 (c0000 hex)
> > ...... done
> > Un-Protected 6 sectors
> > 
> > ...... done
> > Erased 6 sectors
> > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> > ...... done
> > Protected 6 sectors
> > Total of 786432 byte(s) were the same
> 
> OK.  Do you have some of the broken older toolchains as well?  I think
> this will at least correct 4.9 and maybe 4.8, but older toolchains don't
> have that option (but if there's another option for making older still
> toolchains work, we can do that too on the other side of the cc-option).

I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.

I don't think this bug is present on older(<4.8) gcc's, the author to the patch
claims that bug is not present in gcc 4.7.3

My old gcc 4.5.3 works fine also

   Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-16 13:14                           ` Joakim Tjernlund
@ 2015-10-20 21:06                             ` Andy Fleming
  2015-10-20 21:21                               ` Tom Rini
  0 siblings, 1 reply; 32+ messages in thread
From: Andy Fleming @ 2015-10-20 21:06 UTC (permalink / raw)
  To: u-boot

On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
>> On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
>> > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
>> > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
>> > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
>> > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
>> > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
>> > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
>> > > > > > >
>> > > > > > > Hi!
>> > > > > > >
>> > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
>> > > > > > > > > Dear Joakim, dear Dirk,
>> > > > > > > > >
>> > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
>> > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
>> > > > > > > > > > Ouch, that was a nasty surprise.
>> > > > > > > > >
>> > > > > > > > > Indeed.
>> > > > > > > > >
>> > > > > > > > > > > In my original mail I referenced this potential solution, at least it
>> > > > > > > > > > > worked for me:
>> > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
>> > > > > > > > > >
>> > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
>> > > > > > > > > > data.rel.ro.local should be added?
>> > > > > > > > >
>> > > > > > > > > I can confirm:
>> > > > > > > > >
>> > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
>> > > > > > > > >
>> > > > > > > > >    5.5.x].
>> > > > > > > > >
>> > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
>> > > > > > > > >
>> > > > > > > > >    problem go away.
>> > > > > > > > >
>> > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
>> > > > > > > > >
>> > > > > > > > >    the problem go away.
>> > > > > > > > >
>> > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
>> > > > > > > > >
>> > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
>> > > > > > > > >    this would have to be applied to all .lds files...
>> > > > > > > > >
>> > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
>> > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>> > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
>> > > > > > > > >
>> > > > > > > > >    {
>> > > > > > > > >
>> > > > > > > > >      _GOT2_TABLE_ = .;
>> > > > > > > > >      KEEP(*(.got2))
>> > > > > > > > >
>> > > > > > > > > +    KEEP(*(.data.rel.ro))
>> > > > > > > > > +    KEEP(*(.data.rel.ro.local))
>> > > > > > > > >
>> > > > > > > > >      KEEP(*(.got))
>> > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
>> > > > > > > > >      _FIXUP_TABLE_ = .;
>> > > > > > > > >
>> > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
>> > > > > > > > > approach we should take?
>> > > > > > > > >
>> > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
>> > > > > > > > > doing [1] ?
>> > > > > > > > >
>> > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
>> > > > > > > >
>> > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
>> > > > > > > > trying to figure out why u-boot was crashing, and eventually
>> > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
>> > > > > > > > Should I submit a patch to do what was suggested above? Or add the
>> > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
>> > > > > > > > default installed when you ask buildman to install a powerpc cross
>> > > > > > > > compiler...
>> > > > > > >
>> > > > > > > Blacklist patch please, thank you!
>> > > > > >
>> > > > > > Yes, but all gcc 4.8.x versions?
>> > > > > >
>> > > > > > There is a fix here
>> > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
>> > > > > > but I don't know if it got committed or not or which version.
>> > > > > >
>> > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
>> > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
>> > > > > >
>> > > > > > Does it work for all but me to erase u-boot after relocation?
>> > > > > > Using T1040(mpc85xx family)
>> > > > >
>> > > > > Here is a better URL:
>> > > > > http://patchwork.ozlabs.org/patch/342888/
>> > > > >
>> > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
>> > > > > and 4.9.3 (by looking at varasm.c).
>> > > > >
>> > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
>> > > > > correct fix as it is not an .fixup entry?
>> > > >
>> > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
>> > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
>> > > > throw in -mbss-plt to reduce size
>> > >
>> > > Would something like this fix it then?  Or at least work-around in-field
>> > > toolchains?
>> > >
>> > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
>> > > index 83b49b5..2be5b46 100644
>> > > --- a/arch/powerpc/config.mk
>> > > +++ b/arch/powerpc/config.mk
>> > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
>> > >  LDFLAGS_FINAL += --gc-sections
>> > >  LDFLAGS_FINAL += --bss-plt
>> > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
>> > > --fdata-sections -mcall-linux
>> > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
>> > >
>> > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
>> > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
>> > >
>> >
>> > In theory yes, that is what the above URLs claim and what my small compile tests supports.
>> > In addition, this works for me now:
>> > => printenv tftpflash
>> > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize &&
>> > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr
>> > $filesize
>> >
>> >
>> > => run tftpflash
>> > Using FM1 at DTSEC1 device
>> > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
>> > Filename 'u-boot.bin'.
>> > Load address: 0x1000000
>> > Loading: ######################################################
>> >      7.4 MiB/s
>> > done
>> > Bytes transferred = 786432 (c0000 hex)
>> > ...... done
>> > Un-Protected 6 sectors
>> >
>> > ...... done
>> > Erased 6 sectors
>> > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
>> > ...... done
>> > Protected 6 sectors
>> > Total of 786432 byte(s) were the same
>>
>> OK.  Do you have some of the broken older toolchains as well?  I think
>> this will at least correct 4.9 and maybe 4.8, but older toolchains don't
>> have that option (but if there's another option for making older still
>> toolchains work, we can do that too on the other side of the cc-option).
>
> I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
>
> I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> claims that bug is not present in gcc 4.7.3
>
> My old gcc 4.5.3 works fine also

My 4.6.3 has the issue (but it shows up in a different place than with
my 4.8.3).

Andy

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-20 21:06                             ` Andy Fleming
@ 2015-10-20 21:21                               ` Tom Rini
  2015-10-21  8:44                                 ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2015-10-20 21:21 UTC (permalink / raw)
  To: u-boot

On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> >> On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> >> > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> >> > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> >> > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> >> > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> >> > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> >> > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> >> > > > > > >
> >> > > > > > > Hi!
> >> > > > > > >
> >> > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> >> > > > > > > > > Dear Joakim, dear Dirk,
> >> > > > > > > > >
> >> > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> >> > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> >> > > > > > > > > > Ouch, that was a nasty surprise.
> >> > > > > > > > >
> >> > > > > > > > > Indeed.
> >> > > > > > > > >
> >> > > > > > > > > > > In my original mail I referenced this potential solution, at least it
> >> > > > > > > > > > > worked for me:
> >> > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> >> > > > > > > > > >
> >> > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> >> > > > > > > > > > data.rel.ro.local should be added?
> >> > > > > > > > >
> >> > > > > > > > > I can confirm:
> >> > > > > > > > >
> >> > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> >> > > > > > > > >
> >> > > > > > > > >    5.5.x].
> >> > > > > > > > >
> >> > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> >> > > > > > > > >
> >> > > > > > > > >    problem go away.
> >> > > > > > > > >
> >> > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> >> > > > > > > > >
> >> > > > > > > > >    the problem go away.
> >> > > > > > > > >
> >> > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> >> > > > > > > > >
> >> > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> >> > > > > > > > >    this would have to be applied to all .lds files...
> >> > > > > > > > >
> >> > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> >> > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> >> > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> >> > > > > > > > >
> >> > > > > > > > >    {
> >> > > > > > > > >
> >> > > > > > > > >      _GOT2_TABLE_ = .;
> >> > > > > > > > >      KEEP(*(.got2))
> >> > > > > > > > >
> >> > > > > > > > > +    KEEP(*(.data.rel.ro))
> >> > > > > > > > > +    KEEP(*(.data.rel.ro.local))
> >> > > > > > > > >
> >> > > > > > > > >      KEEP(*(.got))
> >> > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> >> > > > > > > > >      _FIXUP_TABLE_ = .;
> >> > > > > > > > >
> >> > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> >> > > > > > > > > approach we should take?
> >> > > > > > > > >
> >> > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> >> > > > > > > > > doing [1] ?
> >> > > > > > > > >
> >> > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> >> > > > > > > >
> >> > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> >> > > > > > > > trying to figure out why u-boot was crashing, and eventually
> >> > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> >> > > > > > > > Should I submit a patch to do what was suggested above? Or add the
> >> > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> >> > > > > > > > default installed when you ask buildman to install a powerpc cross
> >> > > > > > > > compiler...
> >> > > > > > >
> >> > > > > > > Blacklist patch please, thank you!
> >> > > > > >
> >> > > > > > Yes, but all gcc 4.8.x versions?
> >> > > > > >
> >> > > > > > There is a fix here
> >> > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> >> > > > > > but I don't know if it got committed or not or which version.
> >> > > > > >
> >> > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> >> > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> >> > > > > >
> >> > > > > > Does it work for all but me to erase u-boot after relocation?
> >> > > > > > Using T1040(mpc85xx family)
> >> > > > >
> >> > > > > Here is a better URL:
> >> > > > > http://patchwork.ozlabs.org/patch/342888/
> >> > > > >
> >> > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> >> > > > > and 4.9.3 (by looking at varasm.c).
> >> > > > >
> >> > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> >> > > > > correct fix as it is not an .fixup entry?
> >> > > >
> >> > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> >> > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> >> > > > throw in -mbss-plt to reduce size
> >> > >
> >> > > Would something like this fix it then?  Or at least work-around in-field
> >> > > toolchains?
> >> > >
> >> > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> >> > > index 83b49b5..2be5b46 100644
> >> > > --- a/arch/powerpc/config.mk
> >> > > +++ b/arch/powerpc/config.mk
> >> > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> >> > >  LDFLAGS_FINAL += --gc-sections
> >> > >  LDFLAGS_FINAL += --bss-plt
> >> > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> >> > > --fdata-sections -mcall-linux
> >> > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> >> > >
> >> > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> >> > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> >> > >
> >> >
> >> > In theory yes, that is what the above URLs claim and what my small compile tests supports.
> >> > In addition, this works for me now:
> >> > => printenv tftpflash
> >> > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize &&
> >> > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr
> >> > $filesize
> >> >
> >> >
> >> > => run tftpflash
> >> > Using FM1 at DTSEC1 device
> >> > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> >> > Filename 'u-boot.bin'.
> >> > Load address: 0x1000000
> >> > Loading: ######################################################
> >> >      7.4 MiB/s
> >> > done
> >> > Bytes transferred = 786432 (c0000 hex)
> >> > ...... done
> >> > Un-Protected 6 sectors
> >> >
> >> > ...... done
> >> > Erased 6 sectors
> >> > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> >> > ...... done
> >> > Protected 6 sectors
> >> > Total of 786432 byte(s) were the same
> >>
> >> OK.  Do you have some of the broken older toolchains as well?  I think
> >> this will at least correct 4.9 and maybe 4.8, but older toolchains don't
> >> have that option (but if there's another option for making older still
> >> toolchains work, we can do that too on the other side of the cc-option).
> >
> > I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
> >
> > I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> > claims that bug is not present in gcc 4.7.3
> >
> > My old gcc 4.5.3 works fine also
> 
> My 4.6.3 has the issue (but it shows up in a different place than with
> my 4.8.3).

Then we need a different flag there :(  Does what Joakim found maybe
provide a hint?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151020/e94b9a7c/attachment.sig>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-20 21:21                               ` Tom Rini
@ 2015-10-21  8:44                                 ` Joakim Tjernlund
  2015-10-21 13:12                                   ` Tom Rini
  0 siblings, 1 reply; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-21  8:44 UTC (permalink / raw)
  To: u-boot

On Tue, 2015-10-20 at 17:21 -0400, Tom Rini wrote:
> On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> > On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> > > > On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> > > > > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > > > > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > > > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > > > > > > 
> > > > > > > > > > Hi!
> > > > > > > > > > 
> > > > > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > > > > > > Dear Joakim, dear Dirk,
> > > > > > > > > > > > 
> > > > > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > > > > > > 
> > > > > > > > > > > > Indeed.
> > > > > > > > > > > > 
> > > > > > > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > > > > > > worked for me:
> > > > > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > > > > > > 
> > > > > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > > > > > > data.rel.ro.local should be added?
> > > > > > > > > > > > 
> > > > > > > > > > > > I can confirm:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > > > > > > 
> > > > > > > > > > > >    5.5.x].
> > > > > > > > > > > > 
> > > > > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > > > > > > 
> > > > > > > > > > > >    problem go away.
> > > > > > > > > > > > 
> > > > > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > > > > > > 
> > > > > > > > > > > >    the problem go away.
> > > > > > > > > > > > 
> > > > > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > > > > > > 
> > > > > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > > > > > > >    this would have to be applied to all .lds files...
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > > > > > > 
> > > > > > > > > > > >    {
> > > > > > > > > > > > 
> > > > > > > > > > > >      _GOT2_TABLE_ = .;
> > > > > > > > > > > >      KEEP(*(.got2))
> > > > > > > > > > > > 
> > > > > > > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > > > > > > 
> > > > > > > > > > > >      KEEP(*(.got))
> > > > > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > > > > > > 
> > > > > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > > > > > > approach we should take?
> > > > > > > > > > > > 
> > > > > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > > > > > > doing [1] ?
> > > > > > > > > > > > 
> > > > > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > > > > > > 
> > > > > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > > > > > > compiler...
> > > > > > > > > > 
> > > > > > > > > > Blacklist patch please, thank you!
> > > > > > > > > 
> > > > > > > > > Yes, but all gcc 4.8.x versions?
> > > > > > > > > 
> > > > > > > > > There is a fix here
> > > > > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > > > > > > but I don't know if it got committed or not or which version.
> > > > > > > > > 
> > > > > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > > > > > > 
> > > > > > > > > Does it work for all but me to erase u-boot after relocation?
> > > > > > > > > Using T1040(mpc85xx family)
> > > > > > > > 
> > > > > > > > Here is a better URL:
> > > > > > > > http://patchwork.ozlabs.org/patch/342888/
> > > > > > > > 
> > > > > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > > > > > > and 4.9.3 (by looking at varasm.c).
> > > > > > > > 
> > > > > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > > > > > > correct fix as it is not an .fixup entry?
> > > > > > > 
> > > > > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > > > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > > > > > throw in -mbss-plt to reduce size
> > > > > > 
> > > > > > Would something like this fix it then?  Or at least work-around in-field
> > > > > > toolchains?
> > > > > > 
> > > > > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > > > > > index 83b49b5..2be5b46 100644
> > > > > > --- a/arch/powerpc/config.mk
> > > > > > +++ b/arch/powerpc/config.mk
> > > > > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> > > > > >  LDFLAGS_FINAL += --gc-sections
> > > > > >  LDFLAGS_FINAL += --bss-plt
> > > > > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > > > > > --fdata-sections -mcall-linux
> > > > > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> > > > > > 
> > > > > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> > > > > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > > > > > 
> > > > > 
> > > > > In theory yes, that is what the above URLs claim and what my small compile tests supports.
> > > > > In addition, this works for me now:
> > > > > => printenv tftpflash
> > > > > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr
> > > > > +$filesize &&
> > > > > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr
> > > > > $ubootaddr
> > > > > $filesize
> > > > > 
> > > > > 
> > > > > => run tftpflash
> > > > > Using FM1 at DTSEC1 device
> > > > > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> > > > > Filename 'u-boot.bin'.
> > > > > Load address: 0x1000000
> > > > > Loading: ######################################################
> > > > >      7.4 MiB/s
> > > > > done
> > > > > Bytes transferred = 786432 (c0000 hex)
> > > > > ...... done
> > > > > Un-Protected 6 sectors
> > > > > 
> > > > > ...... done
> > > > > Erased 6 sectors
> > > > > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> > > > > ...... done
> > > > > Protected 6 sectors
> > > > > Total of 786432 byte(s) were the same
> > > > 
> > > > OK.  Do you have some of the broken older toolchains as well?  I think
> > > > this will at least correct 4.9 and maybe 4.8, but older toolchains don't
> > > > have that option (but if there's another option for making older still
> > > > toolchains work, we can do that too on the other side of the cc-option).
> > > 
> > > I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
> > > 
> > > I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> > > claims that bug is not present in gcc 4.7.3
> > > 
> > > My old gcc 4.5.3 works fine also
> > 
> > My 4.6.3 has the issue (but it shows up in a different place than with
> > my 4.8.3).
> 
> Then we need a different flag there :(  Does what Joakim found maybe
> provide a hint?
> 

Different? Does not -fno-ira-hoist-pressure help for all gcc's ?
-fno-ira-hoist-pressure is an optimization that u-boot can be without.

    Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-21  8:44                                 ` Joakim Tjernlund
@ 2015-10-21 13:12                                   ` Tom Rini
  2015-10-21 13:18                                     ` Joakim Tjernlund
  0 siblings, 1 reply; 32+ messages in thread
From: Tom Rini @ 2015-10-21 13:12 UTC (permalink / raw)
  To: u-boot

On Wed, Oct 21, 2015 at 08:44:15AM +0000, Joakim Tjernlund wrote:
> On Tue, 2015-10-20 at 17:21 -0400, Tom Rini wrote:
> > On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> > > On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
> > > <joakim.tjernlund@transmode.se> wrote:
> > > > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> > > > > On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> > > > > > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > > > > > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > > > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > > > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Hi!
> > > > > > > > > > > 
> > > > > > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > > > > > > > Dear Joakim, dear Dirk,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Indeed.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > > > > > > > worked for me:
> > > > > > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > > > > > > > data.rel.ro.local should be added?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I can confirm:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    5.5.x].
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    problem go away.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    the problem go away.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > > > > > > > >    this would have to be applied to all .lds files...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > > > > > > > 
> > > > > > > > > > > > >    {
> > > > > > > > > > > > > 
> > > > > > > > > > > > >      _GOT2_TABLE_ = .;
> > > > > > > > > > > > >      KEEP(*(.got2))
> > > > > > > > > > > > > 
> > > > > > > > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > > > > > > > 
> > > > > > > > > > > > >      KEEP(*(.got))
> > > > > > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > > > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > > > > > > > approach we should take?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > > > > > > > doing [1] ?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > > > > > > > 
> > > > > > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > > > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > > > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > > > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > > > > > > > compiler...
> > > > > > > > > > > 
> > > > > > > > > > > Blacklist patch please, thank you!
> > > > > > > > > > 
> > > > > > > > > > Yes, but all gcc 4.8.x versions?
> > > > > > > > > > 
> > > > > > > > > > There is a fix here
> > > > > > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > > > > > > > but I don't know if it got committed or not or which version.
> > > > > > > > > > 
> > > > > > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > > > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > > > > > > > 
> > > > > > > > > > Does it work for all but me to erase u-boot after relocation?
> > > > > > > > > > Using T1040(mpc85xx family)
> > > > > > > > > 
> > > > > > > > > Here is a better URL:
> > > > > > > > > http://patchwork.ozlabs.org/patch/342888/
> > > > > > > > > 
> > > > > > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > > > > > > > and 4.9.3 (by looking at varasm.c).
> > > > > > > > > 
> > > > > > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > > > > > > > correct fix as it is not an .fixup entry?
> > > > > > > > 
> > > > > > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > > > > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > > > > > > throw in -mbss-plt to reduce size
> > > > > > > 
> > > > > > > Would something like this fix it then?  Or at least work-around in-field
> > > > > > > toolchains?
> > > > > > > 
> > > > > > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > > > > > > index 83b49b5..2be5b46 100644
> > > > > > > --- a/arch/powerpc/config.mk
> > > > > > > +++ b/arch/powerpc/config.mk
> > > > > > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> > > > > > >  LDFLAGS_FINAL += --gc-sections
> > > > > > >  LDFLAGS_FINAL += --bss-plt
> > > > > > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > > > > > > --fdata-sections -mcall-linux
> > > > > > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> > > > > > > 
> > > > > > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> > > > > > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > > > > > > 
> > > > > > 
> > > > > > In theory yes, that is what the above URLs claim and what my small compile tests supports.
> > > > > > In addition, this works for me now:
> > > > > > => printenv tftpflash
> > > > > > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr
> > > > > > +$filesize &&
> > > > > > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr
> > > > > > $ubootaddr
> > > > > > $filesize
> > > > > > 
> > > > > > 
> > > > > > => run tftpflash
> > > > > > Using FM1 at DTSEC1 device
> > > > > > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> > > > > > Filename 'u-boot.bin'.
> > > > > > Load address: 0x1000000
> > > > > > Loading: ######################################################
> > > > > >      7.4 MiB/s
> > > > > > done
> > > > > > Bytes transferred = 786432 (c0000 hex)
> > > > > > ...... done
> > > > > > Un-Protected 6 sectors
> > > > > > 
> > > > > > ...... done
> > > > > > Erased 6 sectors
> > > > > > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> > > > > > ...... done
> > > > > > Protected 6 sectors
> > > > > > Total of 786432 byte(s) were the same
> > > > > 
> > > > > OK.  Do you have some of the broken older toolchains as well?  I think
> > > > > this will at least correct 4.9 and maybe 4.8, but older toolchains don't
> > > > > have that option (but if there's another option for making older still
> > > > > toolchains work, we can do that too on the other side of the cc-option).
> > > > 
> > > > I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
> > > > 
> > > > I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> > > > claims that bug is not present in gcc 4.7.3
> > > > 
> > > > My old gcc 4.5.3 works fine also
> > > 
> > > My 4.6.3 has the issue (but it shows up in a different place than with
> > > my 4.8.3).
> > 
> > Then we need a different flag there :(  Does what Joakim found maybe
> > provide a hint?
> > 
> 
> Different? Does not -fno-ira-hoist-pressure help for all gcc's ?
> -fno-ira-hoist-pressure is an optimization that u-boot can be without.

I swear that I tried with my 4.7.2 toolchain (ELDK-5.3) and it didn't
know about that option.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151021/cea58a7f/attachment.sig>

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [U-Boot] Relocation issue - need help!
  2015-10-21 13:12                                   ` Tom Rini
@ 2015-10-21 13:18                                     ` Joakim Tjernlund
  0 siblings, 0 replies; 32+ messages in thread
From: Joakim Tjernlund @ 2015-10-21 13:18 UTC (permalink / raw)
  To: u-boot

On Wed, 2015-10-21 at 09:12 -0400, Tom Rini wrote:
> On Wed, Oct 21, 2015 at 08:44:15AM +0000, Joakim Tjernlund wrote:
> > On Tue, 2015-10-20 at 17:21 -0400, Tom Rini wrote:
> > > On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> > > > On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
> > > > <joakim.tjernlund@transmode.se> wrote:
> > > > > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> > > > > > On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> > > > > > > On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > > > > > > > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > > > > > > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > > > > > > > On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> > > > > > > > > > > On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > > > > > > > > > > > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi!
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > > > > > > > > > > > Dear Joakim, dear Dirk,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > > > > > > > > > > > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > > > > > > > > > > > Ouch, that was a nasty surprise.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Indeed.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > > > > > > > > > > > worked for me:
> > > > > > > > > > > > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > > > > > > > > > > > data.rel.ro.local should be added?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I can confirm:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    5.5.x].
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    problem go away.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    the problem go away.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > > > > > > > > > > > >    this would have to be applied to all .lds files...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > > > > > > > > > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > > > > > > > > > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >    {
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >      _GOT2_TABLE_ = .;
> > > > > > > > > > > > > >      KEEP(*(.got2))
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +    KEEP(*(.data.rel.ro))
> > > > > > > > > > > > > > +    KEEP(*(.data.rel.ro.local))
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >      KEEP(*(.got))
> > > > > > > > > > > > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > > > > > > > > > > > >      _FIXUP_TABLE_ = .;
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > > > > > > > > > > > approach we should take?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > > > > > > > > > > > doing [1] ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Was there a resolution to this thread? I just spent a bunch of time
> > > > > > > > > > > > > trying to figure out why u-boot was crashing, and eventually
> > > > > > > > > > > > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > > > > > > > > > > > Should I submit a patch to do what was suggested above? Or add the
> > > > > > > > > > > > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > > > > > > > > > > > default installed when you ask buildman to install a powerpc cross
> > > > > > > > > > > > > compiler...
> > > > > > > > > > > > 
> > > > > > > > > > > > Blacklist patch please, thank you!
> > > > > > > > > > > 
> > > > > > > > > > > Yes, but all gcc 4.8.x versions?
> > > > > > > > > > > 
> > > > > > > > > > > There is a fix here
> > > > > > > > > > >   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> > > > > > > > > > > but I don't know if it got committed or not or which version.
> > > > > > > > > > > 
> > > > > > > > > > > I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> > > > > > > > > > > after relocation, u-boot misbehavex or crashes so there is something off still.
> > > > > > > > > > > 
> > > > > > > > > > > Does it work for all but me to erase u-boot after relocation?
> > > > > > > > > > > Using T1040(mpc85xx family)
> > > > > > > > > > 
> > > > > > > > > > Here is a better URL:
> > > > > > > > > > http://patchwork.ozlabs.org/patch/342888/
> > > > > > > > > > 
> > > > > > > > > > From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
> > > > > > > > > > and 4.9.3 (by looking at varasm.c).
> > > > > > > > > > 
> > > > > > > > > > Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
> > > > > > > > > > correct fix as it is not an .fixup entry?
> > > > > > > > > 
> > > > > > > > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > > > > > > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > > > > > > > throw in -mbss-plt to reduce size
> > > > > > > > 
> > > > > > > > Would something like this fix it then?  Or at least work-around in-field
> > > > > > > > toolchains?
> > > > > > > > 
> > > > > > > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > > > > > > > index 83b49b5..2be5b46 100644
> > > > > > > > --- a/arch/powerpc/config.mk
> > > > > > > > +++ b/arch/powerpc/config.mk
> > > > > > > > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> > > > > > > >  LDFLAGS_FINAL += --gc-sections
> > > > > > > >  LDFLAGS_FINAL += --bss-plt
> > > > > > > >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > > > > > > > --fdata-sections -mcall-linux
> > > > > > > > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> > > > > > > > 
> > > > > > > >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> > > > > > > >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > > > > > > > 
> > > > > > > 
> > > > > > > In theory yes, that is what the above URLs claim and what my small compile tests supports.
> > > > > > > In addition, this works for me now:
> > > > > > > => printenv tftpflash
> > > > > > > tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr
> > > > > > > +$filesize &&
> > > > > > > cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr
> > > > > > > $ubootaddr
> > > > > > > $filesize
> > > > > > > 
> > > > > > > 
> > > > > > > => run tftpflash
> > > > > > > Using FM1 at DTSEC1 device
> > > > > > > TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> > > > > > > Filename 'u-boot.bin'.
> > > > > > > Load address: 0x1000000
> > > > > > > Loading: ######################################################
> > > > > > >      7.4 MiB/s
> > > > > > > done
> > > > > > > Bytes transferred = 786432 (c0000 hex)
> > > > > > > ...... done
> > > > > > > Un-Protected 6 sectors
> > > > > > > 
> > > > > > > ...... done
> > > > > > > Erased 6 sectors
> > > > > > > Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> > > > > > > ...... done
> > > > > > > Protected 6 sectors
> > > > > > > Total of 786432 byte(s) were the same
> > > > > > 
> > > > > > OK.  Do you have some of the broken older toolchains as well?  I think
> > > > > > this will at least correct 4.9 and maybe 4.8, but older toolchains don't
> > > > > > have that option (but if there's another option for making older still
> > > > > > toolchains work, we can do that too on the other side of the cc-option).
> > > > > 
> > > > > I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
> > > > > 
> > > > > I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> > > > > claims that bug is not present in gcc 4.7.3
> > > > > 
> > > > > My old gcc 4.5.3 works fine also
> > > > 
> > > > My 4.6.3 has the issue (but it shows up in a different place than with
> > > > my 4.8.3).
> > > 
> > > Then we need a different flag there :(  Does what Joakim found maybe
> > > provide a hint?
> > > 
> > 
> > Different? Does not -fno-ira-hoist-pressure help for all gcc's ?
> > -fno-ira-hoist-pressure is an optimization that u-boot can be without.
> 
> I swear that I tried with my 4.7.2 toolchain (ELDK-5.3) and it didn't
> know about that option.
> 
  Then it could be another bug perhaps? Are you sure the bug is in 4.7.2?
  I read test case as, if *.s has a:

	.section	.data.rel.ro.local,"aw", at progbits
	.align 2
.LC5:
	.4byte	.LC0

Then there must be a fixup too.

 Jocke

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2015-10-21 13:18 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-22 12:39 [U-Boot] Relocation issue - need help! Wolfgang Denk
2014-10-22 13:29 ` Dirk Eibach
2014-10-22 16:56   ` Wolfgang Denk
2014-10-22 17:26     ` Fabio Estevam
2014-10-22 17:28     ` Tom Rini
2014-10-22 17:39       ` Wolfgang Denk
2014-10-22 21:27       ` Pavel Machek
2014-10-22 21:46         ` Marek Vasut
2014-10-22 21:57           ` Pavel Machek
2014-10-22 22:06             ` Marek Vasut
2014-10-23  6:01     ` Dirk Eibach
2014-10-23  6:42       ` Joakim Tjernlund
2014-10-23 13:10         ` Wolfgang Denk
2014-10-23 13:42           ` Dirk Eibach
2014-10-24 14:14           ` Bill Pringlemeir
2015-09-30 18:24           ` Andy Fleming
2015-09-30 19:35             ` Marek Vasut
2015-10-01  8:57               ` Joakim Tjernlund
2015-10-06 11:17                 ` Joakim Tjernlund
2015-10-15 15:56                   ` Joakim Tjernlund
2015-10-15 21:58                     ` Tom Rini
2015-10-16  6:55                       ` Joakim Tjernlund
2015-10-16 11:47                         ` Tom Rini
2015-10-16 13:14                           ` Joakim Tjernlund
2015-10-20 21:06                             ` Andy Fleming
2015-10-20 21:21                               ` Tom Rini
2015-10-21  8:44                                 ` Joakim Tjernlund
2015-10-21 13:12                                   ` Tom Rini
2015-10-21 13:18                                     ` Joakim Tjernlund
2015-10-01 14:18             ` Wolfgang Denk
2015-10-02 22:51               ` Andy Fleming
2015-10-03  8:33                 ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox