From owner-freebsd-arm@freebsd.org Fri Oct 13 02:06:04 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 59BD5E3A5F6 for ; Fri, 13 Oct 2017 02:06:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 221FC6FD1C for ; Fri, 13 Oct 2017 02:06:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id v9D264oX070927 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 Oct 2017 19:06:05 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id v9D264Ov070926; Thu, 12 Oct 2017 19:06:04 -0700 (PDT) (envelope-from fbsd) Date: Thu, 12 Oct 2017 19:06:04 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: Difficulty with armv6 to v7 transition. Message-ID: <20171013020604.GA70845@www.zefox.net> References: <20171009175216.GA52497@www.zefox.net> <1507573171.84167.9.camel@freebsd.org> <20171011023356.GA57571@www.zefox.net> <20171011030021.GB57571@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171011030021.GB57571@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 13 Oct 2017 02:06:04 -0000 It's starting to look as if the trouble might have little or nothing to do with the armv6-armv7 transition and instead has some other cause. At this point /etc/make.conf contains KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 DESTDIR=/ Buildkernel works, installkernel demanded a DESTDIR and worked once it was added, so /etc/make.conf is being read and acted upon. If make buildworld is invoked, using the make.conf file above, make reports make[1]: "/usr/src/Makefile.inc1" line 450: To cross-build, set TARGET_ARCH. *** [buildworld] Error code 1 I had to reconstruct all of /usr after mistakenly deleting it during an attempted housecleaning. The restored /usr seems to boot normally and builds kernels just fine, but does not allow su to root, so permissions (or something) are not entirely correct. Might this be related to the failure to recognize or act upon the TARGET_ARCH=armv7 setting? /usr/src is at 324562, along with the kernel. Userland dates from late June. Thanks for reading, and any ideas. bob prohaska On Tue, Oct 10, 2017 at 08:00:21PM -0700, bob prohaska wrote: > On Tue, Oct 10, 2017 at 08:41:17PM -0600, Warner Losh wrote: > > On Tue, Oct 10, 2017 at 8:39 PM, Warner Losh wrote: > > > > > > > > > > > On Tue, Oct 10, 2017 at 8:33 PM, bob prohaska wrote: > > > > > >> On Mon, Oct 09, 2017 at 12:19:31PM -0600, Ian Lepore wrote: > > >> > On Mon, 2017-10-09 at 10:52 -0700, bob prohaska wrote: > > >> > > On an RPI2 model B, invoking? > > >> > > make -j4 -DNO_CLEAN MACHINE_ARCH=armv7 buildworld > buildworld.log > > >> > > > >> > Never set MACHINE_ARCH when building, use TARGET_ARCH. ?Be sure to set > > >> > TARGET_ARCH when installing as well. > > >> > > >> Tried it, like so: > > >> root@www:/usr/src # make -j4 buildworld TARGET_ARCH=armv7 > > > >> buildworld.log & [1] 1006 > > >> root@www:/usr/src # 1 error > > >> > > >> [1] Exit 2 make -j4 buildworld > > >> TARGET_ARCH=armv7 > buildworld.log > > >> root@www:/usr/src # more *.log > > >> --- buildworld --- > > >> make[1]: "/usr/src/Makefile.inc1" line 450: To cross-build, set > > >> TARGET_ARCH. > > >> *** [buildworld] Error code 1 > > >> > > >> make: stopped in /usr/src > > >> > > >> I also tried setting TARGET=arm and WITHOUT_SYSTEM_COMPILER=yes in various > > >> iterations. Should the variables be set somewhere else, in a config file? > > >> > > >> At this point the kernel is at r324499, along with the sources. Userland > > >> dates from late June (operator error). Kernels build, but could that make > > >> the trouble I'm seeing? Clang -v reports > > >> > > >> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > > >> LLVM 4.0.0) > > >> Target: armv6-unknown-freebsd12.0-gnueabihf > > >> Thread model: posix > > >> InstalledDir: /usr/bin > > >> > > >> Thanks again! > > > > > > > > > uname -a says what? > > > > > > root@www:/usr/src # > root@www:/usr/src # uname -a > FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r324499: Tue Oct 10 18:06:39 PDT 2017 root@www.zefox.com:/usr/obj/usr/src/sys/RPI2 arm > > > What happens if you do a build with TARGET_ARCH=armv7? > > > > root@www:/usr/src # make TARGET_ARCH=armv7 buildworld > buildworld.log > make[1]: "/usr/src/Makefile.inc1" line 450: To cross-build, set TARGET_ARCH. > root@www:/usr/src # > > FWIW, /etc/make.conf does not exist. Seemingly the variable isn't recognized. > Maybe a config error someplace? > > Thanks again, > > bob prohaska >