From owner-freebsd-arm@freebsd.org Mon Oct 2 21:48:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5525EE28714 for ; Mon, 2 Oct 2017 21:48:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 118BA7CCAF for ; Mon, 2 Oct 2017 21:48:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23109 invoked from network); 2 Oct 2017 21:42:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Oct 2017 21:42:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 02 Oct 2017 17:42:00 -0400 (EDT) Received: (qmail 8426 invoked from network); 2 Oct 2017 21:41:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Oct 2017 21:41:59 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B003EC9390; Mon, 2 Oct 2017 14:41:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) From: Mark Millard In-Reply-To: Date: Mon, 2 Oct 2017 14:41:58 -0700 Cc: Ian Lepore , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <1506962766.22078.69.camel@freebsd.org> <6B133241-6C83-4FE4-B5E8-D3302B3579B4@dsl-only.net> To: Russell Haley X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 21:48:42 -0000 On 2017-Oct-2, at 11:46 AM, Russell Haley wrote: > On Mon, Oct 2, 2017 at 10:10 AM, Mark Millard wrote: >> [I'm not arguing against the points or questions: >> just noting a specific technique for CPU-targeting >> the built kernel code.] >> >> On 2017-Oct-2, at 9:46 AM, Ian Lepore wrote: >> >>> . . . >>> A GENERIC kernel gives worse performance than a per-soc kernel for >>> virtually every soc since we have to compile for the lowest common >>> denominator (things like using software divide on systems that have >>> hardware divide instructions). >> >> I use src.conf files for CPU targeting, for both native and cross >> building. For example (cross build): >> >> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.amd64-host >> TO_TYPE=aarch64 >> TOOLS_TO_TYPE=${TO_TYPE} >> # >> KERNCONF=GENERIC-NODBG >> TARGET=arm64 >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER= >> WITHOUT_SYSTEM_COMPILER= >> # >> WITH_LIBCPLUSPLUS= >> WITHOUT_BINUTILS_BOOTSTRAP= >> WITH_ELFTOOLCHAIN_BOOTSTRAP= >> WITH_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLD_BOOTSTRAP= >> WITH_LLD= >> WITH_LLD_IS_LD= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> WITHOUT_GCC_BOOTSTRAP= >> WITHOUT_GCC= >> WITHOUT_GCC_IS_CC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> #WERROR= >> MALLOC_PRODUCTION= >> # >> WITH_REPRODUCIBLE_BUILD= >> WITH_DEBUG_FILES= >> # >> XCFLAGS+= -mcpu=cortex-a53 >> XCXXFLAGS+= -mcpu=cortex-a53 >> # There is no XCPPFLAGS but XCPP gets XCFLAGS content. >> >> >> And for native I used the CFLAGS.clang notation: >> >> # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host >> TO_TYPE=aarch64 >> TOOLS_TO_TYPE=${TO_TYPE} >> # >> KERNCONF=GENERIC-NODBG >> TARGET=arm64 >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> #WITH_CROSS_COMPILER= >> WITH_SYSTEM_COMPILER= >> # >> #CPUTYPE=soft >> WITH_LIBCPLUSPLUS= >> WITHOUT_BINUTILS_BOOTSTRAP= >> WITH_ELFTOOLCHAIN_BOOTSTRAP= >> #WITHOUT_CLANG_BOOTSTRAP= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_CLANG_EXTRAS= >> WITH_LLD_BOOTSTRAP= >> WITH_LLD= >> WITH_LLD_IS_LD= >> WITH_LLDB= >> # >> WITH_BOOT= >> WITHOUT_LIB32= >> # >> WITHOUT_GCC_BOOTSTRAP= >> WITHOUT_GCC= >> WITHOUT_GCC_IS_CC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> #WERROR= >> MALLOC_PRODUCTION= >> # >> WITH_REPRODUCIBLE_BUILD= >> WITH_DEBUG_FILES= >> # >> # Use of the .clang 's here avoids >> # interfering with other CFLAGS >> # usage, such as ?= usage. >> CFLAGS.clang+= -mcpu=cortex-a53 >> CXXFLAGS.clang+= -mcpu=cortex-a53 >> CPPFLAGS.clang+= -mcpu=cortex-a53 >> >> >> . . . >> >> === >> Mark Millard >> markmi at dsl-only.net > > What advantage do does this confer to your testing? My use is personal-interest use. I've no reason to bother disabling things from GENERIC: I include GENERIC and override to produce non-debug. (That is a head/ example, not stable/ or release/ or releng/ .) But I also have no reason to have the kernel's machine code portable across various subfamilies. On the lower power, lower performance types of hardware that I have access to I bias towards tailoring to the CPU type. (I do not have access to any BIG.little configurations were code common to the mix might be important. But to my knowledge FreeBSD does not support any BIG.little combinations anyway.) [There was an occasion where my use of -mcpu helped identify/confirm a point/presumption that need not hold. But I'm not the only one that does such tailoring.] I normally do not use the snapshots or releases. I do not bias the builds for old PowerMac's to match CPU details for what I have access to (beyond powerpc64 vs. powerpc that is already involved). As for why I wrote about it: the CPU type for kernel builds can be controlled outside the kernel-config files, at least within a family: For armv6 the GENERIC kernel configuration files already indicate the more generic armv7 classification. I just pick a more specific member of the family. aarch64 has a similar status. I would not try to step outside a family with the src.conf way of specifying CPUs. (Something that I probably should have mentioned in the original message.) Also: I'd guess that Ian builds kernels rather than using the "standard" ones. It was his text that I was replying to. He likely knew anyway but his note might leave a misimpression about alternatives for that specific issue. It is one thing to have GENERIC span some of the small, low power SOC's and boards. It is another to have only GENERIC for them. (But for my use GENERIC-based is fine so I do not have an example that would drive the FreeBSD choice on the issue.) === Mark Millard markmi at dsl-only.net