Dear Allen,
In message 3C7A7ACA8617D24290826EC008B5CD08510F030F98@HQMAIL03.nvidia.com you wrote:
So the particular problem that pushed me over the edge on this was trying to apply the ARM thumb patches that Aneesh V posted. As I discovered, it's not the compiler but the linker that inserts the thumb interworking code. As far as I can tell it's not possible to get a linker targeted for armv7 to emit interworking code that works on armv4 regardless of what options are used. I was banging my head on this for a few days so I would love to be proven wrong, but the 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...
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.
during the "make config" step. I really don't like how fragile it is today where we build an armv4 loader from the armv7 directory. Anytime anybody touches start.S or touches compiler options it potentially breaks us. For example the same thumb patches broke tegra even with CONFIG_THUMB turned off because it changed -march to armv7-a. And why wouldn't you want -march=armv7-a for a armv7 build?
I agree that these are issues that should be solved, but using separate tool chains cannot be the right approach.
Best regards,
Wolfgang Denk