[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