[U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Simon Glass]

Hi Stephen,

On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren <swarren at nvidia.com> wrote:
> On 01/05/2012 08:50 AM, Wolfgang Denk wrote:
>> Dear Thierry Reding,
>>
>> In message <1321524246-5187-2-git-send-email-thierry.reding at avionic-design.de> you wrote:
>>> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
>>> the GCC provided libgcc. To work around this, always build and link
>>> against a private libgcc for Tegra2-based boards.
>>
>> I notice this patch only now, when pulling in from u-boot-arm.
>>
>> I will accept this only temporarily.  Why don't you use a working tool
>> chain instead, or fix the one you are using?
>
> I believe the issue isn't that the toolchain is broken, but due to the
> mix of multiple CPU types on Tegra, all of which run the same U-Boot binary.
>
> U-Boot starts execution on the AVP CPU, an ARMv4(?) CPU. U-Boot then
> inits the main CPUs, ARMv7 Cortex A9s, and arranges for them to continue
> running U-Boot.
>
> The libraries included in the toolchain are built for the ARMv7 CPUs,
> and hence fail to operate correctly when used by the portion of U-Boot
> which runs on the ARMv4 CPU, presumably due to ISA differences. IIRC,
> there are overrides in the U-Boot build process such that some/all of
> U-Boot is built so it'll run on ARMv4 OK, which is why using libgcc
> built by U-Boot solves this.

Yes that's right, but actually I have never delved into exactly why.
Perhaps it is an integer divide or internal memcpy() call early in the
code. We might be able to find the offending C library code, given
enough time, and perhaps arrange not to call it. A little fragile
though.

Regards,
Simon

>
> --
> nvpublic