Hi Stephen, On Thu, Jan 5, 2012 at 8:53 AM, Stephen Warren <swar...@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.red...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot