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

[Måns Rullgård]

Albert ARIBAUD <albert.aribaud at 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 at 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