Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage
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_at_ 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_at_ 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_at_, but I'd humbly
> request a new subject.
I booted Ubuntu Mate on a BPI-M3 and tried:
$ uname -p
$ 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
Still it may mean that for linux-matching "armv7"
might not be the right name for uname -p output.
markmi at dsl-only.net
Received on Thu Jun 15 2017 - 06:20:59 UTC