From: Jaap Crezee <jaap@jcz.nl>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2 v3] package/nodejs: add version 4.1.2
Date: Sun, 22 Nov 2015 13:42:36 +0100 [thread overview]
Message-ID: <5651B83C.1030701@jcz.nl> (raw)
In-Reply-To: <5651094A.5080607@mind.be>
On 11/22/15 01:16, Arnout Vandecappelle wrote:
Thanks for your follow up!
> You have a good point. I don't think it's possible to have a NEON core without
> VFP floating point unit. Hm, looking at [1], NEON and FPU are independently
> optional, so theoretically you could have a Cortex-A9 with one but not the
> other. But that probably doesn't exist in practice (in fact, we don't know any
> Cortex-A9 that doesn't have both).
You are right, I dived further into it:
http://www.arm.com/cortex-a9.php
Advanced SIMD NEON? unit (Optional)
and
Cortex-A9 Floating-Point Unit (FPU)
(Optional)
But... as you also state, I have never seen any Cortex-A8 or higher witout a VFP-unit.
Anyone? Because that's stupid of me, but I advise clients about (TI though) Cortex-A8 and
higher in always having a VFP unit...
> However, I think it should be fixed in Config.in.arm instead. Basically,
> whenever NEON is selected, the VFP's 'maybe' should be converted into a 'has'.
> So something like
>
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -244,6 +244,9 @@ config BR2_ARM_ENABLE_NEON
> bool "Enable NEON SIMD extension support"
> depends on BR2_ARM_CPU_MAYBE_HAS_NEON
> select BR2_ARM_CPU_HAS_NEON
> + select BR2_ARM_CPU_HAS_VFPV3 if BR2_ARM_CPU_MAYBE_HAS_VFPV3
> + select BR2_ARM_CPU_HAS_VFPV4 if BR2_ARM_CPU_MAYBE_HAS_VFPV4
> help
> For some CPU cores, the NEON SIMD extension is optional.
> Select this option if you are certain your particular
>
> (Note that the VFPv2 cores never have NEON - at least as far as I know. Checked
> arm.com and that seems to be correct.)
Agree. I see the compiler being called with -mfpmath=neon (or something alike) so it seems
to be working next to VFPv2.
> However, when you look at it like that, the option is not named correctly. What
> the option is really about is specifying that the optional floating point/NEON
> unit is indeed present.
Here you have a good point.
> Alternatively, if we really do want to support the case where only one of NEON
> and VFPv3/4 is present, we should have a separate option similar to
> BR2_ARM_ENABLE_NEON to enable the FPU. And in that case, of course, all the
> MAYBEs should be removed from the Floating point strategy choice.
Anyone has more available time than me to look into patching this? Would be greatly
appreciated; would be using this for various customers of mine...
See http://www.arm.com/Cortex-A9-chip-diagram-LG.png also.
regards,
Jaap Crezee
next prev parent reply other threads:[~2015-11-22 12:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 21:59 [Buildroot] [PATCH 0/2 v3] package/nodejs: bump version (branch yem/node) Yann E. MORIN
2015-10-19 21:59 ` [Buildroot] [PATCH 1/2 v3] package/nodejs: fix architectural dependencies on ARM Yann E. MORIN
2015-10-19 21:59 ` [Buildroot] [PATCH 2/2 v3] package/nodejs: add version 4.1.2 Yann E. MORIN
2015-10-20 8:25 ` Martin Bark
2015-10-20 9:01 ` Richard Chapman
2015-10-20 16:25 ` Yann E. MORIN
2015-10-20 16:32 ` Martin Bark
2015-11-21 19:53 ` Jaap Crezee
2015-11-22 0:16 ` Arnout Vandecappelle
2015-11-22 12:42 ` Jaap Crezee [this message]
2015-11-22 21:28 ` Martin Bark
2015-10-20 8:02 ` [Buildroot] [PATCH 0/2 v3] package/nodejs: bump version (branch yem/node) Thomas Petazzoni
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=5651B83C.1030701@jcz.nl \
--to=jaap@jcz.nl \
--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.