All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.