[U-Boot] [PATCH 14/26 v2][NEXT] ARM: implement relocation for ARM V7 (OMAP)

[Heiko Schocher]

Hello John,

John Rigby wrote:
> Dear Wolfgang,
> 
> Thanks for the feedback.
> 
> On Fri, Sep 17, 2010 at 4:02 PM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear John,
>>
>> In message <AANLkTims+909jaF1Ho41+WAZbH1qmoNDG8AOhpM04j8F at mail.gmail.com> you wrote:
>>> I noticed that when I wrote to ram in the range where u-boot runs
>>> before being relocated sometimes the board hangs.  I then narrowed it
>> Stupid question: how did you write to that RAM location? And why?
>>
>> The RAM is not supposed to be accessable before relocation...
> 
> I worded this poorly.  I write to memory using mw at the u-boot
> command line.  I write to the region where u-boot was running prior to
> relocation:
> 
> OMAP3 beagleboard.org # mw.b 80000000 ff 1000000
> 
>>> down to being able to reproduce the hang by writing to a single byte.
>>> Turns out that __aeabi_uidiv gets called in its original location
>>> after relocation.  I believe the culprit is ____aeabi_uidiv_veneer.
>> Where is this coming from? I cannot see this symbol anywhere in U-Boot
>> code...
>>
>> Which tool chain are you using?
> 
> I'm using a prerelease Ubuntu/Linaro gcc 4.4.4.
> 
>>> Looks like these *veneer routines need to be relocated.
>> Hm... where are they coming from in the first place?
>>
>>
>> Can you please try building with (1) a different tool chain and/or
>> (2) with USE_PRIVATE_LIBGCC=yes on the command line?  Does this change
>> anything?
> 
> With USE_PRIVATE_LIBGCC=yes these veneer* routines go away and the
> problem is gone.

Maybe, you can document this in doc/README.arm-relocation, in
a problem/solution chapter?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany