From owner-freebsd-arm@freebsd.org Fri Jun 16 03:26:45 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 5DC69BF52FD for ; Fri, 16 Jun 2017 03:26:45 +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 0486E6E241 for ; Fri, 16 Jun 2017 03:26:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17005 invoked from network); 16 Jun 2017 03:26:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Jun 2017 03:26:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 15 Jun 2017 23:26:43 -0400 (EDT) Received: (qmail 9836 invoked from network); 16 Jun 2017 03:26:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 16 Jun 2017 03:26:42 -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 3ACB7EC8F7A; Thu, 15 Jun 2017 20:26:42 -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: <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> Date: Thu, 15 Jun 2017 20:26:41 -0700 Cc: Warner Losh , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <319FAD30-F285-4AE3-B56E-2245F4608CB1@dsl-only.net> References: <6EC26472-CE31-4B14-A049-3F153E590647@dsl-only.net> <20170615145107.97e6460fbb6222b258bfd614@bidouilliste.com> <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> 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: Fri, 16 Jun 2017 03:26:45 -0000 On 2017-Jun-15, at 3:35 PM, Emmanuel Vadot = wrote: > On 2017-06-15 17:40, Mark Millard wrote: > . . . >> 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. >=20 > Linux 4.11 have a correct support of A83T (and it will be better in = 4.12) >=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 > 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 >=20 >> I may do more experiments and report those too. >> My notes are just information for Warner and others >> to consider. >=20 > I'm one of the "others" hence my reply :) Good to know. I'll note here (in shorter form than the message sequence as I was investigating that showed the evidence): I looked at: A) gnu's coreutils and its uname.c B) Ubunutu's coreutils and its uname.c [an (A) variant but not via a .patch file] C) Gentoo's coreutils and its uname.c [a patch applied to (A)] All 3 have different handling of -p and -i in uname (even for the same kernel) via having different source code that does different things to generate the output. While all 3 do the same thing for -m it appears that various Linux distributions tend to tailor what -p and -i do, making the output vary. It does not look like depending on uname -p or uname -i output across different Linux distributions would a good idea (not very portable). Thus if FreeBSD really wants to have a uname output that agrees with a variety of Linux distributions it would appear that targeting uname -m for that would be the best of the 3. And the output text for -m for the armv7 hardfloat context would be: armv7l I've not done an inspection of how uname is used in a variety of ports or on Linux itself for upstream software, so the above is a rather one sided view of it. Of course FreeBSD could also decide to not target uname -m compatibility either. =3D=3D=3D Mark Millard markmi at dsl-only.net