[Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU

Matt Flax flatmax at flatmax.org
Thu Aug 25 00:25:24 UTC 2016



On 25/08/16 08:14, Thomas Petazzoni wrote:
> Matt,
>
> Please Cc: me on your replies. There's a lot of traffic on the
> Buildroot mailing list, so if you want me to be reactive on this
> discussion, you'd better Cc: me.
>
> On Wed, 24 Aug 2016 09:44:22 +1000, Matt Flax wrote:
>
>> Looks good. One thing though, my original Cortex-A53 patch selected
>> VFPV4 which is now incorrect,
>> that should be removed ... however that wouldn't enable any HF settings ...
> I've added a new patch that adds a BR2_ARM_CPU_HAS_FP_ARMV8 hidden
> option, and the related FPU options. For now, I'm only supporting the
> fp-armv8 and neon-fp-armv8 cases. It seems pretty clear that the FPU
> and NEON are mandatory on all ARMv8 cores, at least to date.
>
> I haven't taken into account the crypto-neon-fp-armv8 case, since it's
> not clear whether the crypto instructions are mandatory or not on all
> cores.
>
>> Also I don't understand why we need "select BR2_ARCH_HAS_MMU_OPTIONAL"
>> but as I mentioned,
>> uclibc doesn't compile cleanly without it ... seems like a deep rooted
>> problem.
> If you don't select BR2_ARCH_HAS_MMU_OPTIONAL, then the BR2_USE_MMU
> option is never set to 'y', so Buildroot configures uClibc as if it was
> building for a noMMU platform.
>
> However, for ARMv8, I believe we should probably be using
> BR2_ARCH_HAS_MMU_MANDATORY instead, since I don't think running an
> ARM64 without the MMU enabled is supported.
>
>> I am not sure about the fine detail, but it seems that ARMV8 extends
>> VFPV4, perhaps there should be an extension of VFPV4 which is similar to
>> the extension of VFPV3 to VFPV4 ?
> That's what I've done with BR2_ARM_CPU_HAS_FP_ARMV8.
>
>> The "- mcpu" flag is the same between aarch32 and aarch64, so that
>> simplifies the BR2_GCC_TARGET_CPU to being the same for both.
> No, it's not the same. On ARM 32 bits you have separate -mcpu and -mfpu
> options. On ARM 64 bits, you only have the -mcpu option with its
> modifier mechanism. I've handled this in my new version of the patch
> series.
>
>> However aarch64 and aarch32 seem to require different BR2_GCC_TARGET_FPU
>> lines. I am pretty certain that we need the aarch32 BR2_GCC_TARGET_FPU
>> line to include at least "neon" in some way.
> ARM64 cannot have a BR2_GCC_TARGET_FPU line, because there's no -mfpu
> option, at least according to the gcc documentation at
> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/AArch64-Options.html#AArch64-Options.
>
>>> Also, it is worth reminding that there are some ARMv8-A cores that are
>>> 32-bits only: the Cortex-A32 is one example. So ARMv8-A is not equal to
>>> 64 bits support.
>> Actually I think all ARMv8-A cores are 64bit,
> No: the Cortex-A32 is 32 bits only. See
> http://www.arm.com/products/processors/cortex-a/cortex-a32-processor.php.
>
>> The aarch32 requires a "-fpu" setting to specify "neon-fp-armv8" as my
>> suggested default.
> I've used fp-armv8 as the default, because NEON is not always good for
> FPU operations. From the gcc documentation:
>
>     If the selected floating-point hardware includes the NEON extension
>     (e.g. -mfpu=‘neon’), note that floating-point operations are not
>     generated by GCC's auto-vectorization pass unless
>     -funsafe-math-optimizations is also specified. This is because NEON
>     hardware does not fully implement the IEEE 754 standard for
>     floating-point arithmetic (in particular denormal values are treated
>     as zero), so the use of NEON instructions may lead to a loss of
>     precision.
>
>> The aarch64 requires a "-mcpu"  setting to specify the cpu with feature
>> suffixes ... I note however that fp and simd are on by default when we
>> select the cpu option. Is it necessary to enable these to be turned off
>> ? If not necessary and we don't desire crypto, then we don't need to
>> specify more for the cpu other then the cpu name, i.e. cortex-a53
> I've for now used:
>
> +	default "cortex-a53"		if (BR2_cortex_a53 && !BR2_ARCH_IS_64)
> +	default "cortex-a53+fp"		if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_FP_ARMV8)
> +	default "cortex-a53+fp+simd" 	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_NEON_FP_ARMV8)
>   
> I.e:
>
>   -mcpu=cortex-a53 for Cortex-A53 used in ARM 32 bits mode
>
>   -mcpu=cortex-a53+fp when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_FP_ARMV8 is selected
>
>   -mcpu=cortex-a53+fp+simd when Cortex-A53 used in ARM 64 bits mode and BR2_ARM_FPU_NEON_FP_ARMV8 is selected
>
> Can you have a look at my updated branch at
> http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=aarch64
> and let me know what you think? If you're starting to be happy with it,
> I can post it on the mailing list for proper review.

I think we are almost there.
The three selections for "-mcpu" above may be equivalent. On their 
aarch64 gcc options page, GNU say that both fp and simd are "on by 
default for all possible values for options -march and -mcpu. ".
If you think it is important to disable them by default, then you may 
need to use :

default "cortex-a53" 		if (BR2_cortex_a53 && !BR2_ARCH_IS_64)
default "cortex-a53+fp+nosimd"	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_FP_ARMV8)
default "cortex-a53+fp+simd" 	if (BR2_cortex_a53 && BR2_ARCH_IS_64 && BR2_ARM_FPU_NEON_FP_ARMV8)

Perhaps we should start thinking about including a crypto option for 
ARMV8 in the future ... this should speed up encryption and key 
generation ... may have drastic performance increases when using 
encrypted storage as root or home or otherwise.

Matt



More information about the buildroot mailing list