Next up on creating armv7 MACHINE_ARCH: pre FCP stage
Mark Millard
markmi at dsl-only.net
Thu Jun 15 20:16:03 UTC 2017
On 2017-Jun-15, at 9:58 AM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Jun-15, at 8:40 AM, Mark Millard <markmi at dsl-only.net> 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.
>>
>> 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.
>>
>> I may do more experiments and report those too.
>> My notes are just information for Warner and others
>> to consider.
>
> An FYI:
>
> I tried the following on both kernel7.img files
> (this was via macOS):
>
> $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i sun8i | more
>
> $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i armv7 | more
>
> Both came up empty. The strings reported by uname -p -m -i
> do not seem to be directly from the kernels.
Summary: for Ubunutu unless HAVE_SYSINFO
and SI_ARCHITECTURE and SI_PLATFORM are
defined, it uses struct utsname's machine
member for all 3 of -m -p -i . This matches
what Ubuntu Mate reported (all 3 matching).
(I've not looked at Gentoo source yet.)
Supporting details. . .
The following is uname.c source from:
Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils 8.25-2ubuntu2 (dsc) [2,071 B]
Get:2 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils 8.25-2ubuntu2 (tar) [5,725 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports xenial/main coreutils 8.25-2ubuntu2 (diff) [28.0 kB]
Ubuntu's source for uname.c has:
if (toprint
& (PRINT_KERNEL_NAME | PRINT_NODENAME | PRINT_KERNEL_RELEASE
| PRINT_KERNEL_VERSION | PRINT_MACHINE))
{
struct utsname name; struct utsname name;
. . .
if (uname (&name) == -1)
error (EXIT_FAILURE, errno, _("cannot get system name")); if (toprint & PRINT_MACHINE)
print_element (name.machine);
. . .
and later has:
if (toprint & PRINT_PROCESSOR)
{
char *element = unknown;
#if HAVE_SYSINFO && defined SI_ARCHITECTURE
. . .
#else
{
struct utsname u;
uname(&u);
element = u.machine;
. . .
}
#endif
#ifdef UNAME_PROCESSOR
if (element == unknown)
{
. . .
So it appears that -m and -p are
explicitly returning the same text
(No SI_ARCHITECTURE).
Similarly for even later:
if (toprint & PRINT_HARDWARE_PLATFORM)
{
char *element = unknown;
#if HAVE_SYSINFO && defined SI_PLATFORM
. . .
#else
{
struct utsname u;
uname(&u);
element = u.machine;
if(strlen(element)==4 && element[0]=='i' && element[2]=='8' && element[3
]=='6')
element[1]='3';
}
#endif
#ifdef UNAME_HARDWARE_PLATFORM
if (element == unknown)
{
. . .
So it appears that -m and -p and -i
are explicitly returning the same text
(No SI_ARCHITECTURE nor SI_PLATFORM).
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-arm
mailing list