FCP-100: armv7 plan

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

FCP-100: armv7 plan

Warner Losh
Greetings,

This will serve as 'Last Call' for any objections to the plan to create an
armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.

Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for all
the details. This has been discussed in the mailing lists, on IRC, etc and
I believe that I've captured the consensus from those discussions.

I'm interested in any last minute comments, but as far as I can tell I have
consensus on this issue. Absent any comments to the contrary, I'll proceed
to having core@ vote that this document represents consensus. Now is the
time to speak up if I've gotten anything wrong.

Once the core vote is done, I plan on committing the code reviews I have
open on this:
https://reviews.freebsd.org/D12027
and
https://reviews.freebsd.org/D12010
(again, I welcome any commits / criticisms in phabricator on the specific
issues in this code)

Thanks for any comments...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-100: armv7 plan

Russell Haley
On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh <[hidden email]> wrote:

> Greetings,
>
> This will serve as 'Last Call' for any objections to the plan to create an
> armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
>
> Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for all
> the details. This has been discussed in the mailing lists, on IRC, etc and
> I believe that I've captured the consensus from those discussions.
>
> I'm interested in any last minute comments, but as far as I can tell I have
> consensus on this issue. Absent any comments to the contrary, I'll proceed
> to having core@ vote that this document represents consensus. Now is the
> time to speak up if I've gotten anything wrong.
>
> Once the core vote is done, I plan on committing the code reviews I have
> open on this:
> https://reviews.freebsd.org/D12027
> and
> https://reviews.freebsd.org/D12010
> (again, I welcome any commits / criticisms in phabricator on the specific
> issues in this code)
>
> Thanks for any comments...
>
> Warner
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"

Hi Warner,

Thanks for your work on this. General thoughts in and around this subject.

1) I like how you split the commit into generic build system changes
vs BSP changes. It was helpful in aiding visibility in the code
changes.

2) Are these statements true?

- We will not be differentiating hard/soft float. It is assumed
armv6/7 are hard float (no letter suffixes)
- armv4/5 has no changes
- armv6 is split into armv6, armv7
- armv8 is aarch64
- We will not be supporting aarch64 32 bit extensions for running
armv6/7 binaries
- There is no way to run aarch64 on armv7

3) Can I ask if there will be other armv[0-9+]  architectures created
or do you think everything new will transition to 64 bit? If so, will
we (FreeBSD) be able to differentiate those architectures in the
future (aarch64v2)? I guess what I'm asking is "in your expert
opinion, have we taken enough steps to ensure clean
code/names/you-get-my-point for future changes?" What else could we
do? It seems that there is a lot of changes in arm compared to other
architectures. The rapid development of different things by the Arm
group and other vendors seems to cause a lot of churn. Do you think
our naming conventions do enough to take this into consideration?
Modern hardware manufacturing seem much different then what I am
reading about in Unix history. Have our naming patterns kept up?

4) Also, if my supposition about arm 32/64 compatibility is correct,
do we have plans in place for future boards may have 32/64 bit
compatibility like the RPi3? Or, is it just two different builds and
downloads? (which I'm cool with, but would like to know)

Cheers,

Russ
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-100: armv7 plan

Warner Losh
On Fri, Sep 8, 2017 at 7:52 PM, Russell Haley <[hidden email]> wrote:

> On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh <[hidden email]> wrote:
> > Greetings,
> >
> > This will serve as 'Last Call' for any objections to the plan to create
> an
> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
> >
> > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for
> all
> > the details. This has been discussed in the mailing lists, on IRC, etc
> and
> > I believe that I've captured the consensus from those discussions.
> >
> > I'm interested in any last minute comments, but as far as I can tell I
> have
> > consensus on this issue. Absent any comments to the contrary, I'll
> proceed
> > to having core@ vote that this document represents consensus. Now is the
> > time to speak up if I've gotten anything wrong.
> >
> > Once the core vote is done, I plan on committing the code reviews I have
> > open on this:
> > https://reviews.freebsd.org/D12027
> > and
> > https://reviews.freebsd.org/D12010
> > (again, I welcome any commits / criticisms in phabricator on the specific
> > issues in this code)
> >
> > Thanks for any comments...
> >
> > Warner
> > _______________________________________________
> > [hidden email] mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "[hidden email]"
>
> Hi Warner,
>
> Thanks for your work on this. General thoughts in and around this subject.
>
> 1) I like how you split the commit into generic build system changes
> vs BSP changes. It was helpful in aiding visibility in the code
> changes.
>

Thanks.


> 2) Are these statements true?
>
> - We will not be differentiating hard/soft float. It is assumed
> armv6/7 are hard float (no letter suffixes)
>

Yes. We switched to only hard float on armv6 prior to the switch. While one
can still build a softfloat system, it's not really supported (we don't
test it, we don't build packages for it, etc). That support exists in the
tree for the transition libraries only and may be removed in the future.


> - armv4/5 has no changes
>

Correct.


> - armv6 is split into armv6, armv7
>

Yes.


> - armv8 is aarch64
>

armv8 has no (current) meaning to FreeBSD.


> - We will not be supporting aarch64 32 bit extensions for running
> armv6/7 binaries
>

That's an orthogonal problem that a aarch64 kernel will solve, but is
unrelated to the build system.


> - There is no way to run aarch64 on armv7
>

Nope.


> 3) Can I ask if there will be other armv[0-9+]  architectures created
> or do you think everything new will transition to 64 bit? If so, will
> we (FreeBSD) be able to differentiate those architectures in the
> future (aarch64v2)? I guess what I'm asking is "in your expert
> opinion, have we taken enough steps to ensure clean
> code/names/you-get-my-point for future changes?" What else could we
> do? It seems that there is a lot of changes in arm compared to other
> architectures. The rapid development of different things by the Arm
> group and other vendors seems to cause a lot of churn. Do you think
> our naming conventions do enough to take this into consideration?
> Modern hardware manufacturing seem much different then what I am
> reading about in Unix history. Have our naming patterns kept up?
>

Those are all good questions. While it's hard to say for sure they won't be
any new armvX architectures that implement 32-bit ABIs, there's been a
strongly telegraphed signal that all new ARM innovation will be in the
64-bit area. They've also claimed that new revisions of aarch64 will be
more orderly and less chaotic than things have been in the 32-bit arm
world. It's unclear still if that will actually be the case, but given we
have little basis for guessing the proper names in the future, it's hard to
future-proof here.


> 4) Also, if my supposition about arm 32/64 compatibility is correct,
> do we have plans in place for future boards may have 32/64 bit
> compatibility like the RPi3? Or, is it just two different builds and
> downloads? (which I'm cool with, but would like to know)
>

The notion is that for those AARCH64 SoCs that have the ability to run
32-bit, we'll have two builds. One will be aarch64 based and the other
armv7 based. We'll likely roll that into armv7 GENERIC so we can get away
from having so many distributions (move to more of a base image + flavoring
step), but that work isn't complete enough to talk much about.

Work to make RPI3 work with a 32-bit kernel appears to be reaching
completion. There should be something there soon (if it hasn't already been
announced...)

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-100: armv7 plan

Russell Haley
On Fri, Sep 8, 2017 at 10:10 PM, Warner Losh <[hidden email]> wrote:

>
> On Fri, Sep 8, 2017 at 7:52 PM, Russell Haley <[hidden email]> wrote:
>>
>> On Fri, Sep 8, 2017 at 4:11 PM, Warner Losh <[hidden email]> wrote:
>> > Greetings,
>> >
>> > This will serve as 'Last Call' for any objections to the plan to create
>> > an
>> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
>> >
>> > Please see https://github.com/freebsd/fcp/blob/master/fcp-0100.md for
>> > all
>> > the details. This has been discussed in the mailing lists, on IRC, etc
>> > and
>> > I believe that I've captured the consensus from those discussions.
>> >
>> > I'm interested in any last minute comments, but as far as I can tell I
>> > have
>> > consensus on this issue. Absent any comments to the contrary, I'll
>> > proceed
>> > to having core@ vote that this document represents consensus. Now is the
>> > time to speak up if I've gotten anything wrong.
>> >
>> > Once the core vote is done, I plan on committing the code reviews I have
>> > open on this:
>> > https://reviews.freebsd.org/D12027
>> > and
>> > https://reviews.freebsd.org/D12010
>> > (again, I welcome any commits / criticisms in phabricator on the
>> > specific
>> > issues in this code)
>> >
>> > Thanks for any comments...
>> >
>> > Warner
>> > _______________________________________________
>> > [hidden email] mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> > To unsubscribe, send any mail to "[hidden email]"
>>
>> Hi Warner,
>>
>> Thanks for your work on this. General thoughts in and around this subject.
>>
>> 1) I like how you split the commit into generic build system changes
>> vs BSP changes. It was helpful in aiding visibility in the code
>> changes.
>
>
> Thanks.
>
>>
>> 2) Are these statements true?
>>
>> - We will not be differentiating hard/soft float. It is assumed
>> armv6/7 are hard float (no letter suffixes)
>
>
> Yes. We switched to only hard float on armv6 prior to the switch. While one
> can still build a softfloat system, it's not really supported (we don't test
> it, we don't build packages for it, etc). That support exists in the tree
> for the transition libraries only and may be removed in the future.
>
>>
>> - armv4/5 has no changes
>
>
> Correct.
>
>>
>> - armv6 is split into armv6, armv7
>
>
> Yes.
>
>>
>> - armv8 is aarch64
>
>
> armv8 has no (current) meaning to FreeBSD.
>
>>
>> - We will not be supporting aarch64 32 bit extensions for running
>> armv6/7 binaries
>
>
> That's an orthogonal problem that a aarch64 kernel will solve, but is
> unrelated to the build system.
>
>>
>> - There is no way to run aarch64 on armv7
>
>
> Nope.
>
>>
>> 3) Can I ask if there will be other armv[0-9+]  architectures created
>> or do you think everything new will transition to 64 bit? If so, will
>> we (FreeBSD) be able to differentiate those architectures in the
>> future (aarch64v2)? I guess what I'm asking is "in your expert
>> opinion, have we taken enough steps to ensure clean
>> code/names/you-get-my-point for future changes?" What else could we
>> do? It seems that there is a lot of changes in arm compared to other
>> architectures. The rapid development of different things by the Arm
>> group and other vendors seems to cause a lot of churn. Do you think
>> our naming conventions do enough to take this into consideration?
>> Modern hardware manufacturing seem much different then what I am
>> reading about in Unix history. Have our naming patterns kept up?
>
>
> Those are all good questions. While it's hard to say for sure they won't be
> any new armvX architectures that implement 32-bit ABIs, there's been a
> strongly telegraphed signal that all new ARM innovation will be in the
> 64-bit area. They've also claimed that new revisions of aarch64 will be more
> orderly and less chaotic than things have been in the 32-bit arm world. It's
> unclear still if that will actually be the case, but given we have little
> basis for guessing the proper names in the future, it's hard to future-proof
> here.
>
>>
>> 4) Also, if my supposition about arm 32/64 compatibility is correct,
>> do we have plans in place for future boards may have 32/64 bit
>> compatibility like the RPi3? Or, is it just two different builds and
>> downloads? (which I'm cool with, but would like to know)
>
>
> The notion is that for those AARCH64 SoCs that have the ability to run
> 32-bit, we'll have two builds. One will be aarch64 based and the other armv7
> based. We'll likely roll that into armv7 GENERIC so we can get away from
> having so many distributions (move to more of a base image + flavoring
> step), but that work isn't complete enough to talk much about.
>
> Work to make RPI3 work with a 32-bit kernel appears to be reaching
> completion. There should be something there soon (if it hasn't already been
> announced...)
>
> Warner
>
>

https://www.netgate.com/products/sg-3100.html ?

;)
Russ
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-100: armv7 plan

Jan Beich-5
In reply to this post by Warner Losh
Warner Losh <[hidden email]> writes:

> On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <[hidden email]> wrote:
>
>> Warner Losh <[hidden email]> writes:
>>
>> > Greetings,
>> >
>> > This will serve as 'Last Call' for any objections to the plan to create
>> an
>> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
>> [...]
>>
>> Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific
>> differences between armv6 and armv7. Clang appears to enable NEON for all
>> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and
>> Debian don't assume NEON on armv7.
>>
>> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898
>>
>
> Yes. We are vague about it on purpose. Just like we're vague about MMX,
> MMX2, etc on x86 because different processors can/want use different
> things.

Do you mean similar to how FreeBSD i386 is vague about not supporting
real i386, only i486 or later?

> The goal, if it doesn't work already, is for NEON to work if used,
> but not be required, just like all the other optional features of a CPU.

FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you
mean at compile time? If so then the following probably needs to change

$ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E -</dev/null |& fgrep -i neon
#define __ARM_NEON 1
#define __ARM_NEON_FP 0x4
#define __ARM_NEON__ 1
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Getauxval - was Re: FCP-100: armv7 plan

Russell Haley
Apologies for the top post. 

Man pages indicate ‎getauxval is a non standard glibc function. Is this an issue? Is there a more posix way I could compare against? I was previously wondering to myself if the Linux api is now more standard than the posix api?

Looking forward to all opinions and comments. 

Rus

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
  Original Message  
From: Konstantin Belousov
Sent: Saturday, September 9, 2017 2:46 PM
To: Ian Lepore
Cc: [hidden email]; [hidden email]; Jan Beich; Jan Beich
Subject: Re: FCP-100: armv7 plan

On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote:
> Adding the AT_HWCAP stuff would be relatively easy.  I'm not as sure
> what to do about getauxval().  To be maximally linux-compatible (which
> would be good for ports) we'd put getauxval() in libc and make it work
> just like the linux one.  That's a bit at odds with the support we have
> now, which is procstat_getauxv() in libprocstat.  It's not very
> compatible with how linux getauxval() works, so using just that might
> lead to a lot of patches in ports.

libprocstat is for accessing other processes information and address space.
Our libc already has _elf_aux_info, but it is not exported. If you have
a clear description of the desired API, I can add it (I do not want to
read glibc code).
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: FCP-100: armv7 plan

Stephen Kiernan
In reply to this post by Jan Beich-5
(replying to all this time)

There are ARMv7 systems that do not have hardware floating point.

This is identified by being able to enable CP10 and/or CP11 in the ACR. If
one tries to enable them and, upon reading the ACR back, the values get
reset, then the hardware is not there.

I know this because the BCM56160 SoC from Broadcom does not have hardware
floating point and it is a Cortex-A9-based SoC.

On Sat, Sep 9, 2017 at 3:37 PM, Warner Losh <[hidden email]> wrote:

> On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich <[hidden email]> wrote:
>
> > Warner Losh <[hidden email]> writes:
> >
> > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich <[hidden email]> wrote:
> > >
> > >> Warner Losh <[hidden email]> writes:
> > >>
> > >> > Greetings,
> > >> >
> > >> > This will serve as 'Last Call' for any objections to the plan to
> > create
> > >> an
> > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100.
> > >> [...]
> > >>
> > >> Some ports want NEON support but FCP-0100 is vague about
> > FreeBSD-specific
> > >> differences between armv6 and armv7. Clang appears to enable NEON for
> > all
> > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android
> and
> > >> Debian don't assume NEON on armv7.
> > >>
> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898
> > >>
> > >
> > > Yes. We are vague about it on purpose. Just like we're vague about MMX,
> > > MMX2, etc on x86 because different processors can/want use different
> > > things.
> >
> > Do you mean similar to how FreeBSD i386 is vague about not supporting
> > real i386, only i486 or later?
>
>
> I mean we don't enumerate the list of all the processor supported things.
> We default to compiling for a fairly middle of the road processor, but you
> can strip that back all the way to i486, or hyper optimize for the latest
> core-2 duo.
>
> However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best
> to avoid by declaring the two different. One may be able to run armv6
> binaries on an armv7 CPUs still, but we're not specifically guaranteeing
> it.
>
> > The goal, if it doesn't work already, is for NEON to work if used,
> > > but not be required, just like all the other optional features of a
> CPU.
> >
> > FreeBSD doesn't support detecting NEON at runtime unlike Linux.
>
>
> No, I don't mean that at all.  I mean we don't care if it is enabled or
> not. It doesn't affect the ABI. The kernel knows about the extensions and
> saves the context when it's in use, just like the x86 kernel saves MMX, etc
> context when it's in use.
>
> Do you
> > mean at compile time? If so then the following probably needs to change
> >
> > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E -</dev/null |&
> > fgrep -i neon
> > #define __ARM_NEON 1
> > #define __ARM_NEON_FP 0x4
> > #define __ARM_NEON__ 1
> >
>
> Right. that's based on the default target. gcc/clang can enable or disable
> it (and a dozen other things) depending on what options you give. We don't
> care. We'll run all binaries. It's up to the system integrator to mix/match
> the options so they get optimal performance for their platform.
>
> Just like on x86. If you compile for MMX and run it on 486 w/o run-time
> detection, you'll get a reserved instruction fault. Same philosophy here.
> We don't dictate policy for the binaries, just like on x86. However, most
> of them have run-time detection to be nicer to the users than a core dump,
> and most do the best thing for that CPU if they really care about
> performance, but those applications that don't can just do whatever and be
> fine.
>
> Warner
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"