Next up on creating armv7 MACHINE_ARCH: pre FCP stage

[Emmanuel Vadot]

On 2017-06-15 17:40, Mark Millard wrote:
> On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot <manu at bidouilliste.com> 
> wrote:
> 
>> On Thu, 15 Jun 2017 02:08:10 -0700
>> Mark Millard <markmi at dsl-only.net> wrote:
>> 
>>> On 2017-Jun-14, at 11:20 PM, Mark Millard <markmi at dsl-only.net> 
>>> wrote:
>>> 
>>>> On 2017-Jun-14, at 10:22 PM, Warner Losh <imp at bsdimp.com> wrote:
>>>> 
>>>>> . . .
>>>>> 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.
>>> 
>>> I tried another linux on the BPI-M3: gentoo .
>>> 
>>> # uname -p
>>> ARMv7 Processor rev 5 (v7l)
>>> 
>>> (Wow. Not what I expected.)
>>> 
>>> # uname -pa
>>> Linux bananapi 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 
>>> UTC 2016 armv7l ARMv7 Processor rev 5 (v7l) sun8i GNU/Linux
>>> 
>>> # uname -m
>>> armv7l
>>> 
>>> # uname -i
>>> sun8i
>>> 
>>> # ls -l /lib/ld-*
>>> -rwxr-xr-x 1 root root 134192 Mar 26  2016 /lib/ld-2.21.so
>>> lrwxrwxrwx 1 root root     10 Mar 26  2016 /lib/ld-linux-armhf.so.3 
>>> -> ld-2.21.so
>>> 
>>> So again armv7l seems to be the base name used for
>>> a hardfloat little-endian context --although it
>>> appears that "uname -m" gives text more likely to
>>> be used in testing for how to configure to match
>>> the live context. "uname -p" seems far less
>>> standardized for its results. The same for
>>> "uname -i".
>>> 
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>> 
>> On both your linux you are using linux-sunxi which is a fork of the
>> Allwinner kernel "maintained" by the sunxi community (and it is old).
>> To have the proper values of uname one should test running linux
>> vanilla kernel.
> 
> They both reported (extracted from the earlier text
> that I sent):
> 
> 3.4.39-BPI-M3-Kernel
> 3.4.39-BPI-M3-Kernel
> 
> It is the same kernel version from the same group
> for the same hardware context as far as what each
> reported.
> 
> While they may have varied the kernel for some
> reason without changing the version identification
> that is not want I would expect.
> 
> I expected it was the Ubuntu vs. Gentoo code that
> makes the difference, not the kernel.
> 
> I'm not aware of a modern vanilla kernel for the
> BPI-M3.

  Linux 4.11 have a correct support of A83T (and it will be better in 
4.12)

> From what I can tell for little armv7 boards like
> this having older kernels is a common case and
> is something ports code would normally deal with
> upstream. It is not just sunxi as I understand.

  It depends, I think that Beaglebone based boards are using a more up to 
date kernel.
  And in the Allwinner world the C.H.I.P. is using mostly a vanilla 
kernel

> I may do more experiments and report those too.
> My notes are just information for Warner and others
> to consider.

  I'm one of the "others" hence my reply :)

> ===
> Mark Millard
> markmi at dsl-only.net

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>