Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU
Date: Thu, 25 Aug 2016 00:14:32 +0200	[thread overview]
Message-ID: <20160825001432.0e4b42a6@free-electrons.com> (raw)
In-Reply-To: <dc3618df-52c5-c209-30a4-ea351fb2c49c@flatmax.org>

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.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  parent reply	other threads:[~2016-08-24 22:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  0:53 [Buildroot] [PATCH 0/3] arch/arm a53 + ARMV8, package/fftw rework Matt Flax
2016-08-23  0:53 ` [Buildroot] [PATCH 1/3] arch/arm: Add Cortex-a53 CPU Matt Flax
2016-08-23 22:03   ` Thomas Petazzoni
2016-08-23 23:44     ` Matt Flax
2016-08-24 21:20       ` Waldemar Brodkorb
2016-08-25  0:55         ` Matt Flax
2016-08-24 22:14       ` Thomas Petazzoni [this message]
2016-08-25  0:25         ` Matt Flax
2016-08-23  0:53 ` [Buildroot] [PATCH 2/3] package/fftw : Allow all precisions to be installed at the same time Matt Flax
2016-08-23 21:32   ` Thomas Petazzoni
2016-08-23  0:53 ` [Buildroot] [PATCH 3/3] arch/arm: Add ARMV8 (aarch32) toolchain config Matt Flax

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160825001432.0e4b42a6@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox