From owner-freebsd-arm@freebsd.org Thu Jun 15 20:58:23 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D196FBEEB2D for ; Thu, 15 Jun 2017 20:58:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 948AE84289 for ; Thu, 15 Jun 2017 20:58:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21063 invoked from network); 15 Jun 2017 20:58:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 15 Jun 2017 20:58:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 16:58:21 -0400 (EDT) Received: (qmail 32027 invoked from network); 15 Jun 2017 20:58:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Jun 2017 20:58:21 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EA569EC9281; Thu, 15 Jun 2017 13:58:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage From: Mark Millard In-Reply-To: <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> Date: Thu, 15 Jun 2017 13:58:20 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <07E0EC6D-5CC4-4359-A5CE-2FCDF82B01D7@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <0F64C8AC-576B-4E6E-BAB4-44FE819F9B44@dsl-only.net> <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 20:58:23 -0000 [After looking into the details my preliminary guess seems to be correct: the only dependable uname output among -m -p -i is for -m for linux. The uname.c code used varies from distribution to distribution. Below adds relevant gentoo uname.c source (a patch source) and gnu source. Previously I showed the relevant (and distinct) Ubuntu source.] On 2017-Jun-15, at 1:15 PM, Mark Millard wrote: > On 2017-Jun-15, at 9:58 AM, Mark Millard = wrote: >=20 >> On 2017-Jun-15, at 8:40 AM, Mark Millard = wrote: >>=20 >>=20 >>> On 2017-Jun-15, at 5:51 AM, Emmanuel Vadot wrote: >>>=20 >>>> On Thu, 15 Jun 2017 02:08:10 -0700 >>>> Mark Millard wrote: >>>>=20 >>>>> On 2017-Jun-14, at 11:20 PM, Mark Millard = wrote: >>>>>=20 >>>>>> On 2017-Jun-14, at 10:22 PM, Warner Losh = 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. >=20 > 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). >=20 > (I've not looked at Gentoo source yet.) >=20 > Supporting details. . . >=20 > The following is uname.c source from: >=20 > 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] >=20 > Ubuntu's source for uname.c has: >=20 > 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); > . . . >=20 > and later has: >=20 > 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) > { > . . . >=20 > So it appears that -m and -p are > explicitly returning the same text > (No SI_ARCHITECTURE). >=20 > Similarly for even later: >=20 > 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) > { > . . . >=20 >=20 > So it appears that -m and -p and -i > are explicitly returning the same text > (No SI_ARCHITECTURE nor SI_PLATFORM). Turns out that has a patch instead of independent source. . . Gentoo patches the gnu uname.c source to be different, including: (from = https://dev.gentoo.org/~polynomial-c/dist/coreutils-8.26-patches-1.1.tar.x= z and its 003_all_coreutils-gentoo-uname.patch ) @@ -250,10 +369,14 @@ main (int argc, char **argv) if (toprint & PRINT_PROCESSOR) { char const *element =3D unknown; -#if HAVE_SYSINFO && defined SI_ARCHITECTURE +#if (HAVE_SYSINFO && defined SI_ARCHITECTURE) || defined (USE_PROCINFO) { static char processor[257]; +#if defined (USE_PROCINFO) + if (0 <=3D __linux_procinfo (PROCINFO_PROCESSOR, processor, = sizeof processor)) +#else if (0 <=3D sysinfo (SI_ARCHITECTURE, processor, sizeof = processor)) +#endif element =3D processor; } #endif @@ -306,9 +429,13 @@ main (int argc, char **argv) if (element =3D=3D unknown) { static char hardware_platform[257]; +#if defined (USE_PROCINFO) + if (0 <=3D __linux_procinfo (PROCINFO_HARDWARE_PLATFORM, = hardware_platform, sizeof hardware_platform)) +#else size_t s =3D sizeof hardware_platform; static int mib[] =3D { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >=3D 0) +#endif element =3D hardware_platform; } #endif The ubuntu source uname.c source I reported earlier does not match what is seen via the gnu history at: = http://git.savannah.gnu.org/gitweb/?p=3Dcoreutils.git;a=3Dhistory;f=3Dsrc/= uname.c;h=3D6378ab7342e5b46e686d719573af99475cc9d69f;hb=3D3df84f0492a97e07= fe4de62bd2ed34e4dd3045ef I'm using version 8.27 of coreutils source below. . . if (toprint & PRINT_PROCESSOR) { char const *element =3D unknown; #if HAVE_SYSINFO && defined SI_ARCHITECTURE { static char processor[257]; if (0 <=3D sysinfo (SI_ARCHITECTURE, processor, sizeof = processor)) element =3D processor; } #endif #ifdef UNAME_PROCESSOR if (element =3D=3D unknown) { static char processor[257]; size_t s =3D sizeof processor; static int mib[] =3D { CTL_HW, UNAME_PROCESSOR }; if (sysctl (mib, 2, processor, &s, 0, 0) >=3D 0) element =3D processor; # ifdef __APPLE__ . . . # endif } #endif if (! (toprint =3D=3D UINT_MAX && element =3D=3D unknown)) print_element (element); } if (toprint & PRINT_HARDWARE_PLATFORM) { char const *element =3D unknown; #if HAVE_SYSINFO && defined SI_PLATFORM { static char hardware_platform[257]; if (0 <=3D sysinfo (SI_PLATFORM, hardware_platform, sizeof hardware_platform)) element =3D hardware_platform; } #endif #ifdef UNAME_HARDWARE_PLATFORM if (element =3D=3D unknown) { static char hardware_platform[257]; size_t s =3D sizeof hardware_platform; static int mib[] =3D { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >=3D 0) element =3D hardware_platform; } #endif if (! (toprint =3D=3D UINT_MAX && element =3D=3D unknown)) print_element (element); } =3D=3D=3D Mark Millard markmi at dsl-only.net