Re: build.sh distribution failure for evbarm

[Greg Troxel <gdt%lexort.com@localhost>]

Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes:

> It would benefit from some clarification regarding the ARM ecosystem
> indeed. So far I've always used ' evbarm' for my RPI builds and
> wondered if I can skip the building of the rest.

I think there are two separate issues behind your comment.

First is the type of build, which involves a MACHINE, one of the NetBSD
port types, corresponding to "uname -m", and then MACHINE_ARCH, which is
a CPU type, corresponding to "uname -p".

evbarm is a MACHINE that supports a number of hardware platforms and can
be built with a number oF MACHINE_ARCH values.

See src/build.sh, and search for evbarm.

If you build with "-a evbearmv6hf-el", that will use MACHINE=evbarm and
MACHINE_ARCH=earmv6hf (implicitly el).  That's the right CPU definition
for RPI1, and the same userland code will also run on RPI2/3.

If you build with evbearmv7hf-el, then the userland code will run on
RPI2/3 but not RPI1.  "file" on the userland code says EABI5, compiled
for earmv7hf.  The RPI kernel (for 1) is not built; I am guessing that
is because it needs earmv6hf and there's some logic to omit it.

These articles are helpful to sort through the confusing naming.  In
particular note that armvN and armN have different meanings - there are
familes, architectures and cores, all almost the same names, but really
in different namespaces!
  https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures
  https://en.wikipedia.org/wiki/ARM_architecture


The second issue is that you might wish to omit building a kernel for a
board type you don't have, even if it uses the same CPU and same
userland code.  This is more or less the same thing as skipping building
an alternative i386 kernel.   I am unaware of support for that.  But, my
impression is that there has been significant progress in having more
and more boards run GENERIC via FDT.  But there do seem to be 37 in
current when using evbearmv7hf-el.    I find it easier to just run
builds in the background than to adjust them.





> Anyway, with 'evbearmv6hf-el' the build completed successfully.
>
> On Fri, 2 Nov 2018 at 19:42, Greg Troxel <gdt%lexort.com@localhost> wrote:
>>
>>
>> Nick Hudson <nick.hudson%gmx.co.uk@localhost> writes:
>>
>> > RPI should use evbearmv6hf-el
>> > RPI2 should use evbearmv7hf-el
>> >
>> > I'm thinking evbarm should alias to evbearmv7hf-el these days
>>
>> Maybe, but another theory is that we should have a bunch of aliases and
>> that -a evbarm should just error out, because whoever invoked it that
>> way doesn't have a clear view of what they want.  And we should enable
>> RELEASEMACHINEDIR being equal to the alias by default, so that multiple
>> builds don't collide so much.
>>