Date: Tue, 15 Dec 2015 09:29:13 -0600 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <567031C9.2090109@denninger.net> In-Reply-To: <1450190791.25138.30.camel@freebsd.org> References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> <566EEAC4.1060306@denninger.net> <566F0238.9060605@denninger.net> <1450190791.25138.30.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 12/15/2015 08:46, Ian Lepore wrote: > 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 <karl@denninger.net> >>>> 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 Well, I'm reporting what I got. I followed the instructions in the Wiki, got a product nfsroot directory and the expected src and obj directories, attempted to mount the src and obj directories over nfs and execute a "make installworld" on the target and that blew up with complaints about expected directories being missing. I then attempted to rsync the nfsroot directory to the target machine (a Raspberry Pi2); that succeeded. But, once the machine was rebooted any attempt to execute anything that had floating point operations dumped; "awk", for example, blows up. I built on a 10.2-STABLE machine, if that matters. There appears to be something else odd going on with recent -CURRENT builds on RPI2s. I built on an Rpi2, mounted src and obj directories over NFS to the target and (apparently successfully) did a "make install" after setting TMPDIR to /var/tmp (attempting to go to the memdisk for /tmp runs out of space) -- specifically, everything "mostly" appears to be working but I am getting this in ntp: ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== FS.Denninger.ne .GPS. 1 u 48 64 377 1000.00 -109.55 1000.00 ntpq> And of course it won't lock with the delay and jitter being what they are there (those are not valid). That also looks like a floating-point problem and it is with a current build on a RPI2 and then installed over NFS. FreeBSD 11.0-CURRENT #3 r291949M: Mon Dec 7 13:37:41 CST 2015 karl@IPGw.Denninger.Net:/mnt/obj/mnt/usr/src/sys/RPI2 I've updated to be current as of this morning and am attempting another build to see if I can isolate what went wrong in that regard. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ [-- Attachment #2 --] 0 *H 010 `He 0 *H _0[0C)0 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA0 150421022159Z 200419022159Z0Z1 0 UUS10UFlorida10U Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0 *H 0 X@vkY Tq/vE]5#֯MX \8LJ/V?5Da+ sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y 5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5 Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0 *H Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 `He M0 *H 1 *H 0 *H 1 151215152913Z0O *H 1B@uһ(o7}=0oe{G~ڬq9. wj4^hּoAfmT0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H Cuda Systems LLC CA)0 *H d5^p$wKJu%g1M([W|j}Nјdrˌ6~HQPKvIC5 ", P5.t;5*%wMK< Tc4;m-bc6A7 Aqa}(^:|◷~VT2<(:(g0bѸ6(["L.F} k}R _~6`.&ٌ z?'Ҏk - *|P; N 3+>#D] Óxy6 iYcfMo|Mt"e 1 ȟ7mAXڋ[ iP8 iF" Y 2)tA>B%LQ@g~MPM*<<XlNO9kȞ `67!/0X71vJxh$u9QA*93Z u_5vf0&<y3P1 Hxנ~No UFXpS# ٤(4+ϕ08help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?567031C9.2090109>