> > only option I found that worked was to use an armv4 toolchain for > the > > armv4 bits and armv7 toolchain for the armv7 bits. > > I'm not an expert in this area, but this cannot be the right > approach. > Did you try asking on the binutils mailing list? This is where > experts should be available...
I drilled down on this some more and I found that with an armv4t linker I can force it to generate armv7 compatible interworking code if I use the "--use-bx" switch. Unfortunately there doesn't seem to be any inverse, so with a armv7 linker I can't force it to generate armv4t compatible interworking. This does seem to be a linker limitation, I'll take it up on the linaro toolchain list. > > > How is it possible then to build an SPL that builds from a > different > > arch subdirectory? It seems like the arch subdirectory is decided > > We are not talking about a different architecture here - like a > PowerPC SPL that boots an ARM U-Boot. We are still in a single > architecture, it's just different CPU models. And when both GCC and > the assembler are capable of being tuned to the respective CPU > model, > this should also be possible for the linker. The problem I'm having with the SPL build is that a single entry in boards.cfg can have exactly one architecture and CPU model. So there's no easy way to have the SPL build compile from arm720t and the non SPL build compile from armv7. So I either have to have two board entries or what we have today which is a very fragile armv4t build out of the armv7 directory. I'd really like to solve this since we could definitely clean up the tegra code a bit if we could remove the armv4t bits from the armv7 directory and we could also remove the dependency on USE_PRIVATE_LIBGCC for the tegra build. -Allen nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
