Date: Thu, 15 Jun 2017 13:58:20 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Message-ID: <07E0EC6D-5CC4-4359-A5CE-2FCDF82B01D7@dsl-only.net> In-Reply-To: <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@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> <9F0F91FB-B4D4-4CD9-AA96-036A0DBB7E56@dsl-only.net>
index | next in thread | previous in thread | raw e-mail
[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 <markmi at dsl-only.net> wrote: > 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@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). 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.xz and its 003_all_coreutils-gentoo-uname.patch ) @@ -250,10 +369,14 @@ main (int argc, char **argv) if (toprint & PRINT_PROCESSOR) { char const *element = 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 <= __linux_procinfo (PROCINFO_PROCESSOR, processor, sizeof processor)) +#else if (0 <= sysinfo (SI_ARCHITECTURE, processor, sizeof processor)) +#endif element = processor; } #endif @@ -306,9 +429,13 @@ main (int argc, char **argv) if (element == unknown) { static char hardware_platform[257]; +#if defined (USE_PROCINFO) + if (0 <= __linux_procinfo (PROCINFO_HARDWARE_PLATFORM, hardware_platform, sizeof hardware_platform)) +#else size_t s = sizeof hardware_platform; static int mib[] = { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >= 0) +#endif element = 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=coreutils.git;a=history;f=src/uname.c;h=6378ab7342e5b46e686d719573af99475cc9d69f;hb=3df84f0492a97e07fe4de62bd2ed34e4dd3045ef I'm using version 8.27 of coreutils source below. . . if (toprint & PRINT_PROCESSOR) { char const *element = unknown; #if HAVE_SYSINFO && defined SI_ARCHITECTURE { static char processor[257]; if (0 <= sysinfo (SI_ARCHITECTURE, processor, sizeof processor)) element = processor; } #endif #ifdef UNAME_PROCESSOR if (element == unknown) { static char processor[257]; size_t s = sizeof processor; static int mib[] = { CTL_HW, UNAME_PROCESSOR }; if (sysctl (mib, 2, processor, &s, 0, 0) >= 0) element = processor; # ifdef __APPLE__ . . . # endif } #endif if (! (toprint == UINT_MAX && element == unknown)) print_element (element); } if (toprint & PRINT_HARDWARE_PLATFORM) { char const *element = unknown; #if HAVE_SYSINFO && defined SI_PLATFORM { static char hardware_platform[257]; if (0 <= sysinfo (SI_PLATFORM, hardware_platform, sizeof hardware_platform)) element = hardware_platform; } #endif #ifdef UNAME_HARDWARE_PLATFORM if (element == unknown) { static char hardware_platform[257]; size_t s = sizeof hardware_platform; static int mib[] = { CTL_HW, UNAME_HARDWARE_PLATFORM }; if (sysctl (mib, 2, hardware_platform, &s, 0, 0) >= 0) element = hardware_platform; } #endif if (! (toprint == UINT_MAX && element == unknown)) print_element (element); } === Mark Millard markmi at dsl-only.nethome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07E0EC6D-5CC4-4359-A5CE-2FCDF82B01D7>