From owner-freebsd-arm@freebsd.org Tue Dec 15 14:47:40 2015 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 654E7A48FDF for ; Tue, 15 Dec 2015 14:47:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 4DCD21B29 for ; Tue, 15 Dec 2015 14:47:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 14:46:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFEkV5v020778; Tue, 15 Dec 2015 07:46:31 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450190791.25138.30.camel@freebsd.org> Subject: Re: Updating / keeping current strategies? From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Tue, 15 Dec 2015 07:46:31 -0700 In-Reply-To: <566F0238.9060605@denninger.net> References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> <566EEAC4.1060306@denninger.net> <566F0238.9060605@denninger.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 14:47:40 -0000 On Mon, 2015-12-14 at 11:54 -0600, Karl Denninger wrote: > On 12/14/2015 10:13, Karl Denninger wrote: > > > > On 12/8/2015 09:41, Paul Mather wrote: > > > On Dec 8, 2015, at 10:13 AM, Karl Denninger > > > wrote: > > > > > > > What are people doing in this regard with devices like the > > > > Raspberry Pi2? > > > > > > > > Build times for a "make buildworld" are measured in (many) > > > > hours to a > > > > day or more and require a USB-attached disk for temporary > > > > storage, as > > > > the ramdisk for /tmp that is typically mounted blows up due to > > > > lack of > > > > space and SD cards are slow enough on writes (especially small > > > > writes) > > > > as to make the process virtually impossible. But even with a > > > > USB-attached disk the process is ridiculous in terms of > > > > consumed > > > > walllclock time. > > > > > > > > Further, "make installworld" sometimes fails inexplicably. > > > > > > > > Kernel builds are a bit more reasonable, only requiring a > > > > couple of hours. > > > > > > > > I'm wondering what the best option is to not only build current > > > > code on > > > > a regular basis (since -CURRENT is a "work in progress") but > > > > also to > > > > deploy and update existing devices. What are people doing that > > > > has a > > > > history of working well? > > > I cross-build kernel and world on a FreeBSD/amd64 system. It > > > takes about 30 minutes to do a full buildkernel and buildworld > > > there. Then, when I want to update my Raspberry Pi, I shut down > > > the Pi and move the SD card from it to the FreeBSD/amd64 system. > > > Having mounted the SD card, I cross-install kernel and world > > > onto the SD card and then run mergemaster against it. I use the > > > wrapper script from > > > https://wiki.freebsd.org/FreeBSD/arm/crossbuild to make things > > > easier. > > > > > > After updating the SD card, I unmount it from the FreeBSD/amd64 > > > system and move it back to the Raspberry Pi. Finally, I boot up > > > the Raspberry Pi. > > > > > > This has proved a reliable way for me to update my Raspberry Pi > > > and BeagleBone Black. The manual step of moving the SD card > > > isn't ideal, but has proved to be the most pragmatic approach for > > > me. (Clang seems more reliable on FreeBSD/amd64, for one.:) > > > Someone suggested once to do the cross build/install on the > > > FreeBSD/amd64 system and then rsync over to the Pi/BBB to update > > > the SD card, but I could never get that to work. Similarly, I > > > could never get a NFS install to work either. To be fair, I > > > didn't troubleshoot that problem very much. > > > > > > Cheers, > > > > > > Paul. > > > > > There seem to be some problems with this in the general sense, > > unless > > you're willing to move the media around (I'm generally not.) > > > > Using that script in the Wiki appears to work, but there are > > problems. > > If you try to nfs mount the object and source directories on the > > target > > so you can do a "make installworld" or "make installkernel" on the > > target you quickly find that clang wasn't cross-built in the object > > directory; the "tmp" directory in object contains a copy of it, but > > it's > > compiled for your _*source*_ machine (in this case FreeBSD/amd64) > > and > > the install blows up as it can't determine the cc version. The > > interesting thing is that what's in ~/nfsroot/usr/bin/cc is correct > > which doesn't appear to make sense, but it is what it is. > > > > I'm going to see if I can get a rsync-type thing to work.... > > > It.... gets.... worse. > > I can update using rsync. However, the armv6hf target given in the > wiki > at https://wiki.freebsd.org/FreeBSD/arm/crossbuild produces binaries > that blow up when floating point is attempted. Armv6 is deprecated > and > won't build at all. > I'm having a hard time understanding this. Nobody else is reporting problems with cross-built binaries that use floating point. Also, armv6 is deprecated only in the sense that armv6hf is more efficient and there's no reason to use the old softfp ABI anymore. But that doesn't mean it can't be built, it builds and cross-builds just fine. -- Ian > This is bad for obvious reasons; it looks like cross-compile may > APPEAR > to work but in fact it does not. > > I have managed to mount (via NFS) the object and source directories > from > one Pi2 to another (having used the first as the build environment), > and > can installworld and installkernel this way, much like I would > otherwise.... the performance isn't great, but it works. >