Date: Thu, 15 Jun 2017 20:26:41 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm@freebsd.org Subject: Re: Next up on creating armv7 MACHINE_ARCH: pre FCP stage Message-ID: <319FAD30-F285-4AE3-B56E-2245F4608CB1@dsl-only.net> In-Reply-To: <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org> 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> <290f9213ac2b227442c68cb0e3f7fdd5@megadrive.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Jun-15, at 3:35 PM, Emmanuel Vadot <manu@bidouilliste.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?319FAD30-F285-4AE3-B56E-2245F4608CB1>