Date: Wed, 14 Jun 2017 23:20:51 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Message-ID: <C0FEFDC3-A873-4110-928A-E534D3FB5FE7@dsl-only.net> In-Reply-To: <CANCZdfqw4dwkrMtNO9zpdnuXkrmVrWf_M4Odcn5MY%2B0jz7h_dA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 2017-Jun-14, at 10:22 PM, Warner Losh <imp at bsdimp.com> wrote: > On Thu, Jun 8, 2017 at 2:27 PM, Warner Losh <imp at bsdimp.com> wrote: > >> While the kernel doesn't really need an armv7 support, there will be a >> better match to other systems if we create a armv7 MACHINE_ARCH. This will >> be in addition to the armv6 MACHINE_ARCH we have today. This will allow us >> to create a package set optimized for armv7 as well as armv6. While it is >> true the RPI 1 is the only system that needs armv6 binaries, it's quite >> popular and the Raspberry Pi folks keep creating new variants with the same >> chip. It would also let us get the package stuff spun up and working before >> we mess with armv6. >> >> This would also separate the fate of armv6 and armv7 support at a later >> time, but the weak consensus I've heard appears to be that the time isn't >> yet right to discuss retiring armv6 support... >> > > I've created a new FCP for this. You can comment on it at > https://github.com/freebsd/fcp/pull/6 but the FCP number may change since > the allocation isn't official. I've created this on the belief that > everybody here is either agnostic or fully supports this path. The FCP > tries to enumerate the work and impact, but currently needs your help to > flesh things out. I've done a first pass, but it's lame still. > > This is one of the first FCPs, so I'm going to use it a little as test case > for the larger thing. There will be bumps. Feels may get bruised, but if > so accept my apologies and help me do better in the future. > > I cc'd the re@ as a heads up that this may be coming down the pike and that > discussions so far have been super hand-wavey on the RE@ side of things. > I'd like to know what the actual impact will be so we can document it. At > this stage, it's still in the draft stage and nothing is certain. This is > my call for feedback, but call it 'pre-feedback' if I read FCP-0 wrong and > am doing it wrong :) My gut tells me that to make my doc better, do it on > the pull request. To raise serious issues that need to be discussed, reply > to this message. > > To talk about the many flavors of Rpi, about unified releases, 32-bit ports > to A-53, or any other odd tangents, please do that in arm@, but I'd humbly > request a new subject. > > Comments? I booted Ubuntu Mate on a BPI-M3 and tried: $ uname -p armv7l $ uname -ap Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux I was actually thinking that a "hf" might show up in how they name things if it was a hard float based build. But looking I see in /lib/ : . . . drwxr-xr-x 3 root root 16384 Nov 4 2016 arm-linux-gnueabihf . . . lrwxrwxrwx 1 root root 30 Oct 14 2016 ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.23.so lrwxrwxrwx 1 root root 24 Apr 21 2016 ld-linux.so.3 -> /lib/ld-linux-armhf.so.3 . . . and in /lib/arm-linux-gnueabihf/ : lrwxrwxrwx 1 root root 10 Oct 14 2016 /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so so it appears armv7l was used for naming a hard float build in uname -p. Of course this does not check how uniform the various linux distributions are about such naming. Still it may mean that for linux-matching "armv7" might not be the right name for uname -p output. === Mark Millard markmi at dsl-only.nethelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0FEFDC3-A873-4110-928A-E534D3FB5FE7>