[yocto] Building yocto with hard float support

[Mark Hatle]

On 11/12/15 3:17 AM, Toby Gomersall wrote:
> Hi,
> 
> I want to build yocto with hard float support. I understand that I can
> point the EXTERNAL_TOOLCHAIN variable at the appropriate external hard
> float compiler (gcc-5-arm-linux-gnueabihf). However, I was wondering if
> there was anything within the yocto project to do this?

I'm going to be pedantic for a second.. bear with me.

ARM has two ABIs, the standard EABI which passes floating point values via
integer registers and EABIHF that passes floating point values via floating
point registers.

EABI allows hardware floating point along with neon or any other core specific
optimizations.

EABIHF requires a specific set and size of VFP registers.

The Yocto Project is capable of building for both ABIs with whatever
combinations of optimizations you need.

The ABI and default processor optimization is configured by the 'DEFAULTTUNE'
parameter.  This is typically defined in your machine configuration file, either
explicitly or implicitly via the including of the tune files.


So for example, if you have an ARMv5 CPU you would likely use:

DEFAULTTUNE="armv5e"

This would select ARM EABI, no VFP.

alternatively you could do:

DEFAULTTUNE="armv5e-vfp"

This would select ARM EABI w/ VFP floating point.

OR

(what I think you are actually trying to ask)

DEFAULTTUNE="armv5ehf-vfp"

This would select ARM EABIHF w/ VFP floating point.


So start with your machine and determine which defaulttune (bitbake -e) you have
selected.  Adjust it to a compatible setting for the ABI and processor
optimizations that you wish to use.

> I'm concerned that future updates to an external compiler might affect
> my build and I would prefer to use a method from within the yocto project.

Unless you have a specific need, I don't recommend external compilers.  The
Yocto Project compilers and configurations are well tested and high quality.
While using an external compiler is support by some vendors, it adds complexity
that may not be beneficial.  (Sometimes support and other aspects of commercial
offerings outweigh the complexity..)

> Thank you,
> Toby
> 
> 
>