diff mbox

arch/arm: use EABIhf by default with VFP

Message ID 1445786380-2741-1-git-send-email-benoit.thebaudeau.dev@gmail.com
State Accepted
Commit cc0773f2a89f30b252532e771cf4ffa513f57f2d
Headers show

Commit Message

Benoît Thébaudeau Oct. 25, 2015, 3:19 p.m. UTC
Set EABIhf as the default target ABI for the ARM processors that have or
may have a VFP unit, since this ABI is the most efficient in that case.
Of course, EABI can still be selected manually if needed.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
---
 arch/Config.in.arm | 1 +
 1 file changed, 1 insertion(+)

Comments

Peter Korsgaard Oct. 25, 2015, 6:53 p.m. UTC | #1
>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:

 > Set EABIhf as the default target ABI for the ARM processors that have or
 > may have a VFP unit, since this ABI is the most efficient in that case.
 > Of course, EABI can still be selected manually if needed.

 > Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
 > ---
 >  arch/Config.in.arm | 1 +
 >  1 file changed, 1 insertion(+)

 > diff --git a/arch/Config.in.arm b/arch/Config.in.arm
 > index 4d10f4c..f0110b1 100644
 > --- a/arch/Config.in.arm
 > +++ b/arch/Config.in.arm
 > @@ -188,6 +188,7 @@ endchoice
 >  choice
 >  	prompt "Target ABI"
 >  	depends on BR2_arm || BR2_armeb
 > +	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

I think we should only do it when we are certain it will run,
E.G. arm926 (our default variant) selects MAYBE_HAS_VFPV2, but it is
afaik quite rare to see arm9s with a vfp.

Committed with that changed, thanks.
Peter Korsgaard Oct. 25, 2015, 6:55 p.m. UTC | #2
>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:

 > Set EABIhf as the default target ABI for the ARM processors that have or
 > may have a VFP unit, since this ABI is the most efficient in that case.
 > Of course, EABI can still be selected manually if needed.

On a related note, should we default to thumb2 if the CPU supports it?
Benoît Thébaudeau Oct. 25, 2015, 8:27 p.m. UTC | #3
On Sun, Oct 25, 2015 at 7:55 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
>
>  > Set EABIhf as the default target ABI for the ARM processors that have or
>  > may have a VFP unit, since this ABI is the most efficient in that case.
>  > Of course, EABI can still be selected manually if needed.
>
> On a related note, should we default to thumb2 if the CPU supports it?

I would say:

    choice
           prompt "ARM instruction set"
           default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM
           default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
           default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS

Best regards,
Benoît
Peter Korsgaard Oct. 25, 2015, 8:40 p.m. UTC | #4
>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:

 > On Sun, Oct 25, 2015 at 7:55 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
 >>>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
 >> 
 >> > Set EABIhf as the default target ABI for the ARM processors that have or
 >> > may have a VFP unit, since this ABI is the most efficient in that case.
 >> > Of course, EABI can still be selected manually if needed.
 >> 
 >> On a related note, should we default to thumb2 if the CPU supports it?

 > I would say:

 >     choice
 >            prompt "ARM instruction set"
 >            default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM
 >            default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
 >            default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS

I'm not sure it makes sense to default to thumb1 even if the CPU
supports it because of various compatibility issues - So simply:

default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2

(if no thumb2 is available, the first available option (ARM) is used).
Benoît Thébaudeau Oct. 25, 2015, 8:52 p.m. UTC | #5
On Sun, Oct 25, 2015 at 9:40 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
>
>  > On Sun, Oct 25, 2015 at 7:55 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>  >>>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
>  >>
>  >> > Set EABIhf as the default target ABI for the ARM processors that have or
>  >> > may have a VFP unit, since this ABI is the most efficient in that case.
>  >> > Of course, EABI can still be selected manually if needed.
>  >>
>  >> On a related note, should we default to thumb2 if the CPU supports it?
>
>  > I would say:
>
>  >     choice
>  >            prompt "ARM instruction set"
>  >            default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM
>  >            default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
>  >            default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS
>
> I'm not sure it makes sense to default to thumb1 even if the CPU
> supports it because of various compatibility issues

It's the first default that wins, not the last one, so above it's ARM
over Thumb1.

> - So simply:
>
> default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
>
> (if no thumb2 is available, the first available option (ARM) is used).

With ARM + Thumb2, I would rather use ARM to avoid compatibility
issues, except on platforms very constrained on memory. On Cortex-M3,
there's not even ARM. Or is it common to use Thumb2 on bigger
platforms like Cortex-A*?

Best regards,
Benoît
Yann E. MORIN Oct. 25, 2015, 9:30 p.m. UTC | #6
Benoît, Peter, All,

On 2015-10-25 21:52 +0100, Benoît Thébaudeau spake thusly:
> On Sun, Oct 25, 2015 at 9:40 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
> >>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
> >
> >  > On Sun, Oct 25, 2015 at 7:55 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
> >  >>>>>>> "Benoît" == Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> writes:
> >  >>
> >  >> > Set EABIhf as the default target ABI for the ARM processors that have or
> >  >> > may have a VFP unit, since this ABI is the most efficient in that case.
> >  >> > Of course, EABI can still be selected manually if needed.
> >  >>
> >  >> On a related note, should we default to thumb2 if the CPU supports it?
> >
> >  > I would say:
> >
> >  >     choice
> >  >            prompt "ARM instruction set"
> >  >            default BR2_ARM_INSTRUCTIONS_ARM if BR2_ARM_CPU_HAS_ARM
> >  >            default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
> >  >            default BR2_ARM_INSTRUCTIONS_THUMBS if BR2_ARM_CPU_HAS_THUMBS
> >
> > I'm not sure it makes sense to default to thumb1 even if the CPU
> > supports it because of various compatibility issues
> 
> It's the first default that wins, not the last one,

To be more precise: it's the first default which dependencies are
fullfiled that wins.

> so above it's ARM over Thumb1.

> > - So simply:
> >
> > default BR2_ARM_INSTRUCTIONS_THUMBS2 if BR2_ARM_CPU_HAS_THUMBS2
> >
> > (if no thumb2 is available, the first available option (ARM) is used).
> 
> With ARM + Thumb2, I would rather use ARM to avoid compatibility
> issues, except on platforms very constrained on memory. On Cortex-M3,
> there's not even ARM. Or is it common to use Thumb2 on bigger
> platforms like Cortex-A*?

I agree that we should default to ARM if available. If not, then default
to Thumb2 if available. Finally, fallback to Thumb1.

We know that if neither ARM not Thumb2 is available, then we must have
Thumb1 available. otherwise it would not make sense to have an ARM CPU
that does not support any of those three.

So, slight ammendment to Benoît's proposal:

    choice
        prompt "ARM instruction set"
        default BR2_ARM_INSTRUCTIONS_ARM    if BR2_ARM_CPU_HAS_ARM
        default BR2_ARM_INSTRUCTIONS_THUMB2 if BR2_ARM_CPU_HAS_THUMB2
        default BR2_ARM_INSTRUCTIONS_THUMB

Regards,
Yann E. MORIN.
Thomas Petazzoni Oct. 26, 2015, 12:32 a.m. UTC | #7
Dear Peter Korsgaard,

On Sun, 25 Oct 2015 19:53:06 +0100, Peter Korsgaard wrote:

>  > diff --git a/arch/Config.in.arm b/arch/Config.in.arm
>  > index 4d10f4c..f0110b1 100644
>  > --- a/arch/Config.in.arm
>  > +++ b/arch/Config.in.arm
>  > @@ -188,6 +188,7 @@ endchoice
>  >  choice
>  >  	prompt "Target ABI"
>  >  	depends on BR2_arm || BR2_armeb
>  > +	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2
> 
> I think we should only do it when we are certain it will run,
> E.G. arm926 (our default variant) selects MAYBE_HAS_VFPV2, but it is
> afaik quite rare to see arm9s with a vfp.
> 
> Committed with that changed, thanks.

default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

was indeed wrong, since having BR2_ARM_CPU_MAYBE_HAS_VFPV2 does not
indicate that the SoC has VFP.

However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM
cores for which NEON is optional, but for which the user has explicitly
requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it
is not the case for the VFP option. I think we should do that.
Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2
unit is actually available and used.

Thomas
Peter Korsgaard Oct. 26, 2015, 7:47 a.m. UTC | #8
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Peter Korsgaard,
 > On Sun, 25 Oct 2015 19:53:06 +0100, Peter Korsgaard wrote:

 >> > diff --git a/arch/Config.in.arm b/arch/Config.in.arm
 >> > index 4d10f4c..f0110b1 100644
 >> > --- a/arch/Config.in.arm
 >> > +++ b/arch/Config.in.arm
 >> > @@ -188,6 +188,7 @@ endchoice
 >> >  choice
 >> >  	prompt "Target ABI"
 >> >  	depends on BR2_arm || BR2_armeb
 >> > +	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2
 >> 
 >> I think we should only do it when we are certain it will run,
 >> E.G. arm926 (our default variant) selects MAYBE_HAS_VFPV2, but it is
 >> afaik quite rare to see arm9s with a vfp.
 >> 
 >> Committed with that changed, thanks.

 > default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

 > was indeed wrong, since having BR2_ARM_CPU_MAYBE_HAS_VFPV2 does not
 > indicate that the SoC has VFP.

Indeed.

 > However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM
 > cores for which NEON is optional, but for which the user has explicitly
 > requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it
 > is not the case for the VFP option. I think we should do that.
 > Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2
 > unit is actually available and used.

But packages should use the BR2_ARM_FPU_VFPV2 (and 3/4) symbols to check
if they should use the VFP, and not BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

I don't think kconfig will let us both have these options depend on
BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2 and select
BR2_ARM_CPU_HAS_VFPV2.
Thomas Petazzoni Oct. 26, 2015, 8:25 a.m. UTC | #9
Peter,

On Mon, 26 Oct 2015 08:47:54 +0100, Peter Korsgaard wrote:

>  > However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM
>  > cores for which NEON is optional, but for which the user has explicitly
>  > requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it
>  > is not the case for the VFP option. I think we should do that.
>  > Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2
>  > unit is actually available and used.
> 
> But packages should use the BR2_ARM_FPU_VFPV2 (and 3/4) symbols to check
> if they should use the VFP, and not BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

But then they have to test BR2_ARM_FPU_VFPV2 || BR2_ARM_FPU_VFPV3 ||
BR2_ARM_FPU_VFPV3D16 || ...

If they just want to know if a VFP is available.

> I don't think kconfig will let us both have these options depend on
> BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2 and select
> BR2_ARM_CPU_HAS_VFPV2.

Indeed, it doesn't. Some better solution is needed :)

Best regards,

Thomas
Peter Korsgaard Oct. 26, 2015, 8:51 a.m. UTC | #10
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Peter,
 > On Mon, 26 Oct 2015 08:47:54 +0100, Peter Korsgaard wrote:

 >> > However, unlike BR2_ARM_CPU_HAS_NEON which gets selected even on ARM
 >> > cores for which NEON is optional, but for which the user has explicitly
 >> > requested NEON support to be enabled (through BR2_ARM_ENABLE_NEON), it
 >> > is not the case for the VFP option. I think we should do that.
 >> > Otherwise, BR2_ARM_CPU_HAS_VFPV2 will not be true, even if the VFPv2
 >> > unit is actually available and used.
 >> 
 >> But packages should use the BR2_ARM_FPU_VFPV2 (and 3/4) symbols to check
 >> if they should use the VFP, and not BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2

 > But then they have to test BR2_ARM_FPU_VFPV2 || BR2_ARM_FPU_VFPV3 ||
 > BR2_ARM_FPU_VFPV3D16 || ...

 > If they just want to know if a VFP is available.

If that is the case we could make a hidden BR2_ARM_FPU_VFP that gets
selected by those, or simply check for !ARM_SOFT_FLOAT.
diff mbox

Patch

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index 4d10f4c..f0110b1 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -188,6 +188,7 @@  endchoice
 choice
 	prompt "Target ABI"
 	depends on BR2_arm || BR2_armeb
+	default BR2_ARM_EABIHF if BR2_ARM_CPU_MAYBE_HAS_VFPV2 || BR2_ARM_CPU_HAS_VFPV2
 	default BR2_ARM_EABI
 	help
 	  Application Binary Interface to use. The Application Binary