Date: Thu, 15 Jun 2017 13:15:58 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Message-ID: <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> In-Reply-To: <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> References: <CANCZdfqw4dwkrMtNO9zpdnuXkrmVrWf_M4Odcn5MY%2B0jz7h_dA@mail.gmail.com> <C0FEFDC3-A873-4110-928A-E534D3FB5FE7@dsl-only.net> <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <FC393FFD-7461-40C6-9282-076016A2C567@dsl-only.net> <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >=20 >> On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot <manu at bidouilliste.com> = wrote: >>=20 >>> On Thu, 15 Jun 2017 02:08:10 -0700 >>> Mark Millard <markmi@dsl-only.net> wrote: >>>=20 >>>> On 2017-Jun-14, at 11:20 PM, Mark Millard <markmi at dsl-only.net> = wrote: >>>>=20 >>>>> On 2017-Jun-14, at 10:22 PM, Warner Losh <imp at bsdimp.com> = wrote: >>>>>=20 >>>>>> . . . >>>>>> Comments? >>>>>=20 >>>>> I booted Ubuntu Mate on a BPI-M3 and tried: >>>>>=20 >>>>> $ uname -p >>>>> armv7l >>>>>=20 >>>>> $ 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 >>>>>=20 >>>>> 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/ : >>>>>=20 >>>>> . . . >>>>> 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 >>>>> . . . >>>>>=20 >>>>> and in /lib/arm-linux-gnueabihf/ : >>>>>=20 >>>>> lrwxrwxrwx 1 root root 10 Oct 14 2016 = /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so >>>>>=20 >>>>> so it appears armv7l was used for naming a >>>>> hard float build in uname -p. >>>>>=20 >>>>> Of course this does not check how uniform the >>>>> various linux distributions are about such >>>>> naming. >>>>>=20 >>>>> Still it may mean that for linux-matching "armv7" >>>>> might not be the right name for uname -p output. >>>>=20 >>>> I tried another linux on the BPI-M3: gentoo . >>>>=20 >>>> # uname -p >>>> ARMv7 Processor rev 5 (v7l) >>>>=20 >>>> (Wow. Not what I expected.) >>>>=20 >>>> # 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 >>>>=20 >>>> # uname -m >>>> armv7l >>>>=20 >>>> # uname -i >>>> sun8i >>>>=20 >>>> # 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 >>>>=20 >>>> 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". >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>=20 >>> 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. >>=20 >> They both reported (extracted from the earlier text >> that I sent): >>=20 >> 3.4.39-BPI-M3-Kernel >> 3.4.39-BPI-M3-Kernel >>=20 >> It is the same kernel version from the same group >> for the same hardware context as far as what each >> reported. >>=20 >> While they may have varied the kernel for some >> reason without changing the version identification >> that is not want I would expect. >>=20 >> I expected it was the Ubuntu vs. Gentoo code that >> makes the difference, not the kernel. >>=20 >> I'm not aware of a modern vanilla kernel for the >> BPI-M3. >>=20 >> =46rom 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. >>=20 >> I may do more experiments and report those too. >> My notes are just information for Warner and others >> to consider. >=20 > An FYI: >=20 > I tried the following on both kernel7.img files > (this was via macOS): >=20 > $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i sun8i | more >=20 > $ strings /Volumes/BPI-BOOT/kernel7.img | grep -i armv7 | more >=20 > 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) =3D=3D -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 =3D unknown; #if HAVE_SYSINFO && defined SI_ARCHITECTURE . . . #else { struct utsname u; uname(&u); element =3D u.machine; . . . } #endif #ifdef UNAME_PROCESSOR if (element =3D=3D 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 =3D unknown; #if HAVE_SYSINFO && defined SI_PLATFORM . . . #else { struct utsname u; uname(&u); element =3D u.machine; if(strlen(element)=3D=3D4 && element[0]=3D=3D'i' && = element[2]=3D=3D'8' && element[3 ]=3D=3D'6') element[1]=3D'3'; } #endif #ifdef UNAME_HARDWARE_PLATFORM if (element =3D=3D unknown) { . . . So it appears that -m and -p and -i are explicitly returning the same text (No SI_ARCHITECTURE nor SI_PLATFORM). =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?9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56>