Next up on creating armv7 MACHINE_ARCH: pre FCP stage

[Mark Millard]

On 2017-Jun-15, at 3:35 PM, Emmanuel Vadot <manu at 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.
> 
> Linux 4.11 have a correct support of A83T (and it will be better in 4.12)
> 
>> 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.
> 
> 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
> 
>> I may do more experiments and report those too.
>> My notes are just information for Warner and others
>> to consider.
> 
> 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.

===
Mark Millard
markmi at dsl-only.net