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 <w...@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: w...@denx.de > Old programmers never die, they just branch to a new address. > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
