Quantcast

[U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Raghuveer Murthy
U-boot built for MeeGo on PandaBoard, with compiler option
-mfloat-abi=hard, caused a build break. Please refer to the bug id:

http://bugs.meego.com/show_bug.cgi?id=13140

Removing the -msoft-float options in the config.mk files, allowed it
to be built for both armv7hl and armv7el compilers on MeeGo

Please refer to the below link for more details:
http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal

Signed-off-by: Raghuveer Murthy <[hidden email]>
---
 arch/arm/cpu/armv7/config.mk             |    2 +-
 arch/arm/cpu/armv7/omap-common/config.mk |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 49ac9c7..07f92a8 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -20,7 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8
 
 # Make ARMv5 to allow more compilers to work, even though its v7a.
 PLATFORM_CPPFLAGS += -march=armv5
diff --git a/arch/arm/cpu/armv7/omap-common/config.mk b/arch/arm/cpu/armv7/omap-common/config.mk
index 49ac9c7..07f92a8 100644
--- a/arch/arm/cpu/armv7/omap-common/config.mk
+++ b/arch/arm/cpu/armv7/omap-common/config.mk
@@ -20,7 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
+PLATFORM_RELFLAGS += -fno-common -ffixed-r8
 
 # Make ARMv5 to allow more compilers to work, even though its v7a.
 PLATFORM_CPPFLAGS += -march=armv5
--
1.7.0.4

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Albert ARIBAUD
Le 18/02/2011 16:16, Raghuveer Murthy a écrit :
> U-boot built for MeeGo on PandaBoard, with compiler option
> -mfloat-abi=hard, caused a build break. Please refer to the bug id:
>
> http://bugs.meego.com/show_bug.cgi?id=13140

Is this the official U-Boot? Why is it still at 2010.09 ?

> Removing the -msoft-float options in the config.mk files, allowed it
> to be built for both armv7hl and armv7el compilers on MeeGo
>
> Please refer to the below link for more details:
> http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal
>
> Signed-off-by: Raghuveer Murthy<[hidden email]>

I would like to know which board of mainline U-boot is affected by the
issue and how I can reproduce it on u-boot[-arm]/master.

However, I can already tell that this 'bug' can only occur upon a mix of
object files compiled with -msoft-float and -mhard-float; which means
some files were compiled with -mhard-float; and this should not happen
at all, since U-Boot should not use any floats at all, so:

- either some files in the case reported were compiled voluntarily with
hard-float, and this is not a generally supported use case of U-Boot;

- or they were compiled without any float option and the toolchain
defaulted to hard-float, which may be a meego but is no reason in itself
for U-Boot to adapt to it.

My feeling at the moment is that U-Boot should keep -msoft-float, to be
sure that any float code present in the code base, if it has to be, will
run regardless of hw floating point capabilities, because U-Boot
binaries should make the least possible assumptions on the hardware they
are running on.

Now, CPUs/SoCs/boards that know they have a floating point unit may
justly want to replace -msoft-float with -mhard-float everywhere
throughout U-Boot; I would welcome a patch that allows U-Boot to default
to soft float while allowing CPUs/SoCs/boards to override it for hard float.

In no case, however, should -msoft-float be *removed*: that would make
float support in U-Boot implicit and dependent on the toolchain in use,
and I think U-Boot float support should always be explicit and not
depend on the toolchain.

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Alexander Holler
Hello,

Am 18.02.2011 18:01, schrieb Albert ARIBAUD:

> In no case, however, should -msoft-float be *removed*: that would make
> float support in U-Boot implicit and dependent on the toolchain in use,
> and I think U-Boot float support should always be explicit and not
> depend on the toolchain.

Beeing no friend of cross-compiling I would prefer to use the default of
the toolchain and I don't see any problem with that.

Regards,

Alexander
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Wolfgang Denk
In reply to this post by Raghuveer Murthy
Dear Raghuveer Murthy,

In message <[hidden email]> you wrote:
> U-boot built for MeeGo on PandaBoard, with compiler option
> -mfloat-abi=hard, caused a build break. Please refer to the bug id:

Well, isn't this a typical "Don't do that then!" situation?
(Cf. http://www.jargon.net/jargonfile/d/Dontdothatthen.html)

If this compiler option causes problems (which is IMHO not a surpise at
all), then why are you using it?

None of the U-Boot build rules contain any such option.

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: [hidden email]
"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Måns Rullgård
In reply to this post by Albert ARIBAUD
Albert ARIBAUD <[hidden email]> writes:

> Le 18/02/2011 16:16, Raghuveer Murthy a écrit :
>> U-boot built for MeeGo on PandaBoard, with compiler option
>> -mfloat-abi=hard, caused a build break. Please refer to the bug id:
>>
>> http://bugs.meego.com/show_bug.cgi?id=13140
>
> Is this the official U-Boot? Why is it still at 2010.09 ?
>
>> Removing the -msoft-float options in the config.mk files, allowed it
>> to be built for both armv7hl and armv7el compilers on MeeGo
>>
>> Please refer to the below link for more details:
>> http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal
>>
>> Signed-off-by: Raghuveer Murthy<[hidden email]>
>
> I would like to know which board of mainline U-boot is affected by the
> issue and how I can reproduce it on u-boot[-arm]/master.

I saw this for a while when building for Beagle.  It no longer occurs
with mainline u-boot.  I can't say which commit fixed it.

> However, I can already tell that this 'bug' can only occur upon a mix of
> object files compiled with -msoft-float and -mhard-float; which means
> some files were compiled with -mhard-float; and this should not happen
> at all, since U-Boot should not use any floats at all, so:

The problem was that something from libgcc got pulled in, probably an
integer division or similar.

> - either some files in the case reported were compiled voluntarily with
> hard-float, and this is not a generally supported use case of U-Boot;
>
> - or they were compiled without any float option and the toolchain
> defaulted to hard-float, which may be a meego but is no reason in itself
> for U-Boot to adapt to it.

In my case, it was the latter cause.

> My feeling at the moment is that U-Boot should keep -msoft-float, to be
> sure that any float code present in the code base, if it has to be, will
> run regardless of hw floating point capabilities, because U-Boot
> binaries should make the least possible assumptions on the hardware they
> are running on.
>
> Now, CPUs/SoCs/boards that know they have a floating point unit may
> justly want to replace -msoft-float with -mhard-float everywhere
> throughout U-Boot; I would welcome a patch that allows U-Boot to default
> to soft float while allowing CPUs/SoCs/boards to override it for hard float.
>
> In no case, however, should -msoft-float be *removed*: that would make
> float support in U-Boot implicit and dependent on the toolchain in use,
> and I think U-Boot float support should always be explicit and not
> depend on the toolchain.

There is no reason for supporting hardware floating-point in u-boot.  If
floating-point is used at all, and I can't think of a place where it is,
it is not relevant to performance.  The added complexity of supporting a
hardware FPU is not worth it, in my opinion.

--
Måns Rullgård
[hidden email]

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Alexander Holler
Hello,

Am 19.02.2011 12:19, schrieb Måns Rullgård:

>> In no case, however, should -msoft-float be *removed*: that would make
>> float support in U-Boot implicit and dependent on the toolchain in use,
>> and I think U-Boot float support should always be explicit and not
>> depend on the toolchain.
>
> There is no reason for supporting hardware floating-point in u-boot.  If
> floating-point is used at all, and I can't think of a place where it is,
> it is not relevant to performance.  The added complexity of supporting a
> hardware FPU is not worth it, in my opinion.

I still don't understand this discussion. Floats aren't used in u-boot,
so why should it make a difference if -msoft-float will be removed? I
know there was one bug which linked in something wrong from glibc, but
if that flag isn't needed than it shouldn't make a difference at all if
-msoft-float or -mhard-float is used.

So whats the reasoning to use -msoft-float as it is currently done? To
confuse people? ;)

Regards,

Alexander

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Måns Rullgård
Alexander Holler <[hidden email]> writes:

> Hello,
>
> Am 19.02.2011 12:19, schrieb Måns Rullgård:
>
>>> In no case, however, should -msoft-float be *removed*: that would make
>>> float support in U-Boot implicit and dependent on the toolchain in use,
>>> and I think U-Boot float support should always be explicit and not
>>> depend on the toolchain.
>>
>> There is no reason for supporting hardware floating-point in u-boot.  If
>> floating-point is used at all, and I can't think of a place where it is,
>> it is not relevant to performance.  The added complexity of supporting a
>> hardware FPU is not worth it, in my opinion.
>
> I still don't understand this discussion. Floats aren't used in u-boot,
> so why should it make a difference if -msoft-float will be removed? I
> know there was one bug which linked in something wrong from glibc, but
> if that flag isn't needed than it shouldn't make a difference at all if
> -msoft-float or -mhard-float is used.

The linker refuses to combine objects with different calling
conventions, and those tags are set based only on compiler flags, not
what code the file actually contains.

Some version of u-boot with some versions of gcc erroneously pull in
something from libgcc, which will fail if libgcc and u-boot used
different ABI flags.

The real error here is that of linking in libgcc in the first place, not
the ABI flags.

> So whats the reasoning to use -msoft-float as it is currently done? To
> confuse people? ;)

I guess it's there to make sure no floating-point instructions make it
into u-boot, even though floats are not used in the code.  Perhaps
someone was paranoid.

--
Måns Rullgård
[hidden email]

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Albert ARIBAUD
Le 19/02/2011 14:25, Måns Rullgård a écrit :

>> So whats the reasoning to use -msoft-float as it is currently done? To
>> confuse people? ;)
>
> I guess it's there to make sure no floating-point instructions make it
> into u-boot, even though floats are not used in the code.  Perhaps
> someone was paranoid.

I think also that there is no choice but to have a float option for ARM
C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
the 'soft' calling conventions), because the C compiler does not allow
'no floats', and anyway the C language *requires* to have some sort of
float support.

Actually if you don't specify any float option, the C toolchain will
choose one, which is just the same in the end: *some* float option is
chosen.

And since some option must be chosen, I prefer that U-Boot make the
explicit decision, and choose soft float for the reasons I already exposed.

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Alexander Holler
Am 19.02.2011 14:51, schrieb Albert ARIBAUD:

> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>
>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>> confuse people? ;)
>>
>> I guess it's there to make sure no floating-point instructions make it
>> into u-boot, even though floats are not used in the code.  Perhaps
>> someone was paranoid.
>
> I think also that there is no choice but to have a float option for ARM
> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
> the 'soft' calling conventions), because the C compiler does not allow
> 'no floats', and anyway the C language *requires* to have some sort of
> float support.

As it is on every platform.

> Actually if you don't specify any float option, the C toolchain will
> choose one, which is just the same in the end: *some* float option is
> chosen.

Every compiler has dozens of options which are set to a default value.

> And since some option must be chosen, I prefer that U-Boot make the
> explicit decision, and choose soft float for the reasons I already exposed.

I don't see any reason to explicitly set an option for something which
isn't used, but I know of many reasons to avoid such. ;)

Regards,

Alexander

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Albert ARIBAUD
Le 19/02/2011 15:06, Alexander Holler a écrit :

> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>
>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>> confuse people? ;)
>>>
>>> I guess it's there to make sure no floating-point instructions make it
>>> into u-boot, even though floats are not used in the code. Perhaps
>>> someone was paranoid.
>>
>> I think also that there is no choice but to have a float option for ARM
>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>> the 'soft' calling conventions), because the C compiler does not allow
>> 'no floats', and anyway the C language *requires* to have some sort of
>> float support.
>
> As it is on every platform.

Indeed.

>> Actually if you don't specify any float option, the C toolchain will
>> choose one, which is just the same in the end: *some* float option is
>> chosen.
>
> Every compiler has dozens of options which are set to a default value.

Granted. But not all of them relate to hardware which may or may not be
available.

>> And since some option must be chosen, I prefer that U-Boot make the
>> explicit decision, and choose soft float for the reasons I already
>> exposed.
>
> I don't see any reason to explicitly set an option for something which
> isn't used, but I know of many reasons to avoid such. ;)

At least there is one reason for having -msoft-float even though no
floating point should be used in U-Boot : it helps catching cases where
some code in U-Boot tries to use hard float. :)

Think of it as choosing the least dangerous of Charybdis and Scylla,
while trying our best not to get near any of the two.

> Regards,
>
> Alexander

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Måns Rullgård
Albert ARIBAUD <[hidden email]> writes:

> Le 19/02/2011 15:06, Alexander Holler a écrit :
>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>>
>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>> confuse people? ;)
>>>>
>>>> I guess it's there to make sure no floating-point instructions make it
>>>> into u-boot, even though floats are not used in the code. Perhaps
>>>> someone was paranoid.
>>>
>>> I think also that there is no choice but to have a float option for ARM
>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>>> the 'soft' calling conventions), because the C compiler does not allow
>>> 'no floats', and anyway the C language *requires* to have some sort of
>>> float support.
>>
>> As it is on every platform.
>
> Indeed.
>
>>> Actually if you don't specify any float option, the C toolchain will
>>> choose one, which is just the same in the end: *some* float option is
>>> chosen.
>>
>> Every compiler has dozens of options which are set to a default value.
>
> Granted. But not all of them relate to hardware which may or may not be
> available.
>
>>> And since some option must be chosen, I prefer that U-Boot make the
>>> explicit decision, and choose soft float for the reasons I already
>>> exposed.
>>
>> I don't see any reason to explicitly set an option for something which
>> isn't used, but I know of many reasons to avoid such. ;)
>
> At least there is one reason for having -msoft-float even though no
> floating point should be used in U-Boot : it helps catching cases where
> some code in U-Boot tries to use hard float. :)

There is one further complication here.  If the compiler was built with
-mfpu=neon as default, it might emit neon instructions for pure integer
code.  For the purpose of this discussion, such instructions should
still be regarded as floating-point since they are tied to the VFP.
Such code generation is disabled by -msoft-float.

--
Måns Rullgård
[hidden email]

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Alexander Holler
In reply to this post by Albert ARIBAUD
Am 19.02.2011 15:27, schrieb Albert ARIBAUD:
> Le 19/02/2011 15:06, Alexander Holler a écrit :
>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>>
>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>> confuse people? ;)

>> I don't see any reason to explicitly set an option for something which
>> isn't used, but I know of many reasons to avoid such. ;)
>
> At least there is one reason for having -msoft-float even though no
> floating point should be used in U-Boot : it helps catching cases where
> some code in U-Boot tries to use hard float. :)
>
> Think of it as choosing the least dangerous of Charybdis and Scylla,
> while trying our best not to get near any of the two.

Hmm, I could argue exactly the oposite.
When using -msoft-float you won't find (unwanted) usages of float on any
platform. To follow your argument, hard-floats should be enabled (if
possible), so the usage of floats would lead to an error (at least on
platforms without support for that). ;)

Regards,

Alexander

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Albert ARIBAUD
In reply to this post by Måns Rullgård
Le 19/02/2011 15:34, Måns Rullgård a écrit :

> Albert ARIBAUD<[hidden email]>  writes:
>
>> Le 19/02/2011 15:06, Alexander Holler a écrit :
>>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>>>
>>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>>> confuse people? ;)
>>>>>
>>>>> I guess it's there to make sure no floating-point instructions make it
>>>>> into u-boot, even though floats are not used in the code. Perhaps
>>>>> someone was paranoid.
>>>>
>>>> I think also that there is no choice but to have a float option for ARM
>>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>>>> the 'soft' calling conventions), because the C compiler does not allow
>>>> 'no floats', and anyway the C language *requires* to have some sort of
>>>> float support.
>>>
>>> As it is on every platform.
>>
>> Indeed.
>>
>>>> Actually if you don't specify any float option, the C toolchain will
>>>> choose one, which is just the same in the end: *some* float option is
>>>> chosen.
>>>
>>> Every compiler has dozens of options which are set to a default value.
>>
>> Granted. But not all of them relate to hardware which may or may not be
>> available.
>>
>>>> And since some option must be chosen, I prefer that U-Boot make the
>>>> explicit decision, and choose soft float for the reasons I already
>>>> exposed.
>>>
>>> I don't see any reason to explicitly set an option for something which
>>> isn't used, but I know of many reasons to avoid such. ;)
>>
>> At least there is one reason for having -msoft-float even though no
>> floating point should be used in U-Boot : it helps catching cases where
>> some code in U-Boot tries to use hard float. :)
>
> There is one further complication here.  If the compiler was built with
> -mfpu=neon as default, it might emit neon instructions for pure integer
> code.  For the purpose of this discussion, such instructions should
> still be regarded as floating-point since they are tied to the VFP.
> Such code generation is disabled by -msoft-float.

Thanks for indicating this. If I paraphrase this correctly, some
toochains would generate floating instructions for integer if both
-mfloat-abi=hard and -fmpu=neon were specified or were the default.

I don't see this as a worrying matter though, because I suspect that
toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and
target cpus that have hw floating point capabilities, where such float
instructions would cause no problem.

And it is not as if the C code used floats.

Besides, so far I have seen no complaint that -msoft-float disabling
-mfpu=neon causes any problem with U-Boot, so I suspect no board
requires it now.

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Alexander Holler
In reply to this post by Alexander Holler
Hello,

Am 19.02.2011 16:32, schrieb Albert ARIBAUD:

> Granted :) -- the best option would be to have "-float-abi=none", but
> that does not exist, and I prefer to be sure that if some poor soul puts
> floating point code in U-Boot then at least it is going to work for all
> platforms, so I'll keep -msoft-float in here.

Hmm, but as we've seen, that doesn't work for all platforms because you
can't mix softfloat and hardfloat. So using softfloat breaks building on
(default-) hardfloat platforms if some poor soul puts floating point
code in (which requires hardfloat-libraries too).

So I still think going with the default option would be the right way to
go. ;)

Regards,

Alexander
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[U-Boot] reasons for armv5 as default

Alexander Holler
Am 19.02.2011 16:40, schrieb Alexander Holler:

> Hello,
>
> Am 19.02.2011 16:32, schrieb Albert ARIBAUD:
>
>> Granted :) -- the best option would be to have "-float-abi=none", but
>> that does not exist, and I prefer to be sure that if some poor soul puts
>> floating point code in U-Boot then at least it is going to work for all
>> platforms, so I'll keep -msoft-float in here.
>
> Hmm, but as we've seen, that doesn't work for all platforms because you
> can't mix softfloat and hardfloat. So using softfloat breaks building on
> (default-) hardfloat platforms if some poor soul puts floating point
> code in (which requires hardfloat-libraries too).
>
> So I still think going with the default option would be the right way to
> go. ;)


Btw, while we are there, is there any reason, besides being carefull,
why u-boot for arm is compiled with -march=armv5(te) by default?

I'm just curious if there are some reasons for not using march=amrv7a
for armv7 platforms and don't want to start a discussion about removing
that default.

I've seen some comments about armv5, e.g. in
arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to
understand them.

Regards,

Alexander
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] reasons for armv5 as default

Albert ARIBAUD
Le 19/02/2011 16:59, Alexander Holler a écrit :

> Am 19.02.2011 16:40, schrieb Alexander Holler:
>> Hello,
>>
>> Am 19.02.2011 16:32, schrieb Albert ARIBAUD:
>>
>>> Granted :) -- the best option would be to have "-float-abi=none", but
>>> that does not exist, and I prefer to be sure that if some poor soul puts
>>> floating point code in U-Boot then at least it is going to work for all
>>> platforms, so I'll keep -msoft-float in here.
>>
>> Hmm, but as we've seen, that doesn't work for all platforms because you
>> can't mix softfloat and hardfloat. So using softfloat breaks building on
>> (default-) hardfloat platforms if some poor soul puts floating point
>> code in (which requires hardfloat-libraries too).

You're missing the fact that floating point code is a no-no in U-Boot.
We're not talking about the best option to support floating-point code
in U-Boot, but the best option to catch the use of floating point.

However, as I've said, I would be fine with someone submitting a patch
that makes -mfloat-abi=xxx and -mfpu=yyy available as configuration
options so that a board maintainer who feels the irresistible urge to
have hard float support can have it *for performance improvement only*
(as in the case Måns described about integer code being performed with
float instructions), not for explicit use of floats or doubles in the code.

Note that with such a scheme, a board (or SoC, or [vendor-specific] cpu)
maintainer could even override the float default and decide to leave it
blank so that the toolchain default is used, if they so want.

The only things that won't be an option if such a patch is submitted are
that i) the default config setting for float must be soft-float, and ii)
a doc/README.arm-float must be added to reflect how the option works and
what the risks are of soft and hard float, and that

>> So I still think going with the default option would be the right way to
>> go. ;)
>
>
> Btw, while we are there, is there any reason, besides being carefull,
> why u-boot for arm is compiled with -march=armv5(te) by default?
>
> I'm just curious if there are some reasons for not using march=amrv7a
> for armv7 platforms and don't want to start a discussion about removing
> that default.
>
> I've seen some comments about armv5, e.g. in
> arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to
> understand them.

IIRC the conclusion was that U-Boot does not need armv7 specific
instructions and besides, not all toolchains frequently used with U-Boot
have v7 support -- especially the toolchain coming with ELDK 4.2.

> Regards,
>
> Alexander

Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Måns Rullgård
In reply to this post by Albert ARIBAUD
Albert ARIBAUD <[hidden email]> writes:

> Le 19/02/2011 15:34, Måns Rullgård a écrit :
>> Albert ARIBAUD<[hidden email]>  writes:
>>
>>> Le 19/02/2011 15:06, Alexander Holler a écrit :
>>>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>>>> Le 19/02/2011 14:25, Måns Rullgård a écrit :
>>>>>
>>>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>>>> confuse people? ;)
>>>>>>
>>>>>> I guess it's there to make sure no floating-point instructions make it
>>>>>> into u-boot, even though floats are not used in the code. Perhaps
>>>>>> someone was paranoid.
>>>>>
>>>>> I think also that there is no choice but to have a float option for ARM
>>>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>>>>> the 'soft' calling conventions), because the C compiler does not allow
>>>>> 'no floats', and anyway the C language *requires* to have some sort of
>>>>> float support.
>>>>
>>>> As it is on every platform.
>>>
>>> Indeed.
>>>
>>>>> Actually if you don't specify any float option, the C toolchain will
>>>>> choose one, which is just the same in the end: *some* float option is
>>>>> chosen.
>>>>
>>>> Every compiler has dozens of options which are set to a default value.
>>>
>>> Granted. But not all of them relate to hardware which may or may not be
>>> available.
>>>
>>>>> And since some option must be chosen, I prefer that U-Boot make the
>>>>> explicit decision, and choose soft float for the reasons I already
>>>>> exposed.
>>>>
>>>> I don't see any reason to explicitly set an option for something which
>>>> isn't used, but I know of many reasons to avoid such. ;)
>>>
>>> At least there is one reason for having -msoft-float even though no
>>> floating point should be used in U-Boot : it helps catching cases where
>>> some code in U-Boot tries to use hard float. :)
>>
>> There is one further complication here.  If the compiler was built with
>> -mfpu=neon as default, it might emit neon instructions for pure integer
>> code.  For the purpose of this discussion, such instructions should
>> still be regarded as floating-point since they are tied to the VFP.
>> Such code generation is disabled by -msoft-float.
>
> Thanks for indicating this. If I paraphrase this correctly, some
> toochains would generate floating instructions for integer if both
> -mfloat-abi=hard and -fmpu=neon were specified or were the default.

-mfloat-abi of hard or softfp both allow neon instruction to be emitted.

> I don't see this as a worrying matter though, because I suspect that
> toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and
> target cpus that have hw floating point capabilities, where such float
> instructions would cause no problem.

The issue is not one of hardware availability.  Using the VFP/NEON unit
at all requires additional support beyond simply using the instructions.

Firstly, the coprocessor must be enabled, which although a trivial
operation does add complexity and maintenance burden.

Secondly, any code run in an interrupt context must be somehow arranged
to be free of VFP/NEON code, or the VFP context must be saved and
restored around interrupt handlers.  The latter is a bad idea since it
significantly slows interrupt handling.  This leaves us with the former
option, and if some code must be VFP-free, that requirement might as
well be extended to all code with no additional burden.

The simplest way to make sure no VFP or NEON instructions are used is to
pass -msoft-float to the compiler.  Since linking to libgcc is an error
in u-boot, ABI compatibility with it is of no concern.

To summarise, I think using -msoft-float is good.  Supporting
floating-point in u-boot is more trouble than it's worth, and
-msoft-float is an easy way to make sure the code is clean.

--
Måns Rullgård
[hidden email]

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Wolfgang Denk
In reply to this post by Måns Rullgård
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=,

In message <[hidden email]> you wrote:
>
> > So whats the reasoning to use -msoft-float as it is currently done? To
> > confuse people? ;)
>
> I guess it's there to make sure no floating-point instructions make it
> into u-boot, even though floats are not used in the code.  Perhaps
> someone was paranoid.

No.  There are pretty good reasons to use -msoft-float.  On some
systems certain versions of GCC will optimize certain operations
(usually corresponding to 8 byte memory copy things) by using FP
registers.

-msoft-float prevents that.

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: [hidden email]
Life would be so much easier if we could  just  look  at  the  source
code.                                                   -- Dave Olson
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Wolfgang Denk
In reply to this post by Albert ARIBAUD
Dear Albert ARIBAUD,

In message <[hidden email]> you wrote:
>
> And since some option must be chosen, I prefer that U-Boot make the
> explicit decision, and choose soft float for the reasons I already exposed.

I explained this several times before.  There are good reasons to have
-msoft-float.


If the tool chain has problems by not providing soft-float libgcc
routines, the user can always use the U-Boot provided library
functions.

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: [hidden email]
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

Wolfgang Denk
In reply to this post by Alexander Holler
Dear Alexander Holler,

In message <[hidden email]> you wrote:
>
> I don't see any reason to explicitly set an option for something which
> isn't used, but I know of many reasons to avoid such. ;)

Read my previous messages, and/or the archives. There _are_ good
reasons that -msoft-float is used.

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: [hidden email]
NOTE: The  Most  Fundamental  Particles  in  This  Product  Are  Held
Together  by  a  "Gluing" Force About Which Little is Currently Known
and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
12
Loading...