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

[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 <raghuveer.murthy@ti.com>
---
 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] [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<raghuveer.murthy@ti.com>

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] [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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Wolfgang Denk]

Dear Raghuveer Murthy,

In message <1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com> 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: wd at denx.de
"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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Måns Rullgård]

Albert ARIBAUD <albert.aribaud@free.fr> 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<raghuveer.murthy@ti.com>
>
> 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
mans at mansr.com

[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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Måns Rullgård]

Alexander Holler <holler@ahsoftware.de> 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
mans at mansr.com

[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] [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] [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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Måns Rullgård]

Albert ARIBAUD <albert.aribaud@free.fr> 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
mans at mansr.com

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

[Alexander Holler]

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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Albert ARIBAUD]

Le 19/02/2011 15:34, M?ns Rullg?rd a ?crit :
> Albert ARIBAUD<albert.aribaud@free.fr>  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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[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] 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] 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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Måns Rullgård]

Albert ARIBAUD <albert.aribaud@free.fr> writes:

> Le 19/02/2011 15:34, M?ns Rullg?rd a ?crit :
>> Albert ARIBAUD<albert.aribaud@free.fr>  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
mans at mansr.com

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

[Wolfgang Denk]

Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=,

In message <yw1x7hcw5f6w.fsf@unicorn.mansr.com> 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: wd at denx.de
Life would be so much easier if we could  just  look  at  the  source
code.                                                   -- Dave Olson

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

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4D5FCACA.1060606@free.fr> 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: wd at denx.de
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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Wolfgang Denk]

Dear Alexander Holler,

In message <4D5FCE64.8030901@ahsoftware.de> 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: wd at denx.de
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] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Wolfgang Denk]

Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=,

In message <yw1xy65c3xfi.fsf@unicorn.mansr.com> you wrote:
> 
> There is one further complication here.  If the compiler was built with
> -mfpu=3Dneon 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.

Right.

May we now just agree that "-msoft-float" is a matter of fact and
mandatory in U-Boot.

Thanks.

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
How many QA engineers does it take to screw in a lightbulb? 3:  1  to
screw it in and 2 to say "I told you so" when it doesn't work.

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

[Wolfgang Denk]

Dear Alexander Holler,

In message <4D5FE485.5030007@ahsoftware.de> you wrote:
> 
> 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).

A Perfect Tool Chain (TM) should provide all the needed libgcc support.
If it fails to do that, then U-Boot provides all the needed library
functions, you just have to use them.

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 day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.

[U-Boot] reasons for armv5 as default

[Wolfgang Denk]

Dear Alexander Holler,

In message <4D5FE8F0.1020607@ahsoftware.de> you wrote:
>
> 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?

Because that's the lowest ARM instruction set version supported widely
across available tool chains.

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

Well, a major reason for not doing this is that "amrv7a" is a typo :-P

Other reasons are for example explained in doc/README.omap3 or
doc/README.s5pc1xx


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
Command, n.:
            Statement presented by a human and accepted by a computer
in such a manner as to make the human feel as if he is in control.

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

[Wolfgang Denk]

Dear Raghuveer Murthy,

In message <1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com> 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:
> 
> 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 <raghuveer.murthy@ti.com>
> ---
>  arch/arm/cpu/armv7/config.mk             |    2 +-
>  arch/arm/cpu/armv7/omap-common/config.mk |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

After we had just another round of these discussions I thing we have
again found an agreement that there are good reasons for using
-msoft-float.

I hereby reject your patch.

If you have problems with your tool chain, please feel free to use
the U-Boot provided libgcc functions instead (by providing
USE_PRIVATE_LIBGCC=yes on the command line) or even your private
libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib
on the command line).

Or fix your tool chain so it provides a soft-float version of the
needed library routines, too.

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
Speculation is always more interesting than facts.
                                    - Terry Pratchett, _Making_Money_

[U-Boot] reasons for armv5 as default

[Alexander Holler]

Hello,

Am 19.02.2011 18:48, schrieb Albert ARIBAUD:

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

Please don't turn the words in my mouth.

Anyway, I now know why -msoft-float is used.

Regards,

Alexander

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

[Raghuveer Murthy]

On Sunday 20 February 2011 01:25 AM, Wolfgang Denk wrote:
> Dear Raghuveer Murthy,
>
> In message<1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com>  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:
>>
>> 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<raghuveer.murthy@ti.com>
>> ---
>>   arch/arm/cpu/armv7/config.mk             |    2 +-
>>   arch/arm/cpu/armv7/omap-common/config.mk |    2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> After we had just another round of these discussions I thing we have
> again found an agreement that there are good reasons for using
> -msoft-float.
>
> I hereby reject your patch.
>
> If you have problems with your tool chain, please feel free to use
> the U-Boot provided libgcc functions instead (by providing
> USE_PRIVATE_LIBGCC=yes on the command line) or even your private
> libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib
> on the command line).
>
> Or fix your tool chain so it provides a soft-float version of the
> needed library routines, too.
>
> Best regards,
>
> Wolfgang Denk
>

Acknowledge the comments. Thanks for you time.

Regards,
Raghuveer