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> References: <CANCZdfqw4dwkrMtNO9zpdnuXkrmVrWf_M4Odcn5MY%2B0jz7h_dA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> 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. >>=20 >> 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... >>=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0FEFDC3-A873-4110-928A-E534D3FB5FE7>