From owner-freebsd-arm@FreeBSD.ORG Thu Feb 12 23:11:33 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 325C88B4 for ; Thu, 12 Feb 2015 23:11:33 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1773B4E for ; Thu, 12 Feb 2015 23:11:32 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so10892505pdb.5 for ; Thu, 12 Feb 2015 15:11:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=DI/cyAltft+ovNxR1Paa/zSyCX5JMVc9V8So0BSetR4=; b=gjJjeU7MJtzhS33+xavAQsRqDc8vf/BdFDSYeRjNUNxYMvvoE8+WB9L5yox/pKKnQ/ 7THIQwCukG8c7Xi2H7FYOu2sycJXrBqCH/1LZ6qZuirLzjDtWzcqT9jS32Ltl0pCIohe KuZFTG/hg3SMHZDPxiy/Xa8NC7Qj3w2o6PZqwwsU034zhwh5L+9tVVY7v8LCuuNzXlBd VX/25WS1ntAqdFWyxTc8PZwa3q/yNsjJ94UJ5uyZj8CmkjVX8i/mmHpKk8UpkoUCJd7S W+jEegLwN0002yAmQh+Vgk/5UkoOzzqvOb1rk0RoyGtate3P7sdR3GVYhhHSwJ6I791P qrLg== X-Gm-Message-State: ALoCoQkbFMInJ/Gs2Y1so4guzG4hKlDpugkxllz4nhPOePIhcs4YvWXupgtwPhC45jCWk0pDgnmo X-Received: by 10.68.69.6 with SMTP id a6mr10498017pbu.82.1423782692162; Thu, 12 Feb 2015 15:11:32 -0800 (PST) Received: from [10.64.26.244] ([69.53.236.236]) by mx.google.com with ESMTPSA id g11sm4821519pat.24.2015.02.12.15.11.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 15:11:31 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification From: Warner Losh In-Reply-To: <20150212225655.26c865aa@bender.lan> Date: Thu, 12 Feb 2015 16:11:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51DBDD85-A1FD-4A18-946D-FB78252BB845@bsdimp.com> 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> To: Andrew Turner X-Mailer: Apple Mail (2.2070.6) 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: Thu, 12 Feb 2015 23:11:33 -0000 > On Feb 12, 2015, at 3:56 PM, Andrew Turner = wrote: >=20 > On Thu, 12 Feb 2015 11:37:38 -0700 > Warner Losh wrote: >=20 >>=20 >>> On Feb 12, 2015, at 10:58 AM, Nathan Whitehorn >>> wrote: >>>=20 >>> 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. >>>>>=20 >>>>> Traditionally in Linux, they have been a matched set. >>>>=20 >>>> Ok, it appears they may have abandoned this. >>>>=20 >>>>>> 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. >>>>>=20 >>>>> This one I=E2=80=99m not on board with. You=E2=80=99ve not made a = compelling case >>>>> for it yet. >>>>=20 >>>> That's why I said "we might decide" -- I'm not sure myself. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=E2=80=99m not sure how having either = aarch64/aarch64 or arm64/aarch64 instead of arm/aarch64 would preclude -m32 from working. Warner