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

Heiko Schocher
2010-09-19T06:07:28Z

Hello John,

John Rigby wrote:
> Dear Wolfgang,
>
> Thanks for the feedback.
>
> On Fri, Sep 17, 2010 at 4:02 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear John,
>>
>> In message <AANLkTims+909jaF1Ho41+WAZbH1qmoNDG8AOhpM04j8F@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