[U-Boot] using different architecture / toolchain for SPL build

[U-Boot] using different architecture / toolchain for SPL build

[Allen Martin]

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

[U-Boot] using different architecture / toolchain for SPL build

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The more we disagree, the more chance there is that at least  one  of
us is right.

[U-Boot] using different architecture / toolchain for SPL build

[Allen Martin]

> > 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

[U-Boot] using different architecture / toolchain for SPL build

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.

[U-Boot] using different architecture / toolchain for SPL build

[Wolfgang Denk]

Dear Allen Martin,

In message <3C7A7ACA8617D24290826EC008B5CD08510F030F9F@HQMAIL03.nvidia.com> you wrote:
>
> > 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.

No, please do not.

Please take it to the binutils mailing list, so it gets solved in
mainline.  It does not help at all if Linaro provides a local fix for
their tools, and for everybody else the issue is still unsolved.

> > 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

But you can define any tye of CONFIG_ settings, both in boards.cfg and
in your board config file.

> 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

What would prevent you from extending the Makefiles to set build
options depending on CONFIG_ settings from your board configuration?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
                  Nail here --X-- for new monitor.

[U-Boot] using different architecture / toolchain for SPL build

[Måns Rullgård]

Allen Martin <AMartin@nvidia.com> writes:

>> > 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.

You should compile with the -mthumb-interwork gcc flag if you need
old-style interworking veneers.

The --use-blx flag only affects PLT calls from Thumb code.  I doubt you
have a PLT in your SPL.

-- 
M?ns Rullg?rd
mans at mansr.com

[U-Boot] using different architecture / toolchain for SPL build

[Allen Martin]

> > 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