[U-Boot] [PATCH 14/26 v2][NEXT] ARM: implement relocation for ARM V7 (OMAP)
John Rigby
jcrigby at gmail.com
Sun Sep 19 03:21:45 CEST 2010
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.
Thanks,
John
More information about the U-Boot
mailing list