[U-Boot] using different architecture / toolchain for SPL build
I'm trying to solve a problem we've had in the tegra build of u-boot for a while. Tegra2/3 have an integrated arm7tdmi in addition to the cortex A9. Initial boot of the system is always to the arm7tdmi which is responsible for turning on the clocks and power rails for the A9 and then taking it out of reset.
The tegra build of u-boot currently is a single image that executes on both the arm7tdmi and cortex A9, but it's quite fragile because we use a armv7 toolchain and have be careful about compiler options and ifdefing around inline assembly so it still boots on the arm7tdmi.
I'm looking at using an SPL build of u-boot that executes only on the arm7tdmi and initializes the bare minimum to bring up the A9 and transfer control to it. However all the SPL examples I'm looking at assume the same toolchain and architecture for the SPL and normal u-boot build.
How would others feel about a CROSS_COMPILE_SPL variable that allowed one to override the toolchain used during the SPL build?
The architecture seems harder to fix. It seems like I really have to have two entries in boards.cfg, which means two passes of config/make.
nvpublic
Dear Allen,
In message 3C7A7ACA8617D24290826EC008B5CD08510F030F95@HQMAIL03.nvidia.com you wrote:
The tegra build of u-boot currently is a single image that executes on both the arm7tdmi and cortex A9, but it's quite fragile because we use a armv7 toolchain and have be careful about compiler options and ifdefing around inline assembly so it still boots on the arm7tdmi.
I'm looking at using an SPL build of u-boot that executes only on the arm7tdmi and initializes the bare minimum to bring up the A9 and transfer control to it. However all the SPL examples I'm looking at assume the same toolchain and architecture for the SPL and normal u-boot build.
I think you make an important mistake here: please so not mix up "tool chain" on one side and "build options" on the other side.
How would others feel about a CROSS_COMPILE_SPL variable that allowed one to override the toolchain used during the SPL build?
This makes no sense to me. The need to use a specific tool chain for some SoC type usuallyonly comes into play when dealing with user space code, i. e. when you have to make sure that you also use libraries that were built with appropriate options. U-Boot however is pretty much self-contained - if you are careful (see USE_PRIVATE_LIBGCC) we do not even depend on the compiler-provided libraries.
All you should have to do is making sure the build is done using appropriate build options. I can see no reason why different tool chains would be needed (not to mention that such an approch would be a maintainance nightmare for all involved parties).
The architecture seems harder to fix. It seems like I really have to have two entries in boards.cfg, which means two passes of config/make.
This should be not needed; I also do not think this would be an acceptable approach.
Best regards,
Wolfgang Denk
How would others feel about a CROSS_COMPILE_SPL variable that allowed one to override the toolchain used during the SPL build?
This makes no sense to me. The need to use a specific tool chain for some SoC type usuallyonly comes into play when dealing with user space code, i. e. when you have to make sure that you also use libraries that were built with appropriate options. U-Boot however is pretty much self-contained - if you are careful (see USE_PRIVATE_LIBGCC) we do not even depend on the compiler-provided libraries.
All you should have to do is making sure the build is done using appropriate build options. I can see no reason why different tool chains would be needed (not to mention that such an approch would be a maintainance nightmare for all involved parties).
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.
The architecture seems harder to fix. It seems like I really have to have two entries in boards.cfg, which means two passes of config/make.
This should be not needed; I also do not think this would be an acceptable approach.
How is it possible then to build an SPL that builds from a different arch subdirectory? It seems like the arch subdirectory is decided 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?
-Allen
nvpublic
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
participants (2)
-
Allen Martin -
Wolfgang Denk