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

[Tom Warren]

Simon,

> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Thursday, January 05, 2012 10:07 AM
> To: Stephen Warren
> Cc: Wolfgang Denk; Thierry Reding; u-boot at lists.denx.de; Tom Warren
> Subject: Re: [U-Boot] [PATCH 1/2] tegra2: Always build with
> USE_PRIVATE_LIBGCC=yes.
> 
> 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.

IIRC, it was a divide that caused an undefined instruction exception. You can run U-Boot w/o the UE_PRIVATE_LIBGCC, and break in w/JTAG and look at the undefined instr shadow regs (sp/lr/pc) and find the opcode that caused the fault pretty easily, again IIRC.  But USE_PRIVATE_LIBGCC was intended for just this problem, and works fine.

Tom
> 
> Regards,
> Simon
> 
> >
> > --
> > nvpublic