From owner-freebsd-arm@FreeBSD.ORG Fri Feb 13 00:12:59 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E58A932 for ; Fri, 13 Feb 2015 00:12:59 +0000 (UTC) Received: from anacreon.physics.berkeley.edu (anacreon.Physics.Berkeley.EDU [128.32.117.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anacreon.physics.wisc.edu", Issuer "anacreon.physics.wisc.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B57E240 for ; Fri, 13 Feb 2015 00:12:58 +0000 (UTC) Received: from anacreon.physics.berkeley.edu (localhost [127.0.0.1]) by anacreon.physics.berkeley.edu (8.14.9/8.14.9) with ESMTP id t1D0Co0H074244; Thu, 12 Feb 2015 16:12:50 -0800 (PST) (envelope-from nwhitehorn@freebsd.org) Message-ID: <54DD4182.7040505@freebsd.org> Date: Thu, 12 Feb 2015 16:12:50 -0800 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD powerpc; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Warner Losh , Andrew Turner Subject: Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification References: <607BF592-A09B-4DB4-9872-C9E63066AB57@bsdimp.com> <71E9C1B9-F819-420B-90A5-A36D58E71817@bsdimp.com> <228428CC-4042-4902-90A4-E7040F4BFFF5@bsdimp.com> <54DCE9B5.8040203@freebsd.org> <20150212225655.26c865aa@bender.lan> <51DBDD85-A1FD-4A18-946D-FB78252BB845@bsdimp.com> In-Reply-To: <51DBDD85-A1FD-4A18-946D-FB78252BB845@bsdimp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 00:12:59 -0000 On 02/12/15 15:11, Warner Losh wrote: > >> On Feb 12, 2015, at 3:56 PM, Andrew Turner wrote: >> >> On Thu, 12 Feb 2015 11:37:38 -0700 >> Warner Losh wrote: >> >>> >>>> On Feb 12, 2015, at 10:58 AM, Nathan Whitehorn >>>> 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 :) Yes. For my own interest, how similar are 32-bit ARMv8 and 64-bit ARMv8? Is 32-bit ARMv8 just the same as 32-bit ARMv7? It seems weird that the architectures would be that disjoint, but, if they are, I agree it makes sense more to treat them like ia64 and i386 than a conventional 32-bit/64-bit port. >> 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. It just makes it harder since /usr/include/machine isn't shared. There were a lot of hacks required to make that functional on x86, which you'd have to repeat. -Nathan