Date: Sat, 23 Jun 2012 16:17:22 -0600 From: Warner Losh <wlosh@bsdimp.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: arm@freebsd.org Subject: Re: armv6 tree vs. buildkernel Message-ID: <9204F891-C26B-4BED-9866-B31281521683@bsdimp.com> In-Reply-To: <0078302D-CC33-4B89-87BE-50C77D4855BE@freebsd.org> References: <3F1A5B5F-0787-41CE-8C77-8B1F9A601172@freebsd.org> <31C8D224-72D4-4BE8-8EC3-29B078C7DAC3@bsdimp.com> <C75EE66B-30CE-48C7-8CC2-5DEC9F9D7F24@freebsd.org> <D0A60CD4-E0CF-4D7B-9E87-22D9A12048D1@bsdimp.com> <0078302D-CC33-4B89-87BE-50C77D4855BE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 23, 2012, at 3:07 PM, Tim Kientzle wrote: >=20 > On Jun 23, 2012, at 12:58 PM, Warner Losh wrote: >=20 >>=20 >> On Jun 23, 2012, at 12:58 PM, Tim Kientzle wrote: >>> On Jun 23, 2012, at 7:35 AM, Warner Losh wrote: >>>>=20 >>>>> P.S. How is CPUTYPE/TARGET_CPUTYPE supposed to be inferred for = regular "buildworld"? >>>>> The only option I can find is to set it explicitly in = /etc/src.conf >>>>=20 >>>> It can't possibly work very well. We need to get TARGET_ARCH=3Darmv6= working instead of continuing these kludges. >>>=20 >>>=20 >>> Help get me oriented and I'll start grinding through this. >>>=20 >>> What values of TARGET_ARCH should be supported? >>=20 >> arm, armeb, armv6 (and maybe armv6eb if they make those). >=20 > So do you consider the -DARM_ARCH_6 and -D_ARM_ARCH_6 > defines to be among these "kluges"? Yes. The compilers built when we're doing armv6 should have them = defined. I believe they are standard. If not, we should migrate tot he = standard defines. There was some churn in Mips land because of this = (some of which I fixed, some of which I caused :). > How should the C source identify the architecture and > customize itself? I'm not sure I understand this question. > I'm trying to get a clearer picture of how this *should* > work before I start roto-tilling a lot of code. Excellent idea. >>> Right now, there are ARCH values of arm and armeb. >>> Should there be armv6eb? armv7? >>=20 >> There should be no armv7, since armv6 means v6 and later. At some = point there will be an arm64, I suppose too. >=20 > So if someone wants an armv7 tree, they should have > TARGET=3Darm > TARGET_ARCH=3Darmv6 > TARGET_CPUTYPE=3Darmv7 Correct. This is much the same as if someone wants a nahalem tree on = x86: TARGET=3Di386 TARGET_ARCH=3Di386 TARGET_CPUTYPE=3Dnahalem or TARGET=3Damd64 TARGET_ARCH=3Damd64 TARGET_CPUTYPE=3Dnahalem to pick which base you are compiling against, and then which = optimizations you wish to build for. >>> I'm also unclear on the distinction between make's MACHINE_ARCH >>> and uname -p; are these supposed to be the same? If so, shouldn't >>> make be using a sysctl instead of a hard-coded value? >>=20 >> I thought it already did. That might not be a bad idea. = MACHINE_ARCH and uname -p should be identical. If they aren't, that's a = bug. >=20 > Ah. That helps. (This certainly isn't true in the current > make source and I can't find where this assumption > is documented.) I'm not sure it is. Note that there's a planned migration to bmake = soonish. >> I posted patches here before to do all (most?) of MACHINE_ARCH=3Darmv6.= Have you tried them on the armv6 branch? I've not had a chance to = port them over yet. >=20 > I've seen some oblique references to those patches but > haven't tracked them down to study yet. >=20 > Is this r234548 in users/imp? Yes, that's one of the two intermingled patches. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9204F891-C26B-4BED-9866-B31281521683>