[U-Boot] reasons for armv5 as default

[Albert ARIBAUD <albert.aribaud@free.fr>]

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.