FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

Andrew Turner andrew at fubar.geek.nz
Thu Feb 12 22:57:10 UTC 2015


On Thu, 12 Feb 2015 11:37:38 -0700
Warner Losh <imp at bsdimp.com> wrote:

> 
> > On Feb 12, 2015, at 10:58 AM, Nathan Whitehorn
> > <nwhitehorn at freebsd.org> wrote:
> > 
> > On 02/12/15 09:15, Ed Maste wrote:
> >>>> Oh - I don't care what directory Linux puts the kernel source
> >>>> in, only what's reported by uname.  As far as I can tell that
> >>>> has always been aarch64 for uname -m.
> >>> 
> >>> Traditionally in Linux, they have been a matched set.
> >> 
> >> Ok, it appears they may have abandoned this.
> >> 
> >>>> We might decide that "uname -m" has to be aarch64 to match
> >>>> expectations of third-party software set by other operating
> >>>> systems. If that in turn means we have to move the kernel
> >>>> source, so be it.
> >>> 
> >>> This one I’m not on board with. You’ve not made a compelling case
> >>> for it yet.
> >> 
> >> That's why I said "we might decide" -- I'm not sure myself.
> >> 
> >> However, there's no backwards compatibility concern here, we've
> >> never had a FreeBSD release that reports "arm64" for "uname -m".
> >> There's no reason for us to prefer "arm64" if everyone else uses
> >> "aarch64." Also, having arm64 for uname -m and aarch64 for uname
> >> -p seems a bit odd.
> > 
> > I would assume uname -m would be "arm", not "arm64". Unless there
> > are fundamental platform differences you are baking in somehow,
> > which I don't know.
> 
> arm would be a pleasing outcome, but looking at his WIP tree, it
> looks like it would be possible, but rather inconvenient to merge the
> arm64 bits back under arm and make them conditional.

They are two different architectures. They don't share any assembly,
and the exception handling is different, both in exception types and
number of modes/levels.

Along with this they only sort of share the special registers. The
method to access them is different, on 32-bit it is via a coprocessor
call where on 64-bit there is an instruction to get them by name.

We may be able to share some of the new pmap code, however it would
need a lot of work as the virtual memory layout is different and it is
likely we will need to handle 64k granules on arm64 in the future.
Because of this any sharing there would need to be handled carefully.

The interrupt controller and timer drivers will be shared, but these
are both devices and maybe they should be moved under sys/dev.

The two architectures will share very little code or headers. An ARMv8
core may be able to execute either 32 or 64-bit code (both are optional
so either one or both options will be enabled) so there is a case for
use to handle cc -m32, but I don't feel this is enough justification to
merge two otherwise different architectures just because they were
designed by the same company.

Andrew


More information about the freebsd-arm mailing list