On 01/05/2012 01:42 PM, Simon Glass wrote: > Hi, > > On Thu, Jan 5, 2012 at 12:17 PM, Wolfgang Denk <w...@denx.de> wrote: >> Dear Stephen Warren, >> >> In message <4f05fcbd.2040...@nvidia.com> you wrote: >>> >>>> No, this is NOT a solution, it is a workaround for an inappropriate >>>> toolchain. If you want to build code for an armv4t system, you must >>>> use a tool chain that supports it. >>> >>> But we don't want to generate code for ARMv4 in general, but rather >> >> Then just turn on the ARMv4 specific options (-march=armv4t -mno-thumb >> -mthumb-interwork -mtune=arm920t ???) for the files that need it.
That's exactly what we've already done, but that doesn't affect code that gets pulled in from libgcc, which is what USE_PRIVATE_LIBGCC affects IIUC. >> But as soon as any of these files liks code from libgcc you have to >> decide. > > Perhaps we could adjust Tegra's config.mk to use ARMv4T when not > building with the private libgcc? I believe the relevant U-Boot source files are already built for ARMv4T, it's just libgcc that's the issue. >>> ARMv7 as the toolchain does. Only a tiny part of the code needs to be >>> built for ARMv4, and in general we want to benefit from using ARMv7. >> >> Then you should probably still link against a ARMv4 specific libgcc. >> >> If you were building U-Boot's libgcc code with optimization set for >> ARMv7 this would not fix anything. > > It might be possible to specify ARMv4T on the link flags and have it > pick up the v4T library, even if nearly everything else is ARMv7? I don't think we use any multilib toolchains, so I don't think that's possible. -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot