FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

Warner Losh imp at bsdimp.com
Thu Feb 12 23:11:33 UTC 2015


> On Feb 12, 2015, at 3:56 PM, Andrew Turner <andrew at fubar.geek.nz> wrote:
> 
> 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.

Yea, rather inconvenient :)

> 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.

We support -m32 on x86 where we have amd64 and i386 MACHINE values
and directories today. I’m not sure how having either aarch64/aarch64 or
arm64/aarch64 instead of arm/aarch64 would preclude -m32 from working.

Warner



More information about the freebsd-arm mailing list