From owner-freebsd-arm@freebsd.org Mon Dec 14 06:40:24 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 7D4A4A43016; Mon, 14 Dec 2015 06:40:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 466CA10DC; Mon, 14 Dec 2015 06:40:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkca188 with SMTP id a188so148966347vkc.0; Sun, 13 Dec 2015 22:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FOfZ7b+2Hhik96LG6LSeu8mePwcek60QdWci9qJWi9c=; b=j9JYkm8q4VpLOFlRRvu3mXVL9edL9/tTequF2bZWUgrOV/FNiHxuqRHmgeyYKg+cqd ONrK+ZHEHlKzdp84W7tfuFIuw2XCM+3hUv6GFpQkkuRw4/jkzWyrPAQJZfLBqZq56Uz6 pgs5h5tRLjlFX/tn4NxDS7SNuqwhxKtwJ5+UpWV8B/L6aA45NtviUx23OJozToXaQibI tdFc/c1bqBmNv8B9sKjhsRsz13peJpSBig2jesvKTsiPTTXOdJRZjiqAq0iCp27F8p/V IkjX+oJdauZd14EVe4xD5YpQEGkWf9hQpRHVJT2WnNl73ErwURoTyvoRpax5ghWgCcDG 4vfw== MIME-Version: 1.0 X-Received: by 10.31.167.216 with SMTP id q207mr23017894vke.79.1450075222859; Sun, 13 Dec 2015 22:40:22 -0800 (PST) Received: by 10.31.47.137 with HTTP; Sun, 13 Dec 2015 22:40:22 -0800 (PST) Date: Sun, 13 Dec 2015 22:40:22 -0800 Message-ID: Subject: "libssl.so.8" not found From: Russell Haley To: freebsd-arm , freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 06:40:24 -0000 Hi There, I am trying to bring up an Arm image off the FreeBSD website for my hummingboard. The problem seems to be when I run pkg the system installs the latest version - 1.6.2, and then fails with: Shared object "libssl.so.8" not found, required by "pkg" I've seen this in NextBSD, and DesktopBSD and even on my previous arm image but I was able to get around the problem by creating links from libssl.so.7 to libssl.so.8. While this works for pkg, I then get curl errors from git: root@imx6:~ # git clone http://github.com/amix/vimrc.git ~/.vim_runtime Cloning into '/root/.vim_runtime'... /usr/local/lib/libcurl.so.4: Undefined symbol "SSL_CTX_set_alpn_protos" I'm just guessing, but the thought was this is an option missing in the libssl.so.7 binary? This is a bit of a show stopper for me because I wanted to build my project on the board itself. As usual, any input would be welcome as I don't know where to go from here. Thanks, Russ From owner-freebsd-arm@freebsd.org Mon Dec 14 07:18:49 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 55BACA42975; Mon, 14 Dec 2015 07:18:49 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE71131E; Mon, 14 Dec 2015 07:18:48 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [93.104.12.110] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1a8NPA-0005Dl-Qa; Mon, 14 Dec 2015 08:18:45 +0100 Received: from localhost.my.domain (c720-r285885-amd64 [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id tBE7Ifoo003791 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Dec 2015 08:18:42 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id tBE7IfVi003790; Mon, 14 Dec 2015 08:18:41 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Mon, 14 Dec 2015 08:18:40 +0100 From: Matthias Apitz To: Russell Haley Cc: freebsd-arm , freebsd-current@freebsd.org Subject: Re: "libssl.so.8" not found Message-ID: <20151214071840.GA3771@c720-r285885-amd64> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Russell Haley , freebsd-arm , freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 11.0-CURRENT r285885 (amd64) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 93.104.12.110 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: Mon, 14 Dec 2015 07:18:49 -0000 El día Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley escribió: > Hi There, > > I am trying to bring up an Arm image off the FreeBSD website for my > hummingboard. The problem seems to be when I run pkg the system installs > the latest version - 1.6.2, and then fails with: > > Shared object "libssl.so.8" not found, required by "pkg" > > I've seen this in NextBSD, and DesktopBSD and even on my previous arm image > but I was able to get around the problem by creating links from libssl.so.7 > to libssl.so.8. I have had the same issue on r285885 with ports as well from July this year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and now pkg complains about it database, but still works: $ pkg info pkg pkg: warning: database version 32 is newer than libpkg(3) version 31, but still compatible pkg-1.5.5 I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it should have been done more conservative, IMHO matthias -- Matthias Apitz, ✉ guru@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045 From owner-freebsd-arm@freebsd.org Mon Dec 14 07:36:05 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 7D0DDA43485 for ; Mon, 14 Dec 2015 07:36:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C2DE1F82 for ; Mon, 14 Dec 2015 07:36:05 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkgj66 with SMTP id j66so52211941vkg.1 for ; Sun, 13 Dec 2015 23:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BIi0O/6CtU0U2urr4y735EsRmS9eH6Wal+Xd59+IHOI=; b=X6k1aj0wDOztN2rVIHthg1nR83W5xGb+Gp0kn8rhoWNKtNi8OqN17RwBLelVNamd0I yiVdKwMAJOzjiYZXWPIOcXXrhQBugFswyygqXxn6bE3aosOE9vCCgGl6ky86u3YuTefU HD0HFS/nfIY5cBJ4vbKJda4BrwID7zLbGuBnBEoz4SIFylmiI5bIIGaVIuInpVOOajDR i331iIDPOUX/RMvDbD1I+uCECnG5iwzT61Yl75k32xo9djp1I3WHMr3zqiqGhneOn4uJ TatfbbspXXSFwMKNdbSs/SnSfN2NMxYdaRZee0suOXjqaMZFs16eb+zEdxgvmxqY4M7a nQ2Q== MIME-Version: 1.0 X-Received: by 10.31.5.132 with SMTP id 126mr24285742vkf.107.1450078564258; Sun, 13 Dec 2015 23:36:04 -0800 (PST) Received: by 10.31.47.137 with HTTP; Sun, 13 Dec 2015 23:36:04 -0800 (PST) In-Reply-To: References: <5666F37C.4060908@denninger.net> <20151208170304.4386897.13959.1326@gmail.com> Date: Sun, 13 Dec 2015 23:36:04 -0800 Message-ID: Subject: Re: Updating / keeping current strategies? From: Russell Haley To: Warner Losh Cc: Karl Denninger , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 07:36:05 -0000 With sata support soon available (https://reviews.freebsd.org/D4240 ?) is there any thought to look at ZFS on Arm? Russ On Tue, Dec 8, 2015 at 9:29 AM, Warner Losh wrote: > > > On Tue, Dec 8, 2015 at 10:03 AM, Russell Haley > wrote: > >> We do a ping pong at work for our embedded linux upgrades. It ensures >> that we can fall back to the original install if the update fails. However, >> we use a sata drive. Do you gave an documentation for this? >> > > It's a work in progress, but > https://www.freebsd.org/doc/en/articles/nanobsd/article.html has the > basics. > > Warner > > >> Thanks >> >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> Original Message >> From: Warner Losh >> Sent: Tuesday, December 8, 2015 7:55 AM >> To: Karl Denninger >> Cc: freebsd-arm@freebsd.org >> Subject: Re: Updating / keeping current strategies? >> >> On Tue, Dec 8, 2015 at 8: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've been updating for years. But usually building on another machine and >> then >> installing to the media of the embedded machine via NFS. This mostly works >> and isn't too sucky. But there are problems with this approach, since high >> write work loads tend to bog down the embedded box due to crappy storage >> being used (eg SD cards, USB attachment or both). >> >> You may have noticed some commits to nanobsd I've been making lately. >> I'm moving all my local boards over to nanobsd with a ping-pong partition. >> I'd create a new image for a new partition, splat it on to the 'pong' >> partition, >> adjust the active flags and reboot. NanoBSD has supported this operation >> for a while, and this works well in the hand-built images I've done. >> >> I'm polishing off the rough edges for this by making it possible to >> dynamically >> resize the first time. FreeBSD supports this for one partition today. But >> it >> doesn't provide a good way to do a divide by 2. The support in FreeBSD >> for writing MSDOS partitions as a regular user is also weak, so there's >> bits from mtools in my build. I've also not completely integrated the >> u-boot >> ports into the build. There's also an open question about the proper way >> to install packages on these boxes. One school of thought says that >> nanobsd >> should put the packages you want onto the image, and that's all you'll >> ever get. Another says that nanobsd should keep the database of packages >> off the ping or pong partitions so that when you upgrade, the packages >> are refreshed to the old set. There's other in-between positions I've >> heard >> articulated. >> >> So I can't help you today, but I'll be able to help you soon. >> >> Warner >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > From owner-freebsd-arm@freebsd.org Mon Dec 14 09:21:32 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 D2DBCA4214E; Mon, 14 Dec 2015 09:21:32 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6311445; Mon, 14 Dec 2015 09:21:32 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1a8PJs-0003KS-6z; Mon, 14 Dec 2015 10:21:29 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Russell Haley" , "Matthias Apitz" Cc: freebsd-arm , freebsd-current@freebsd.org Subject: Re: "libssl.so.8" not found References: <20151214071840.GA3771@c720-r285885-amd64> Date: Mon, 14 Dec 2015 10:21:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Scan-Signature: 98cd051f671ee36aeaf0d6c34a549736 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: Mon, 14 Dec 2015 09:21:32 -0000 On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop = wrote: > On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz = = > wrote: > >> El d=C3=ADa Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell= Haley = >> escribi=C3=B3: >> >>> Hi There, >>> >>> I am trying to bring up an Arm image off the FreeBSD website for my >>> hummingboard. The problem seems to be when I run pkg the system = >>> installs >>> the latest version - 1.6.2, and then fails with: >>> >>> Shared object "libssl.so.8" not found, required by "pkg" >>> >>> I've seen this in NextBSD, and DesktopBSD and even on my previous ar= m = >>> image >>> but I was able to get around the problem by creating links from = >>> libssl.so.7 >>> to libssl.so.8. >> >> I have had the same issue on r285885 with ports as well from July thi= s >> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could = not >> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and= = >> now pkg >> complains about it database, but still works: >> >> $ pkg info pkg >> pkg: warning: database version 32 is newer than libpkg(3) version 31,= = >> but still compatible >> pkg-1.5.5 >> >> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8;= it >> should have been done more conservative, IMHO >> >> matthias >> > > I had the same problem on my amd64 laptop. Your FreeBSD version is too= = > old. Upgrading the FreeBSD base will give you the new libssl version. = = > After that you can upgrade your packages. > > What version of FreeBSD is running on this hummingboard? I guess = > 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages = = > are build on this newer version. In 10-STABLE this is kept backwards = > compatible, but in 11-CURRENT you have to keep up yourself. > > Regards, > > Ronald. It has to do with this message in /usr/src/UPDATING: https://svnweb.freebsd.org/base/head/UPDATING?r1=3D290206&r2=3D290207&pa= threv=3D292177& From owner-freebsd-arm@freebsd.org Mon Dec 14 09:21:48 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 6FFD1A421DD; Mon, 14 Dec 2015 09:21:48 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39A3214DE; Mon, 14 Dec 2015 09:21:47 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1a8PAP-0005qm-Nq; Mon, 14 Dec 2015 10:11:43 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Russell Haley" , "Matthias Apitz" Cc: freebsd-arm , freebsd-current@freebsd.org Subject: Re: "libssl.so.8" not found References: <20151214071840.GA3771@c720-r285885-amd64> Date: Mon, 14 Dec 2015 10:11:35 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <20151214071840.GA3771@c720-r285885-amd64> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Scan-Signature: 18b3e585b0ef946fc0f6ee9ab4fcc4ff 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: Mon, 14 Dec 2015 09:21:48 -0000 On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz = wrote: > El d=C3=ADa Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell = Haley = > escribi=C3=B3: > >> Hi There, >> >> I am trying to bring up an Arm image off the FreeBSD website for my >> hummingboard. The problem seems to be when I run pkg the system insta= lls >> the latest version - 1.6.2, and then fails with: >> >> Shared object "libssl.so.8" not found, required by "pkg" >> >> I've seen this in NextBSD, and DesktopBSD and even on my previous arm= = >> image >> but I was able to get around the problem by creating links from = >> libssl.so.7 >> to libssl.so.8. > > I have had the same issue on r285885 with ports as well from July this= > year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could n= ot > find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and = = > now pkg > complains about it database, but still works: > > $ pkg info pkg > pkg: warning: database version 32 is newer than libpkg(3) version 31, = = > but still compatible > pkg-1.5.5 > > I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; = it > should have been done more conservative, IMHO > > matthias > I had the same problem on my amd64 laptop. Your FreeBSD version is too = old. Upgrading the FreeBSD base will give you the new libssl version. = After that you can upgrade your packages. What version of FreeBSD is running on this hummingboard? I guess = 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages ar= e = build on this newer version. In 10-STABLE this is kept backwards = compatible, but in 11-CURRENT you have to keep up yourself. Regards, Ronald. From owner-freebsd-arm@freebsd.org Mon Dec 14 12:26:26 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 5D834A41A07 for ; Mon, 14 Dec 2015 12:26:26 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F1011761; Mon, 14 Dec 2015 12:26:26 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by iofq126 with SMTP id q126so31570469iof.2; Mon, 14 Dec 2015 04:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B/uy9p/k/aFubrHIZ8mSHWb/NxafkmvAqGjYfA9KUPs=; b=JBayfw/uwmoJ2vuhAhLOQx4ZhJA0QnT2pLC2x7uJOCBQd3vgCZtx5w2bIA8jcCFmD+ irxJvYya+qUasNrKs8TEfrvUc9NkTZ5mDdA5F/AkuTh3ZOIwyAY2hB7WnpEPQQg8gCvt 8YbdHfZWuhnqVACGz7im13otslo0V9QxDJfShxqiXAkQl3MjhDaP0/XmzEk+Z599o3Bz EwE3JVtUS+Aq6dm467rEZnbC7Wz7bFNtGtdXadNS10us4co5v1iMLuEm23/Xr+Ganlx7 Ddmf2gdfqvB7SuARU+8j6gDpVJ+zS9V8MbPI3YvkU9sdwUmdvDe1z5v+vd75klSn4QaB HeQA== MIME-Version: 1.0 X-Received: by 10.107.162.68 with SMTP id l65mr27725972ioe.179.1450095985555; Mon, 14 Dec 2015 04:26:25 -0800 (PST) Received: by 10.107.51.213 with HTTP; Mon, 14 Dec 2015 04:26:25 -0800 (PST) In-Reply-To: <20151211150019.GA44341@ns.kevlo.org> References: <1449784832.417138.27650.30415@mail.rambler.ru> <20151211150019.GA44341@ns.kevlo.org> Date: Mon, 14 Dec 2015 20:26:25 +0800 Message-ID: Subject: Re: support Allwinner H3 From: RayCherng Yu To: Kevin Lo Cc: =?UTF-8?B?0KHQtdGA0LPQtdC5INCn0LLQtdGA0YLQvdGP0Lo=?= , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 12:26:26 -0000 I have one Orange Pi PC. Kevlo bought for me . We receive two Orange Pi PC board. They look the same but run different.... Kevlo use the official linux image and it runs well. My Orange Pi PC can't run the official linux image but my board runs the image that loboris built [1] very well. Kevlo's board can't run loboris's image~~ Who want to port FreeBSD to this kind of board? You don't know which board can run, which board can't. So our Orange Pi PC look the same but they are just similiar... I think I won't buy any product made by this company [1] http://www.orangepi.org/orangepibbsen/forum.php?mod=3Dviewthread&tid=3D= 342 2015-12-11 23:00 GMT+08:00 Kevin Lo : > On Fri, Dec 11, 2015 at 01:00:32AM +0300, =D0=A1=D0=B5=D1=80=D0=B3=D0=B5= =D0=B9 =D0=A7=D0=B2=D0=B5=D1=80=D1=82=D0=BD=D1=8F=D0=BA wrote: > > > > Please help. > > I do not understand how to create a boot exactly for Allwinner H3 (boar= d > OrangePi > > PC). > > There are practices in support of processors Allwinner H3? > > Thanks to Ganbold who added support for Allwinner A10/A20 SoCs, > porting to H3 is straightforward. I have a preliminary patch for this, > but I don't want to continue working on it. It seems there's a hardware > issue with Orange Pi PC [1]. I had a similar issue with my Orange Pi PC > when I used the images from Orange Pi download [2], it turned out that on= ly > Lubuntu image worked. > > [1] > http://www.cnx-software.com/2015/10/02/orange-pi-pc-not-booting-you-are-n= ot-alone/ > [2] http://www.orangepi.org/downloadresources/ > > > Thanks! > > > > Best regards, Sergey! > > Kevin > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. From owner-freebsd-arm@freebsd.org Mon Dec 14 13:03:27 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 33F5AA43C56 for ; Mon, 14 Dec 2015 13:03:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0FE5157F for ; Mon, 14 Dec 2015 13:03:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkht125 with SMTP id t125so132406146qkh.3 for ; Mon, 14 Dec 2015 05:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wTpCHrPKK/alGdk9Qi3AQ1RcIKXqW1gM7VLvvpOLFsE=; b=pHHjDHwzrIJrPnDKjWLUeV596LFT79TX5m3xtS4LiDyygGn1CxcuiZWgLldM6H8/OL fyUBeYimp35c1q0+ltCRi4hcrHuNq/q/MpnHWXbGr2QyBOzVrvy3Ofvk4lAzsxSTP1j3 /JEWiH+Icorn8XuMGNzlAMAn5snFljXc2nNskm0Rexl1EMYdt3iD5igisSHYa+pmNXi3 htacC9cQlaDQW7b5t7tu8m5z2zI1nvzkJoBnpej4y+e1U3EfsOYWChf6F1lcGdhPtD/L +KRVmNUtXSfcRi7953d3P2dn5Gx0E4lKFUEDioFjgepB+9mn2NEwuDToGSkvoTnSOWOI 24jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wTpCHrPKK/alGdk9Qi3AQ1RcIKXqW1gM7VLvvpOLFsE=; b=CNbbIs4o6lr/taJdxId078nYxLUbNqYarm1iuceYqhieJd1ZJ4wwiMkeAUTITHLfLp gALwkPXIiExkRqC3atEC7uTPQJ2eK1hQa9BSgjL7zTadgYd/Jfu3sDCg3JtqagRkyqWL 6oUIiomC0ECUSqN2X/E0KiLch5n8KDAPhIAjqRK7Lr6IVyGhODjjnEHiz8Sighx4BlNK 923OHvnTUpxo42/JeormJm3YrOBhXTOnWNub/uHgxyIUJcgfaUyO9KluEQaRSsfwM05H 8xYOgxyXJagVFJoS87AXHZXRmMqw0ujzSJsZ9YpZpYVnVDfb5G6/gpsLDOr6a38VoT4X lXTg== X-Gm-Message-State: ALoCoQlF6pDaSs+MsuCX5vAarlxJyBykBo5hm/TY7cqtDvVgZjm/68m/sKRWfMS3VzEZfJV+Swyo0MYwYJQZwLrsfVEUmClpLg== MIME-Version: 1.0 X-Received: by 10.55.80.68 with SMTP id e65mr43383589qkb.46.1450098205675; Mon, 14 Dec 2015 05:03:25 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Mon, 14 Dec 2015 05:03:25 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:4020:26e2:d346:a935] In-Reply-To: References: <20151214071840.GA3771@c720-r285885-amd64> Date: Mon, 14 Dec 2015 06:03:25 -0700 X-Google-Sender-Auth: gq4so3Hdnxc6PC1oPdKTGtWZhYk Message-ID: Subject: Re: "libssl.so.8" not found From: Warner Losh To: Ronald Klop Cc: Russell Haley , Matthias Apitz , freebsd-arm , FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 13:03:27 -0000 On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote: > On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop > wrote: > > On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz >> wrote: >> >> El d=C3=ADa Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Ha= ley >>> escribi=C3=B3: >>> >>> Hi There, >>>> >>>> I am trying to bring up an Arm image off the FreeBSD website for my >>>> hummingboard. The problem seems to be when I run pkg the system instal= ls >>>> the latest version - 1.6.2, and then fails with: >>>> >>>> Shared object "libssl.so.8" not found, required by "pkg" >>>> >>>> I've seen this in NextBSD, and DesktopBSD and even on my previous arm >>>> image >>>> but I was able to get around the problem by creating links from >>>> libssl.so.7 >>>> to libssl.so.8. >>>> >>> >>> I have had the same issue on r285885 with ports as well from July this >>> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could no= t >>> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and >>> now pkg >>> complains about it database, but still works: >>> >>> $ pkg info pkg >>> pkg: warning: database version 32 is newer than libpkg(3) version 31, >>> but still compatible >>> pkg-1.5.5 >>> >>> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; i= t >>> should have been done more conservative, IMHO >>> >>> matthias >>> >>> >> I had the same problem on my amd64 laptop. Your FreeBSD version is too >> old. Upgrading the FreeBSD base will give you the new libssl version. Af= ter >> that you can upgrade your packages. >> >> What version of FreeBSD is running on this hummingboard? I guess >> 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages ar= e >> build on this newer version. In 10-STABLE this is kept backwards >> compatible, but in 11-CURRENT you have to keep up yourself. >> >> Regards, >> >> Ronald. >> > > It has to do with this message in /usr/src/UPDATING: > > > https://svnweb.freebsd.org/base/head/UPDATING?r1=3D290206&r2=3D290207&pat= hrev=3D292177& As a temporary measure, for bootstrapping or installing packages, you can also use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library that you'll find you need to map too. This will get you over the hump. However, once you do upgrade, you'll need to remove the lines because slogin and suc= h have a check for the right version of openssl, and will give an error message if you try to use them cross-threaded. Warner From owner-freebsd-arm@freebsd.org Mon Dec 14 15:24:42 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 0CF1FA4440D for ; Mon, 14 Dec 2015 15:24:42 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 924651F20 for ; Mon, 14 Dec 2015 15:24:41 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by lbblt2 with SMTP id lt2so109151177lbb.3 for ; Mon, 14 Dec 2015 07:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OuZPpA5j42GDviqWIFdLYYE6lwCCThhoClHgB4FQZSU=; b=1VC9TH2ySes0cUbuL8UEM06jRtaZ03MZHmSwL0pmMBEJmWKGUZmOPGez7riI+nKsR7 s4cdnd4xktKAVTP3bZrszW0Z/TC12tZhBWPfcgcnKhpFChLGa01ADObg5jZ0Frr0rLIw w6rtDGQ1nnTPEm/KNLNxIc6+L0493TjPHMed9R8gvjYJXI49BgyZ/C+o7s18j/dRD1Bm HUwzgdfX1KWTJ4Qw15dfwy75ADq7Qq+ohsUUKATscEGTHTIQYtDQJLjKUZkt3HQ7qUsR JeU7tsRLfIpTKDjOgqtnxtL9bPQcHb5aMk8YkrlqJzIpEZfQd6qds9nj13KXLTBz2HB8 h+ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OuZPpA5j42GDviqWIFdLYYE6lwCCThhoClHgB4FQZSU=; b=P5ObL6piGv+yrpbZHdzl0W79oT2krObG4lB9OD+716CDrtmbiAE4ZH+vIiQpU5we16 Xghppiwe7kcK4coTJTs5C9t6ZPwkfZI6nKsztKYui1Mv/GQx7WFGPgRCcoVls4eTrjWQ /K62shmJVnDUKoQN4ZdKlrzbnutrfJpuezmK1VZ8h6ZhM+NkuZBF3FB8RMlZZZ1Yb4Dw QmpkS+F74b/qg9Iqbpy5m2qmzLG+lK/wD7bnzj94Nkm0il34z1j6lKO+7hoBC51Eqs9t i7hHvy09FT9lqYahz2rePLDfmhJVFqckFjgd+XzBmX1X+xPWK6okbuh6zZjPgDYg6ZAn hKhQ== X-Gm-Message-State: ALoCoQkAF2me3OamM6JBP2KdrNxmR1KW7rPPkhabO+W+hbFbNloPDopB7n/p/u4TUm5yDMALN7RjNsko+uqD9pf1lseK0h3lKw== X-Received: by 10.112.55.38 with SMTP id o6mr11019987lbp.38.1450106678439; Mon, 14 Dec 2015 07:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.139.194 with HTTP; Mon, 14 Dec 2015 07:24:18 -0800 (PST) In-Reply-To: References: From: Zbigniew Bodek Date: Mon, 14 Dec 2015 16:24:18 +0100 Message-ID: Subject: Re: Various panics while using HWPMC on ARM64 To: Ruslan Bukin Cc: Andrew Turner , "freebsd-arm@freebsd.org" , Ed Maste Content-Type: text/plain; charset=UTF-8 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: Mon, 14 Dec 2015 15:24:42 -0000 Hello, Did you have time to look into that? Do you have any clues what could be wrong here? We would like to use hwpmc for profiling so your help will be very much appreciated. Best regards zbb 2015-12-09 13:06 GMT+01:00 Zbigniew Bodek : > Hello Ed, > > Done. I also check what happens when SMP is disabled and the kassert > is triggered: > > root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc > ^Cpanic: [pmc,4256] cpu 0 didn't find a sample to collect > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffffff80004e9aac lr = 0xffffff800006d8b4 > sp = 0xffffff87cba976e0 fp = 0xffffff87cba97800 > > db_trace_self_wrapper() at vpanic+0x9c > pc = 0xffffff800006d8b4 lr = 0xffffff800027136c > sp = 0xffffff87cba97810 fp = 0xffffff87cba97880 > > vpanic() at kassert_panic+0x160 > pc = 0xffffff800027136c lr = 0xffffff80002712cc > sp = 0xffffff87cba97890 fp = 0xffffff87cba97950 > > kassert_panic() at pmc_capture_user_callchain+0x1a4 > pc = 0xffffff80002712cc lr = 0xffffff80000e1444 > sp = 0xffffff87cba97960 fp = 0xffffff87cba979c0 > > pmc_capture_user_callchain() at pmc_hook_handler+0x7c0 > pc = 0xffffff80000e1444 lr = 0xffffff80000dfb78 > sp = 0xffffff87cba979d0 fp = 0xffffff87cba97a50 > > pmc_hook_handler() at ast+0x14c > pc = 0xffffff80000dfb78 lr = 0xffffff80002b976c > sp = 0xffffff87cba97a60 fp = 0xffffff87cba97a90 > > ast() at handle_el0_sync+0x90 > pc = 0xffffff80002b976c lr = 0xffffff80004eb224 > sp = 0xffffff87cba97aa0 fp = 0xffffff87cba97bb0 > > handle_el0_sync() at 0x406d60 > pc = 0xffffff80004eb224 lr = 0x0000000000406d60 > sp = 0xffffff87cba97bc0 fp = 0x0000007ffffff540 > > KDB: enter: panic > [ thread pid 679 tid 100061 ] > Stopped at kdb_enter+0x40: > db> > > > when invariants options is disabled I only get: > > root@thunderx_crb4:~ # pmcstat -S CPU_CYCLES -O cpu_cycles.pmc > ^Cpmcstat: WARNING: sampling was paused at least 1 time. > Please consider tuning the "kern.hwpmc.nsamples" tunable. > > > Best regards > zbb > > 2015-12-08 20:59 GMT+01:00 Ed Maste : >> On 8 December 2015 at 14:34, Zbigniew Bodek wrote: >>> Hello, >>> >>> I encountered some problems with FreeBSD on ARM64 while using hwpmc. >>> Some of the errors that I found are listed below: >>> >>> * panic: Unknown kernel exception 0 esr_el1 2000000 >>> * panic: data abort in critical section or under mutex >>> * panic: VFP exception in the kernel >>> * panic: Unknown kernel exception 21 esr_el1 86000006 >> >> Can you add these notes to PR 204686? I think there are SMP issues in >> arm64 hwpmc that need to be resolved. From owner-freebsd-arm@freebsd.org Mon Dec 14 15:32:20 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 AF631A44A24 for ; Mon, 14 Dec 2015 15:32:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 9261C1513 for ; Mon, 14 Dec 2015 15:32:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 14 Dec 2015 15:32:11 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBEFWCaX018570; Mon, 14 Dec 2015 08:32:12 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450107132.25138.11.camel@freebsd.org> Subject: Re: Updating / keeping current strategies? From: Ian Lepore To: Russell Haley , Warner Losh Cc: "freebsd-arm@freebsd.org" Date: Mon, 14 Dec 2015 08:32:12 -0700 In-Reply-To: References: <5666F37C.4060908@denninger.net> <20151208170304.4386897.13959.1326@gmail.com> 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: Mon, 14 Dec 2015 15:32:20 -0000 On Sun, 2015-12-13 at 23:36 -0800, Russell Haley wrote: > With sata support soon available (https://reviews.freebsd.org/D4240 ? > ) is > there any thought to look at ZFS on Arm? > > Russ ZFS has been reported in the past to work fine on arm. Someone even ran it on a beaglebone (I can't imagine it worked very well on a 512mb system, but it worked). -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 14 15:45:00 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 C5C39A47E11; Mon, 14 Dec 2015 15:45:00 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B00621D00; Mon, 14 Dec 2015 15:45:00 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id B6F701F511; Mon, 14 Dec 2015 15:35:17 +0000 (UTC) Date: Mon, 14 Dec 2015 15:35:17 +0000 From: Brad Davis To: Warner Losh Cc: Ronald Klop , freebsd-arm , Matthias Apitz , FreeBSD Current Subject: Re: "libssl.so.8" not found Message-ID: <20151214153517.GB49345@corpmail.liquidneon.com> References: <20151214071840.GA3771@c720-r285885-amd64> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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: Mon, 14 Dec 2015 15:45:01 -0000 On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote: > On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote: > > > On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop > > wrote: > > > > On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz > >> wrote: > >> > >> El d??a Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley > >>> escribi??: > >>> > >>> Hi There, > >>>> > >>>> I am trying to bring up an Arm image off the FreeBSD website for my > >>>> hummingboard. The problem seems to be when I run pkg the system installs > >>>> the latest version - 1.6.2, and then fails with: > >>>> > >>>> Shared object "libssl.so.8" not found, required by "pkg" > >>>> > >>>> I've seen this in NextBSD, and DesktopBSD and even on my previous arm > >>>> image > >>>> but I was able to get around the problem by creating links from > >>>> libssl.so.7 > >>>> to libssl.so.8. > >>>> > >>> > >>> I have had the same issue on r285885 with ports as well from July this > >>> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not > >>> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and > >>> now pkg > >>> complains about it database, but still works: > >>> > >>> $ pkg info pkg > >>> pkg: warning: database version 32 is newer than libpkg(3) version 31, > >>> but still compatible > >>> pkg-1.5.5 > >>> > >>> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it > >>> should have been done more conservative, IMHO > >>> > >>> matthias > >>> > >>> > >> I had the same problem on my amd64 laptop. Your FreeBSD version is too > >> old. Upgrading the FreeBSD base will give you the new libssl version. After > >> that you can upgrade your packages. > >> > >> What version of FreeBSD is running on this hummingboard? I guess > >> 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages are > >> build on this newer version. In 10-STABLE this is kept backwards > >> compatible, but in 11-CURRENT you have to keep up yourself. > >> > >> Regards, > >> > >> Ronald. > >> > > > > It has to do with this message in /usr/src/UPDATING: > > > > > > https://svnweb.freebsd.org/base/head/UPDATING?r1=290206&r2=290207&pathrev=292177& > > > As a temporary measure, for bootstrapping or installing packages, you can > also > use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library > that > you'll find you need to map too. This will get you over the hump. However, > once you do upgrade, you'll need to remove the lines because slogin and such > have a check for the right version of openssl, and will give an error > message if > you try to use them cross-threaded. Or just use pkg-static. :) Regards, Brad Davis From owner-freebsd-arm@freebsd.org Mon Dec 14 16:14:46 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 3D695A44365 for ; Mon, 14 Dec 2015 16:14:46 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 D48D71055 for ; Mon, 14 Dec 2015 16:14:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 8F1AC235BD1 for ; Mon, 14 Dec 2015 10:14:37 -0600 (CST) Subject: Re: Updating / keeping current strategies? References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> To: "freebsd-arm@freebsd.org" From: Karl Denninger X-Enigmail-Draft-Status: N1110 Message-ID: <566EEAC4.1060306@denninger.net> Date: Mon, 14 Dec 2015 10:13:56 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070205010407040004060407" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 16:14:46 -0000 This is a cryptographically signed message in MIME format. --------------ms070205010407040004060407 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 P= i2? >> >> 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 ho= urs. >> >> I'm wondering what the best option is to not only build current code o= n >> 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 abo= ut 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 cros= s-install kernel and world onto the SD card and then run mergemaster agai= nst it. I use the wrapper script from https://wiki.freebsd.org/FreeBSD/a= rm/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 P= i. > > This has proved a reliable way for me to update my Raspberry Pi and Bea= gleBone Black. The manual step of moving the SD card isn't ideal, but ha= s proved to be the most pragmatic approach for me. (Clang seems more rel= iable on FreeBSD/amd64, for one.:) Someone suggested once to do the cros= s 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. Similarl= y, 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.=20 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.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070205010407040004060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTQxNjEzNTZaME8GCSqGSIb3DQEJBDFCBEDF DPjsJ7PF0waaB4UYsMRElljp/89XEYJvdkCUwTlOU0Xq5gjnb+s0M3JCWLIeKrixX0Sy2KMq NIF045s/Ah+SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAG05Cr46T WWgrQVLy02vgY3k8DHPMNDWGe9F6C1MHX0IZjAV0tDTUFr3ZELZjh3Ei/NElyRLc323P0pNV IjtEAqx8/kg/LYQEZwj47BgY6gLB2oUkOxA986S/SBRBi7PM47UdfDy6OsOiYqXbffUts1S2 plt2OtlJ5672cWi79hbuJa4Ue3BmqL1RzS2XQqbaBZ5x9FsGqUfyd3O2ExB6QZcFFjmmV/Qw 6gV20Jvl7lr71DDFGTQlgEEtSxB+JudIese86fp6UeKkjy/D2wgjkBhhkQivGmVJ8xaFQElA bAJzdT8pc+Niqt5DjBBNAZXY9bjP0tmugKchORQ25/yp29m9d9SRylKBs+nTJnm3nhfgANLM wEf7ePlAhWDlxHOkcIDmOJp/yVfBNmuhLO+a/gUJCaLBKOYztqbpfEOGkoxbwb7qk65iMvmc 8aU3SPwNUqmzPbpYLLU4bXb5Va015pAXemV7Dn9yME3XMGeygNJjTW5sBytTTALvaAu8HZQt batbm9KP9zL8sVrAvTEH65ziO6tnfCFLJ+MjrIsIQevGdMrEHd+bKg1d5lhOy2O7zHVD2/l3 me5CAzf16frT2kPH7q60KzOsNC3t5ZLbq3hZU49QIW+aEaMmpLRt+PYyTVTNY08Lu2tEfxsK Ki37etuE6x5Pq9SAoDyUkcowcswAAAAAAAA= --------------ms070205010407040004060407-- From owner-freebsd-arm@freebsd.org Mon Dec 14 17:54:45 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 175F7A43B4F for ; Mon, 14 Dec 2015 17:54:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 D26EB15E9 for ; Mon, 14 Dec 2015 17:54:44 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 158D3236145 for ; Mon, 14 Dec 2015 11:54:42 -0600 (CST) Subject: Re: Updating / keeping current strategies? To: freebsd-arm@freebsd.org References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> <566EEAC4.1060306@denninger.net> From: Karl Denninger Message-ID: <566F0238.9060605@denninger.net> Date: Mon, 14 Dec 2015 11:54:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <566EEAC4.1060306@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020008040206050101080604" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 17:54:45 -0000 This is a cryptographically signed message in MIME format. --------------ms020008040206050101080604 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 o= f >>> 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 h= ours. >>> >>> 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 ab= out 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 car= d from it to the FreeBSD/amd64 system. Having mounted the SD card, I cro= ss-install kernel and world onto the SD card and then run mergemaster aga= inst 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 Be= agleBone Black. The manual step of moving the SD card isn't ideal, but h= as proved to be the most pragmatic approach for me. (Clang seems more re= liable on FreeBSD/amd64, for one.:) Someone suggested once to do the cro= ss build/install on the FreeBSD/amd64 system and then rsync over to the P= i/BBB to update the SD card, but I could never get that to work. Similar= ly, 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. 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. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020008040206050101080604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTQxNzU0MDBaME8GCSqGSIb3DQEJBDFCBEB8 Z8s7KItTRZkYa7rSf+S58QDb8l4FSwg2h9y3E3P79j7H5JBUi84Ua116bKXIObW/sJLMLw1E Iwov7lnjmC1AMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIALxIZrCtq h0RISzK2PBaWjAxpZJXCUH4uqffrRQJ2fPKM7IcQcbNbxtC8EYY32AA+yvjEMi18iGEpzwo6 qaZKd3XUfX4vmaazQkW0IgKmNVGzuZpLjuY6PKWcze0b4gXRIG8iRJi/5+1VgTE/X6btm/AZ sfzLQtfqXC30XDOfWJjCBFFj9p3dtsj13koP/Wt9YISY61XnqHINhrACInANWaFNdjQH7E0p ed9H0JvPmGeJXunYvShu2FSUWu/+m9duWbpYtquLm69C57P2l5hiqkXACOZvC2Vxr41VQoNY aegiMXWft9tyn2vUfvLf8w4T9UXk8UMUG1XeUdqlq0uU+Mb1HxhJfK3hHmeETVeWBrOf8N1S xBaXMxPjOdRkyUgH4GSRYe9OJre0X8EZkchAFZRu2x0RfAVglO/H6xw2ilv/S671EDR69VEk hcy3RIn1xywc123r3m8RBK+/W68tZFyYyyTaxvbGNg42yUWep/By9EmNgDiJprZ01ffDIPfw s3d/BDrPuu4dxIJe6gpepx/P1w9kbU8kmVZCi3B2rqlvrEUhqHe1JsBEKaSiBtNooanUlCZD 8R74wMaEpQy2sSfh0RiYEgCAKQuJ/UD6t/JCnAe8WJI/buIqJooegPBfNt3TiJt4fQg1fWRm hdDb2eLVW2k4MUueDkaEDp2jrhcAAAAAAAA= --------------ms020008040206050101080604-- From owner-freebsd-arm@freebsd.org Mon Dec 14 18:39:27 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 08185A439DC for ; Mon, 14 Dec 2015 18:39:27 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 C3CC91A79 for ; Mon, 14 Dec 2015 18:39:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 74265236324 for ; Mon, 14 Dec 2015 12:39:24 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Reason for this limitation? Message-ID: <566F0CB2.8000201@denninger.net> Date: Mon, 14 Dec 2015 12:38:42 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040400090704060005020302" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Mon, 14 Dec 2015 18:39:27 -0000 This is a cryptographically signed message in MIME format. --------------ms040400090704060005020302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In the current RPI2 images the filesystem definitions used to include: md /tmp mfs rw,noatime,-s30m 0 0 Now its: tmpfs /tmp tmpfs rw,mode=3D1777,size=3D30m 0 0 Why the limitation, and why set so small on a 1Gb RAM system? The former limit was rational because the allocation was fixed on boot, but tmpfs is dynamic. Is this a historical accident or is there a logical point in that sort of restrictive limit? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040400090704060005020302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTQxODM4NDJaME8GCSqGSIb3DQEJBDFCBECZ AfSm4xEy+k9YzJXbmHswIh/pCIJheIQkKOYgYWA6ALsWWWOTKT7vYhqibd9RgTBIyMWpC1jt wJoWanHXowRpMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAPAZPOxsq 0FtWxNwz6Ks+R4T1rVwwumu1NDCrfEUD4pQrrh+YG1cUMHp5JGP5tz4qPJHFKtiVEAszCoDz yrw9HGtaIGerdaDGa2wSu2nzqYrMxXgCYoryThAwMddzxGtcD92QbvOCdDRPl1YlLz5P4G2y BHrQpnC3H+cV1CuACIsEqryHDwrTbUXyvRP2PfjHsDMb/s4Ub0PrsbuCH5KDpWDPYLoT5QGs qedoENJlycqBYJe01nQiWXzQOinB+zxmkBaG1vswpGupHAWsGnoQL3UNpnjSUtOiBA2uSGHb nARwz6cKjsabL5j+AKr5wrDGkefVoHe9fO1b7U2u5OOFaf0s5r8LfDlKPbfamzIzUu892Dh3 HNeMtwYL2KqhVozK0jhDNABoJ0yuHZsSsHErO0d9gnzWI5GKegG5f7+4jyxLgE9RKGMXqIDX i1282N43S91ivQwr3SOcQYMIGJQzPHUARLvLKhupu6o6jx5LWskh5rDuyOMQ77RiFmOIci+w KjskzwGpPf0W/8jQwQPTDEEGgGw38xTHgBKQyd8vyKh2e4m0PSM2qFXGUyLxtLjJTpWIwe2i uoDodAauZbDwQUjF2HaJOix2aLQNsNHQ3OAIVLK9ULrb+NGkUcF5Is4CjaghzB0HIHRepGOF VTq7xSPsYE8Ary758WEZm+Ovq1kAAAAAAAA= --------------ms040400090704060005020302-- From owner-freebsd-arm@freebsd.org Mon Dec 14 21:02:19 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 2876DA44E33 for ; Mon, 14 Dec 2015 21:02:19 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 A32F61006 for ; Mon, 14 Dec 2015 21:02:18 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id tBEL2Fto060888 for ; Mon, 14 Dec 2015 22:02:15 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 14 Dec 2015 22:02:14 +0100 (CET) Message-ID: <4762fd582e7.3808a64f@mail.schwarzes.net> In-Reply-To: <566F0CB2.8000201@denninger.net> References: <566F0CB2.8000201@denninger.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Reason for this limitation? MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 14 Dec 2015 22:02:15 +0100 (CET) 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: Mon, 14 Dec 2015 21:02:19 -0000 On 14.12.15, Karl Denninger wrote: > Is this a historical accident or is there a logical point in that sort > of restrictive limit? Don't know. I'm using tmpfs without any memory limitation since years. No problems so far. root@pizelot:~ # grep tmpfs /etc/fstab tmpfs /tmp tmpfs rw,mode=1777 2 0 tmpfs /var/tmp tmpfs rw 2 0 -asc From owner-freebsd-arm@freebsd.org Tue Dec 15 06:03:24 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 6AA3EA47991 for ; Tue, 15 Dec 2015 06:03:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C97F10CB for ; Tue, 15 Dec 2015 06:03:24 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkha189 with SMTP id a189so168846471vkh.2 for ; Mon, 14 Dec 2015 22:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zr3VWtFsxv8cJZFl8UgZcVj0mTt/YnEoWZMsWHWoxMU=; b=MAh5hV4RTpo+/ipHj5vIOdafUCqB4rHGSIQDcDeFXjehYd7VyC3Gwrt3RfDVFd9lHt 9opsupGjDmEBuIukhl7mm/o1gjKAxtXl0XalAWlO7cFH8Wt8krKPPuqiS+a4Sf476tLh PwadjCQN53RVAP5AeW2pxKUcnOeDQUgrpo+91WQZXi2b3f6fk8q7fKTTP1dmJGIRi3uj OpzURRIAuvuzGkcbKs00XbaDZtipCyD+GByP5Lu07LW0dw4wVCHnaxLkHkKXwg0KYN3J MaLupnxx9n7tP+EJy2IwajszusJTHMISmCbXIONrcSjycfzb4WNPZ+u+Xty+xUanqWqC dMrQ== MIME-Version: 1.0 X-Received: by 10.31.134.3 with SMTP id i3mr28917499vkd.14.1450159402753; Mon, 14 Dec 2015 22:03:22 -0800 (PST) Received: by 10.31.47.137 with HTTP; Mon, 14 Dec 2015 22:03:22 -0800 (PST) Date: Mon, 14 Dec 2015 22:03:22 -0800 Message-ID: Subject: Sata Support on Hummingboard From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 06:03:24 -0000 Hey, I've got the latest kernel with the changes to ahci.c, but I'm still not seeing my ssd. I noticed the file imx6q.dtsi had the sata status as disabled, so I changed that to enabled (?) and rebuilt the kernel again but it didn't make any difference. This is all I'm seeing: root@defcon3:~# ofwdump -p /soc/sata Node 0x64a4: sata@02200000 compatible: 66 73 6c 2c 69 6d 78 36 71 2d 61 68 63 69 00 'fsl,imx6q-ahci' reg: 02 20 00 00 00 00 40 00 interrupts: 00 00 00 00 00 00 00 27 00 00 00 04 clocks: 00 00 00 02 00 00 00 9a 00 00 00 02 00 00 00 bb 00 00 00 02 00 00 00 69 clock-names: 73 61 74 61 00 73 61 74 61 5f 72 65 66 00 61 68 62 00 status: 6f 6b 61 79 00 'okay' fsl,transmit-level-mV: 00 00 04 01 fsl,transmit-boost-mdB: 00 00 0d 02 fsl,transmit-atten-16ths: 00 00 00 09 fsl,receive-eq-mdB: 00 00 0b b8 And nothing in the boot output about ahci or sata on simplebus or anything. The values in the device tree file imx6q.dtsi are the same as the ones in the Linux tree in the current kernel too. Any thoughts? Thanks, Russ 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. > From owner-freebsd-arm@freebsd.org Tue Dec 15 15:29:58 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 8A126A43E77 for ; Tue, 15 Dec 2015 15:29:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 3CC15114C for ; Tue, 15 Dec 2015 15:29:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id DC9DE236CE3 for ; Tue, 15 Dec 2015 09:29:56 -0600 (CST) Subject: Re: Updating / keeping current strategies? 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> To: "freebsd-arm@freebsd.org" From: Karl Denninger X-Enigmail-Draft-Status: N1110 Message-ID: <567031C9.2090109@denninger.net> Date: Tue, 15 Dec 2015 09:29:13 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1450190791.25138.30.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070903070802050207080900" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 15:29:58 -0000 This is a cryptographically signed message in MIME format. --------------ms070903070802050207080900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 >>>> 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.=20 >>>> 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=20 >>>> 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.:)=20 >>>> 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.=20 >>> 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=20 jitter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 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 =20 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. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070903070802050207080900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUxNTI5MTNaME8GCSqGSIb3DQEJBDFCBED6 4XWi0rsoy+BviTecqpyeffA9MLxvZYq2sXvxR49+2qxx/PE5CK4unCB34WrkNF6SaNa8b+VB gdfgZm3RFFTjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAZIkGgjVe lHDafyR3S8CuSux1JWeqMU3gKIRbV3xqfU68t9GYuhDuqfdkcvvLjDZ+x0jOUaVQS3ZJxkM1 DZDwBCLKLA32UBQ1Ay7VdDsDNSq5JQd3yu+w+IPqTdxL/TwP1x1UiqJjy/Y0OxadtKtt4bwt Aaq3f+liY5ecNkHJNw0dQatxmmF9KF46vtkQ3Xzil7d+iLPhVlSpMjzNKDrD+ihnMGKU39G4 9MzwNvAaKJ67W87NIkwus5JGfYENa33/UgBf8OvT3H5/AzZgDqUu9CYInBsP3NmM94QMej8n 0o5rIC1/CfaJ7Cq9fBBQGvI7AJJOhhx/tB0zpCs+hSNEF10disOTqa14efU2DWlZxWOgB5X0 ZpkOTYAEb3wZjKhN9uqqdMMiqQ9lq8IeMQ3RyJ83bbbYQVjai1sR0gxpwFA4C+IDaYcHRiKN HVm+xB4yKXSTqoFBvT5CiYL6JUxRQGfyfrVNUE0qPDxYvo1sTrhPOWvInh1g8BGTNpI39SGi L5GBMAH4WDcxdkrUAnhouSR13MU55VFBKjkzWqQP5wmT3RiE9QKI8HVfkRipNdF2ZjCP9yYY 3Tz01MV5M51Q7bvS+zG4CLyqCkgIFxN4kPPuudeg8367To5vHAsNVUYBD7oPF91YcMhT6fsj DNmkgsAowPnVNJQWhivPlY4wOBgAAAAAAAA= --------------ms070903070802050207080900-- From owner-freebsd-arm@freebsd.org Tue Dec 15 15:58:51 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 99D7CA4805F for ; Tue, 15 Dec 2015 15:58:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 8123219D5 for ; Tue, 15 Dec 2015 15:58:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 15:58:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFFwhKR020901; Tue, 15 Dec 2015 08:58:43 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450195123.25138.42.camel@freebsd.org> Subject: Re: Updating / keeping current strategies? From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Tue, 15 Dec 2015 08:58:43 -0700 In-Reply-To: <567031C9.2090109@denninger.net> 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> <567031C9.2090109@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 15:58:51 -0000 On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote: > 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. > Oh, you can't do that. The pathnames in the obj directory are correct for the build machine, but wrong when nfs-mounted on another machine. The instructions in the wiki page you cited are how to set up a development environment that uses an nfs-mounted root directory. You can also use it as a source for rsync, but you can't install directly from the objdir of such a build environment using an nfs mount unless the target system has the exact directory layout of the build system after nfs-mounting the source and obj dirs. Another way to make it work is to nfs-mount the target's root directory on your build machine, then you can make installworld DESTDIR= > 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. > Using a kernel and world built yesterday for armv6hf... root@wand :~ # awk "BEGIN {print 2.7+4.2 }" 6.9 I do all my building on a 10-stable machine. I wonder if your first attempt to installworld somehow installed some x86 stuff by accident and now you've got a mixed/broken world, and rsyn c didn't fix it because some of the broken files were more recent? -- Ian [ntpd stuff snipped] From owner-freebsd-arm@freebsd.org Tue Dec 15 16:22:56 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 E4FCDA43065 for ; Tue, 15 Dec 2015 16:22:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 996AF1D2D for ; Tue, 15 Dec 2015 16:22:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3DBBF235E2C for ; Tue, 15 Dec 2015 10:22:48 -0600 (CST) Subject: Re: Updating / keeping current strategies? To: "freebsd-arm@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> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> From: Karl Denninger X-Enigmail-Draft-Status: N1110 Message-ID: <56703E2D.8050504@denninger.net> Date: Tue, 15 Dec 2015 10:22:05 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1450195123.25138.42.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040102000306060807030605" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 16:22:57 -0000 This is a cryptographically signed message in MIME format. --------------ms040102000306060807030605 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/15/2015 09:58, Ian Lepore wrote: > On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote: >> On 12/15/2015 08:46, Ian Lepore wrote: >>>>> 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.=20 >>>>> 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. >> > Oh, you can't do that. The pathnames in the obj directory are correct > for the build machine, but wrong when nfs-mounted on another machine. Well, but they are if I maintain the paths. Example: I have the build at /pics/CrossBuild on the source (10.2-STABLE amd64) machine. I export /pics/CrossBuild. I then mount that at /pics/CrossBuild on the target. Now the paths are the same. But..... when I try to do a "make installkernel" as you would do if doing this on a consistent architecture what I get is this: root@Pool-MCP:/pics/CrossBuild # ./mk installkernel TARGET_ARCH=3Darmv6hf= + cd /pics/CrossBuild/src + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=3Darmv6hf' 'DESTDIR=3D/pics/CrossBuild/nfsroot' '__MAKE_CONF=3D/pics/CrossBuild/config/make.conf' 'srcconf=3D/pics/CrossBuild/config/src.conf' 'KERNCONF=3DRPI2' 'UBLDR_LOADADDR=3D0x2000000' installkernel 'TARGET_ARCH=3Darmv6hf' --- installkernel --- --- installkernel --- -------------------------------------------------------------- >>> Installing kernel RPI2 -------------------------------------------------------------- cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2;=20 MAKEOBJDIRPREFIX=3D/pics/CrossBuild/obj/arm.armv6hf MACHINE_ARCH=3Darmv6= hf=20 MACHINE=3Darm CPUTYPE=3D GROFF_BIN_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp= /legacy/usr/bin=20 GROFF_FONT_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tm= p/legacy/usr/share/groff_font=20 GROFF_TMAC_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tm= p/legacy/usr/share/tmac CC=3D"cc " CXX=3D"c++ " DEPFLAGS=3D"" CPP=3D"cpp " AS=3D"as" AR=3D"ar= " LD=3D"ld" NM=3Dnm OBJDUMP=3Dobjdump OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D= =20 SIZE=3D"size" PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/us= r/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/us= r/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/bin= :/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/sbin:/pics/= CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/bin:/sbin:/bin:/us= r/sbin:/usr/bin=20 make KERNEL=3Dkernel install sh: cc: Exec format error make[2]: "/pics/CrossBuild/src/share/mk/bsd.compiler.mk" line 137: Unable to determine compiler type for cc . Consider setting COMPILER_TYP= E. *** [installkernel] Error code 1 make[1]: stopped in /pics/CrossBuild/src 1 error make[1]: stopped in /pics/CrossBuild/src *** [installkernel] Error code 2 make: stopped in /pics/CrossBuild/src 1 error make: stopped in /pics/CrossBuild/src root@Pool-MCP:/pics/CrossBuild # When investigating this what I find is that the executable in the path for "cc" is in fact an arm64 executable! So I have a built system but no way to install it. > > The instructions in the wiki page you cited are how to set up a > development environment that uses an nfs-mounted root directory. You > can also use it as a source for rsync, but you can't install directly > from the objdir of such a build environment using an nfs mount unless > the target system has the exact directory layout of the build system > after nfs-mounting the source and obj dirs. Except that doesn't work because the PATH contains executables for the source which is a different architecture. And when I tried to rsync it I got a system that booted and ran, sort of, but anything that did floating point blew up. That might be because of schg flags prevented some of the copies and rsync has no good way to get around that (removing them from the target is undesirable for all the obvious reasons.) > > Another way to make it work is to nfs-mount the target's root directory= > on your build machine, then you can make installworld DESTDIR=3D That's an interesting idea that I will look into. It's undesirable for a number of reasons down the road (enabling nfs server on these machines isn't my idea of a good thing over time) but it might get me going for the moment. >> 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. > Using a kernel and world built yesterday for armv6hf... > > root@wand :~ # awk "BEGIN {print 2.7+4.2 }" > 6.9 > > I do all my building on a 10-stable machine. > > I wonder if your first attempt to installworld somehow installed some > x86 stuff by accident and now you've got a mixed/broken world, and rsyn= > c didn't fix it because some of the broken files were more recent? > > -- Ian Maybe. But I don't think so; I suspect the issue revolves around schg flags (in other words some things didn't update) and if so it's a problem since I don't believe rsync can deal with that. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040102000306060807030605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUxNjIyMDVaME8GCSqGSIb3DQEJBDFCBEBo hDmCaE3XP5zzpRiI9sx9BF2ldKgseB3HIYtb4jEEoc4zFjvZhVpnGsiO9CsFvX9kQ+ljfkRs CloOCj4U8R+/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAg4/1Rj1Q Ln42M5xrax6SjTnTUvLdjJIcnYRQTcqCFhcQ0sWtfZxln6AsQ1GSTixHE5Ha1I9dgu45Wtam VbysQOnBZPqiX3r7TnLlPNEvxM58rG515ITXEZQWyCbltn7+kJUXmO2IsHvPl/CB2qsCV4b9 EQSCmUyHsXxcvts1CliT4Zi/kivZBt9+crqrpeJHpUm3LsYCFBk03dUlV0bwyTzfUTxC2WGE /CvsTUae7H7cfC7G5JSvDmwOOTkDVmU9ZhHM3rh/XXzdZiF3k8B+XK0OiP/ElnWdXc+GCW4P lH5EAGnBE6GW5LlYMwUEqr8WVCD1igu6oKUoku0NjvSob/hHMAKFqon56R/QmQqoGjfzAbF/ TgotuamVRog90sd6o97AeIAE6TurYwtTswaF60cH76k7xutd0/wjVOZd+T4HMUBynObQ0SX3 1YW1Bzy+kSPUkv05n16/+z0uE5IUaySlr23FoiosCG5FeWFZIXGDKP80bl08QcpvSukrcrah d+oaGVX7YPvE6iS4Cf4yhAzkW1unD3Ji2nIfBnLGtXMy+sl9V6eBV3DosoP3gN5k58Ed4Gl+ lx+fjB4oVhXHYLzOd0WRtDkDhPfHXDzejZYBz26WDhYley7fpVB4lEwDfLphG5DfKarvRBlY oAcVK0GMTp8nkHTwvghIK0kYqbsAAAAAAAA= --------------ms040102000306060807030605-- From owner-freebsd-arm@freebsd.org Tue Dec 15 17:02:38 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 8CA24A48B62 for ; Tue, 15 Dec 2015 17:02:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 73C0615BF for ; Tue, 15 Dec 2015 17:02:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 17:02:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFH2UOP021112; Tue, 15 Dec 2015 10:02:30 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450198950.25138.50.camel@freebsd.org> Subject: Re: Updating / keeping current strategies? From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Tue, 15 Dec 2015 10:02:30 -0700 In-Reply-To: <56703E2D.8050504@denninger.net> 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> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> <56703E2D.8050504@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 17:02:38 -0000 On Tue, 2015-12-15 at 10:22 -0600, Karl Denninger wrote: > On 12/15/2015 09:58, Ian Lepore wrote: > > On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote: > > > On 12/15/2015 08:46, Ian Lepore wrote: > > > > > > 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. > > > > > Oh, you can't do that. The pathnames in the obj directory are > > correct > > for the build machine, but wrong when nfs-mounted on another > > machine. > Well, but they are if I maintain the paths. > > Example: I have the build at /pics/CrossBuild on the source (10.2 > -STABLE > amd64) machine. > I export /pics/CrossBuild. > > I then mount that at /pics/CrossBuild on the target. Now the paths > are > the same. > > But..... when I try to do a "make installkernel" as you would do if > doing this on a consistent architecture what I get is this: > > root@Pool-MCP:/pics/CrossBuild # ./mk installkernel > TARGET_ARCH=armv6hf > + cd /pics/CrossBuild/src > + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=armv6hf' > 'DESTDIR=/pics/CrossBuild/nfsroot' > '__MAKE_CONF=/pics/CrossBuild/config/make.conf' > 'srcconf=/pics/CrossBuild/config/src.conf' 'KERNCONF=RPI2' > 'UBLDR_LOADADDR=0x2000000' installkernel 'TARGET_ARCH=armv6hf' > --- installkernel --- > --- installkernel --- > -------------------------------------------------------------- > > > > Installing kernel RPI2 > -------------------------------------------------------------- > cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2; > MAKEOBJDIRPREFIX=/pics/CrossBuild/obj/arm.armv6hf > MACHINE_ARCH=armv6hf > MACHINE=arm CPUTYPE= > GROFF_BIN_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/t > mp/legacy/usr/bin > GROFF_FONT_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/ > tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/ > tmp/legacy/usr/share/tmac > CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp " AS="as" AR="ar" > LD="ld" > NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= > SIZE="size" > PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/ > usr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/leg > acy/usr/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/ > legacy/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/u > sr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/ > bin:/sbin:/bin:/usr/sbin:/usr/bin > make KERNEL=kernel install > sh: cc: Exec format error > make[2]: "/pics/CrossBuild/src/share/mk/bsd.compiler.mk" line 137: > Unable to determine compiler type for cc . Consider setting > COMPILER_TYPE. > *** [installkernel] Error code 1 > > make[1]: stopped in /pics/CrossBuild/src > 1 error > > make[1]: stopped in /pics/CrossBuild/src > *** [installkernel] Error code 2 > > make: stopped in /pics/CrossBuild/src > 1 error > > make: stopped in /pics/CrossBuild/src > root@Pool-MCP:/pics/CrossBuild # > > When investigating this what I find is that the executable in the > path > for "cc" is in fact an arm64 executable! So I have a built system > but > no way to install it. > > > > > > The instructions in the wiki page you cited are how to set up a > > development environment that uses an nfs-mounted root directory. > > You > > can also use it as a source for rsync, but you can't install > > directly > > from the objdir of such a build environment using an nfs mount > > unless > > the target system has the exact directory layout of the build > > system > > after nfs-mounting the source and obj dirs. > Except that doesn't work because the PATH contains executables for > the > source which is a different architecture. > > And when I tried to rsync it I got a system that booted and ran, sort > of, but anything that did floating point blew up. That might be > because > of schg flags prevented some of the copies and rsync has no good way > to > get around that (removing them from the target is undesirable for all > the obvious reasons.) > > > > > Another way to make it work is to nfs-mount the target's root > > directory > > on your build machine, then you can make installworld > > DESTDIR= > That's an interesting idea that I will look into. It's undesirable > for a > number of reasons down the road (enabling nfs server on these > machines > isn't my idea of a good thing over time) but it might get me going > for > the moment. > > > 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. > > Using a kernel and world built yesterday for armv6hf... > > > > root@wand :~ # awk "BEGIN {print 2.7+4.2 }" > > 6.9 > > > > I do all my building on a 10-stable machine. > > > > I wonder if your first attempt to installworld somehow installed > > some > > x86 stuff by accident and now you've got a mixed/broken world, and > > rsyn > > c didn't fix it because some of the broken files were more recent? > > > > -- Ian > Maybe. But I don't think so; I suspect the issue revolves around > schg > flags (in other words some things didn't update) and if so it's a > problem since I don't believe rsync can deal with that. > I had forgotten about the "can't determine compiler" error, other people have reported that too. It's another roadblock that adds up to "you can't do that" (install a crossbuilt system by mounting the objdir on the target). The way the crossbuild works is to create a bunch of cross-tools and put them in a PATH that makes them get used before the standard system tools; they're still there at install time. I'm not sure it's impossible to cross-build then non-cross install, but it certainly can't be done with the way the build system currently works. At $work we deal with updating by having readonly rootfs and all modified data on a different filesystem. We have two slices for rootfs so if we're running from slice 1 we newfs then populate slice 2, switch the active flag in the MBR, and reboot. Warner has recently been adding similar features to nanobsd, so it may be available as a solution for this stuff pretty soon. -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 15 17:08:12 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 37CC9A48E97 for ; Tue, 15 Dec 2015 17:08:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 BFC8619BC for ; Tue, 15 Dec 2015 17:08:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id D572D236C79 for ; Tue, 15 Dec 2015 11:08:10 -0600 (CST) Subject: Re: Updating / keeping current strategies? To: "freebsd-arm@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> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> <56703E2D.8050504@denninger.net> <1450198950.25138.50.camel@freebsd.org> From: Karl Denninger Message-ID: <567048CF.1000803@denninger.net> Date: Tue, 15 Dec 2015 11:07:27 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1450198950.25138.50.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050903080109000306000300" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 17:08:12 -0000 This is a cryptographically signed message in MIME format. --------------ms050903080109000306000300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/15/2015 11:02, Ian Lepore wrote: > On Tue, 2015-12-15 at 10:22 -0600, Karl Denninger wrote: >> Well, but they are if I maintain the paths. >> >> Example: I have the build at /pics/CrossBuild on the source (10.2 >> -STABLE >> amd64) machine. >> I export /pics/CrossBuild. >> >> I then mount that at /pics/CrossBuild on the target. Now the paths >> are >> the same. >> >> But..... when I try to do a "make installkernel" as you would do if >> doing this on a consistent architecture what I get is this: >> >> root@Pool-MCP:/pics/CrossBuild # ./mk installkernel >> TARGET_ARCH=3Darmv6hf >> + cd /pics/CrossBuild/src >> + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=3Darmv6hf' >> 'DESTDIR=3D/pics/CrossBuild/nfsroot' >> '__MAKE_CONF=3D/pics/CrossBuild/config/make.conf' >> 'srcconf=3D/pics/CrossBuild/config/src.conf' 'KERNCONF=3DRPI2' >> 'UBLDR_LOADADDR=3D0x2000000' installkernel 'TARGET_ARCH=3Darmv6hf' >> --- installkernel --- >> --- installkernel --- >> -------------------------------------------------------------- >>>>> Installing kernel RPI2 >> -------------------------------------------------------------- >> cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2;=20 >> MAKEOBJDIRPREFIX=3D/pics/CrossBuild/obj/arm.armv6hf=20 >> MACHINE_ARCH=3Darmv6hf=20 >> MACHINE=3Darm CPUTYPE=3D >> GROFF_BIN_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/= t >> mp/legacy/usr/bin=20 >> GROFF_FONT_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src= / >> tmp/legacy/usr/share/groff_font=20 >> GROFF_TMAC_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src= / >> tmp/legacy/usr/share/tmac >> CC=3D"cc " CXX=3D"c++ " DEPFLAGS=3D"" CPP=3D"cpp " AS=3D"as" AR=3D= "ar" >> LD=3D"ld" >> NM=3Dnm OBJDUMP=3Dobjdump OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRING= S=3D=20 >> SIZE=3D"size" >> PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy= / >> usr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/leg >> acy/usr/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/ >> legacy/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/u >> sr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/ >> bin:/sbin:/bin:/usr/sbin:/usr/bin=20 >> make KERNEL=3Dkernel install >> sh: cc: Exec format error >> make[2]: "/pics/CrossBuild/src/share/mk/bsd.compiler.mk" line 137: >> Unable to determine compiler type for cc . Consider setting >> COMPILER_TYPE. >> *** [installkernel] Error code 1 >> >> make[1]: stopped in /pics/CrossBuild/src >> 1 error >> >> make[1]: stopped in /pics/CrossBuild/src >> *** [installkernel] Error code 2 >> >> make: stopped in /pics/CrossBuild/src >> 1 error >> >> make: stopped in /pics/CrossBuild/src >> root@Pool-MCP:/pics/CrossBuild # >> >> When investigating this what I find is that the executable in the >> path >> for "cc" is in fact an arm64 executable! So I have a built system >> but >> no way to install it. >> >> >>> The instructions in the wiki page you cited are how to set up a >>> development environment that uses an nfs-mounted root directory.=20 >>> You >>> can also use it as a source for rsync, but you can't install >>> directly >>> from the objdir of such a build environment using an nfs mount >>> unless >>> the target system has the exact directory layout of the build >>> system >>> after nfs-mounting the source and obj dirs. >> Except that doesn't work because the PATH contains executables for >> the >> source which is a different architecture. >> >> And when I tried to rsync it I got a system that booted and ran, sort >> of, but anything that did floating point blew up. That might be >> because >> of schg flags prevented some of the copies and rsync has no good way >> to >> get around that (removing them from the target is undesirable for all >> the obvious reasons.) >> >>> Another way to make it work is to nfs-mount the target's root >>> directory >>> on your build machine, then you can make installworld >>> DESTDIR=3D >> That's an interesting idea that I will look into. It's undesirable >> for a >> number of reasons down the road (enabling nfs server on these >> machines >> isn't my idea of a good thing over time) but it might get me going >> for >> the moment. >>>> 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. >>> Using a kernel and world built yesterday for armv6hf... >>> >>> root@wand :~ # awk "BEGIN {print 2.7+4.2 }" >>> 6.9 >>> >>> I do all my building on a 10-stable machine. >>> >>> I wonder if your first attempt to installworld somehow installed >>> some >>> x86 stuff by accident and now you've got a mixed/broken world, and >>> rsyn >>> c didn't fix it because some of the broken files were more recent? >>> >>> -- Ian >> Maybe. But I don't think so; I suspect the issue revolves around >> schg >> flags (in other words some things didn't update) and if so it's a >> problem since I don't believe rsync can deal with that. >> > I had forgotten about the "can't determine compiler" error, other > people have reported that too. It's another roadblock that adds up to > "you can't do that" (install a crossbuilt system by mounting the objdir= > on the target). The way the crossbuild works is to create a bunch of > cross-tools and put them in a PATH that makes them get used before the > standard system tools; they're still there at install time. I'm not > sure it's impossible to cross-build then non-cross install, but it > certainly can't be done with the way the build system currently works. > > At $work we deal with updating by having readonly rootfs and all > modified data on a different filesystem. We have two slices for rootfs= > so if we're running from slice 1 we newfs then populate slice 2, switch= > the active flag in the MBR, and reboot. Warner has recently been > adding similar features to nanobsd, so it may be available as a > solution for this stuff pretty soon. > > -- Ian > Thanks... This is turning into a production .vs. development issue here in that I'm working on a home automation package that I intend to distribute and will run under FreeBSD on the Pi2. It's working extremely well and will bring down the price-point of such things in a big way (because the hardware is so cheap) while allowing all sorts of interesting things (like direct measurement analog inputs and relay-switched outputs.) But to do this and make it workable I have to be able to update a number of these machines consistently and, since -CURRENT is not really recommended for any sort of production anything (and -STABLE won't run on the Pi2) I am stuck with "gotta find a way to get 'stable enough' code" that I can point people at and is able to be reproduced "on demand.= " --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050903080109000306000300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUxNzA3MjdaME8GCSqGSIb3DQEJBDFCBEAq VKTTuZ2R3/qOo8UIh6UDZmZc7nPppQm/e3/dA5khHQSKQTT6BF5QuI5VumEUUQzxm7xpAzaz oZHRF8NZw4u8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAEV8WGSKy 8kkTEb5Q8IAKOiCy/snEWGAd2Xguk29slfdhRyLBZ2c2nQTwpBc1KZHF8o0Vydi46mpAFxfN crpgv9F8QUjlilF3Y1V2xIsy7/+ChFb/mn2UFkbpRfRmVrJMcVASzPPv65oeiVTv6NafMjLr sEg1ZU4Bklr4Q0ZLO/gWSs0YD1FMpkwxaOwiLpzhKe7ryfIc0EYlOn5+u2mkeV+9Ka/uCzFO mS83r7njmVRwE5N157YBf14368fmqRuZgKpkMKRnW4IwINeVRtIY/d0kGS1g9a1UMfED2Pc9 SKnDF5dsw2YVoNEkCf3/NSLsYH5hIdMAWtJCtCT0MAoiAJew1pprC3ne1gI2qRka3rhAcG11 nDZtSNe097fVmpX0vtbKgkYNRrRzc/hi6mo5ln+o/O5y7KNIWM7RKAqE3ReigAbUZUPgwCCA VgGCRpHjFQoNndyc0Ap148D8qFSTuqIg81/hI/2TsFpg/RTiIVW/3E+/icpESfcCDP055Cby M9k5NUHi/zqmfSJ3eEn9JlA0ghgFr2E7lxJYu9PyUnJiI0hG2DJfmUpNXUB3Gg9Z9X2BI2ut JFMkkgmqDufF/5bE40pMraWSiJpqUNuUEE/BmDGZ6I+bzNvphZzV7vg86QE2d6/Hixdieakm atW90d3jpVJMI3s8Git6fxue38UAAAAAAAA= --------------ms050903080109000306000300-- From owner-freebsd-arm@freebsd.org Tue Dec 15 17:15:16 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 7C0BDA4835F for ; Tue, 15 Dec 2015 17:15:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C9641ECE for ; Tue, 15 Dec 2015 17:15:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22b.google.com with SMTP id xm8so19057446igb.1 for ; Tue, 15 Dec 2015 09:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WIlX6MNpkfJx+cFdq775IkFvNYcUNbfChwQI04wor+c=; b=FsnkoP6x9Jbv2B6rG5uZNfiXfWWmshc2VtA6scZ8JkJP5J/0YA2X5PFB3Sxm+eA2NE 9c/gHcX6S2XEZ+z5IsM4OdahkYjvymBi+VvgjgPD+e9dIgASOKOOOnYQMRbRu8QPXy6E X17QZdBeI8NvN291M+BnOYZxWwPLfj+V2HEzbibtFTyfXucKqUBDVxbD8poD+z2xU+wp oVsbndvL+Qn2TGVw3f5g3+NBiny3CaHzLWHds4SJx5xsrWVDEJ9vkGucqqVnfhsQD6Y0 Yj4XeN9uvmYxU+pvvO8/m6UR5aLlpNiCsBYQN91bHLp1uctwvY1uBmAUWpNQxSYKxrVH k3zQ== MIME-Version: 1.0 X-Received: by 10.50.115.72 with SMTP id jm8mr4873141igb.61.1450199715653; Tue, 15 Dec 2015 09:15:15 -0800 (PST) Received: by 10.36.121.202 with HTTP; Tue, 15 Dec 2015 09:15:15 -0800 (PST) In-Reply-To: <567048CF.1000803@denninger.net> 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> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> <56703E2D.8050504@denninger.net> <1450198950.25138.50.camel@freebsd.org> <567048CF.1000803@denninger.net> Date: Tue, 15 Dec 2015 09:15:15 -0800 Message-ID: Subject: Re: Updating / keeping current strategies? From: Adrian Chadd To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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 17:15:16 -0000 This is why people just roll with nanobsd and do full image replacement with active/failover booting. -adrian From owner-freebsd-arm@freebsd.org Tue Dec 15 17:26:23 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 9E275A48AF2 for ; Tue, 15 Dec 2015 17:26:23 +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 800F417B2 for ; Tue, 15 Dec 2015 17:26:23 +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 17:26:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFHQLWs021145; Tue, 15 Dec 2015 10:26:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450200381.25138.54.camel@freebsd.org> Subject: Re: Updating / keeping current strategies? From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Tue, 15 Dec 2015 10:26:21 -0700 In-Reply-To: <567048CF.1000803@denninger.net> 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> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> <56703E2D.8050504@denninger.net> <1450198950.25138.50.camel@freebsd.org> <567048CF.1000803@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 17:26:23 -0000 On Tue, 2015-12-15 at 11:07 -0600, Karl Denninger wrote: > [...] > > This is turning into a production .vs. development issue here in that > I'm working on a home automation package that I intend to distribute > and > will run under FreeBSD on the Pi2. It's working extremely well and > will > bring down the price-point of such things in a big way (because the > hardware is so cheap) while allowing all sorts of interesting things > (like direct measurement analog inputs and relay-switched outputs.) > > But to do this and make it workable I have to be able to update a > number > of these machines consistently and, since -CURRENT is not really > recommended for any sort of production anything (and -STABLE won't > run > on the Pi2) I am stuck with "gotta find a way to get 'stable enough' > code" that I can point people at and is able to be reproduced "on > demand." > I can't think of any reason why rpi2 couldn't work on 10-stable other than nobody has MFC'd the changes needed to make that happen, and the only reason for that might be because nobody has asked for it. (I don't have rpi2 hardware myself to test anything.) There is no g'tee it would work or be more stable on 10 at this point though (the ARM_NEW_PMAP code that has been in place on 11 for about a year isn't present on 10, so rpi2 has never been tested with the old code). -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 15 18:15:39 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 18656A43E0E for ; Tue, 15 Dec 2015 18:15:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D79C119D1 for ; Tue, 15 Dec 2015 18:15:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tBFIAlxU032652; Tue, 15 Dec 2015 10:10:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tBFIAl8a032651; Tue, 15 Dec 2015 10:10:47 -0800 (PST) (envelope-from fbsd) Date: Tue, 15 Dec 2015 10:10:47 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: No space left in lost+found Message-ID: <20151215181047.GA29187@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i 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 18:15:39 -0000 Hi all, Lately I've been seeing "sorry, no space left in lost+found directory" during routine fsck of my rpi2. The messages seem to be new, in the last few weeks. The machine has root on the microSD card, but /usr, /tmp, /var and swap are all on a mechanical USB hard disk. Unrecovered files/directories are in /tmp. The running cycle is typically to build the latest revision of current, compile, reboot, fsck -fy twice and run stress2 -a till it crashes. Next, reboot, run fsck -fy three times, update using svnlite and repeat. After the reboot is complete, /lost+found is empty. Do I have something misconfigured? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Dec 15 18:38:59 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 4B041A48EB0 for ; Tue, 15 Dec 2015 18:38:59 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 2352719A1 for ; Tue, 15 Dec 2015 18:38:59 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6387420989 for ; Tue, 15 Dec 2015 13:38:58 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Tue, 15 Dec 2015 13:38:58 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Oh1D6ufqOmZvEXj 3wrTzIkga/I8=; b=QRQmBrFwF2BdberTz21iS0sUcLWkDy8valxeh+MYP5fRl9f ukLPjdUBwAnb3RXnhS40N+NtU/TzMOksMXme7O45AWE8nnMBR1j6oZy3vsxKbWaL uLJZBXk4Why0uH9oAKvzgYIxU//IRtSJwkZaUuE/0rH/0KT5gaAZAe6DbsEE= Received: by web3.nyi.internal (Postfix, from userid 99) id 3E1E110E1E4; Tue, 15 Dec 2015 13:38:58 -0500 (EST) Message-Id: <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> X-Sasl-Enc: W+pK5Xa03du/pHAmEHE09nsu2hccwbS2wRLTGIN6BJaQ 1450204738 From: Mark Felder To: bob prohaska , freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: <20151215181047.GA29187@www.zefox.net> References: <20151215181047.GA29187@www.zefox.net> Subject: Re: No space left in lost+found Date: Tue, 15 Dec 2015 12:38:58 -0600 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 18:38:59 -0000 On Tue, Dec 15, 2015, at 12:10, bob prohaska wrote: > Hi all, > > Lately I've been seeing "sorry, no space left in lost+found directory" > during > routine fsck of my rpi2. The messages seem to be new, in the last few > weeks. > The machine has root on the microSD card, but /usr, /tmp, /var and swap > are > all on a mechanical USB hard disk. Unrecovered files/directories are in > /tmp. > > The running cycle is typically to build the latest revision of current, > compile, > reboot, fsck -fy twice and run stress2 -a till it crashes. Next, reboot, > run fsck -fy > three times, update using svnlite and repeat. > > After the reboot is complete, /lost+found is empty. > > Do I have something misconfigured? > > Thanks for reading, > > bob prohaska > Can you provide the "tunefs -p" output of the filesystem? eg, tunefs -p /dev/da0p2 -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-arm@freebsd.org Tue Dec 15 19:18:48 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 2810BA48828 for ; Tue, 15 Dec 2015 19:18:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDEE7158F; Tue, 15 Dec 2015 19:18:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tBFJIkNP032822; Tue, 15 Dec 2015 11:18:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tBFJIjj2032821; Tue, 15 Dec 2015 11:18:45 -0800 (PST) (envelope-from fbsd) Date: Tue, 15 Dec 2015 11:18:45 -0800 From: bob prohaska To: Mark Felder Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: No space left in lost+found Message-ID: <20151215191845.GB29187@www.zefox.net> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> User-Agent: Mutt/1.4.2.3i 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 19:18:48 -0000 Hi Mark, Here's what I get, da0p4 is /tmp root@www:/lost+found # tunefs -p /dev/da0p4 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 3296 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) root@www:/lost+found # root@www:/lost+found # tunefs -p /dev/mmcsd0s2a tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) No intentional changes were made from as-installed defaults. Note that /lost+found resides on the microSD card, with 4 GB free. Here's df: root@www:/lost+found # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 7031260 2327652 4141108 36% / devfs 1 1 0 100% /dev /dev/mmcsd0s1 51128 7332 43796 14% /boot/msdos /dev/da0p4 1279260 51568 1125352 4% /tmp /dev/da0p3 29442460 18775576 8311488 69% /usr /dev/da0p1 4053308 156100 3572944 4% /var Thanks for reading! bob prohaska On Tue, Dec 15, 2015 at 12:38:58PM -0600, Mark Felder wrote: > > > On Tue, Dec 15, 2015, at 12:10, bob prohaska wrote: > > Hi all, > > > > Lately I've been seeing "sorry, no space left in lost+found directory" > > during > > routine fsck of my rpi2. The messages seem to be new, in the last few > > weeks. > > The machine has root on the microSD card, but /usr, /tmp, /var and swap > > are > > all on a mechanical USB hard disk. Unrecovered files/directories are in > > /tmp. > > > > The running cycle is typically to build the latest revision of current, > > compile, > > reboot, fsck -fy twice and run stress2 -a till it crashes. Next, reboot, > > run fsck -fy > > three times, update using svnlite and repeat. > > > > After the reboot is complete, /lost+found is empty. > > > > Do I have something misconfigured? > > > > Thanks for reading, > > > > bob prohaska > > > > Can you provide the "tunefs -p" output of the filesystem? eg, tunefs -p > /dev/da0p2 > > > -- > Mark Felder > ports-secteam member > feld@FreeBSD.org From owner-freebsd-arm@freebsd.org Tue Dec 15 19:54:01 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 B9115A48090 for ; Tue, 15 Dec 2015 19:54:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 9CBAF10AB for ; Tue, 15 Dec 2015 19:54:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 19:54:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFJrxQ2021409; Tue, 15 Dec 2015 12:53:59 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450209239.25138.62.camel@freebsd.org> Subject: Re: No space left in lost+found From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Tue, 15 Dec 2015 12:53:59 -0700 In-Reply-To: <20151215181047.GA29187@www.zefox.net> References: <20151215181047.GA29187@www.zefox.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 19:54:01 -0000 On Tue, 2015-12-15 at 10:10 -0800, bob prohaska wrote: > Hi all, > > Lately I've been seeing "sorry, no space left in lost+found > directory" during > routine fsck of my rpi2. The messages seem to be new, in the last few > weeks. > The machine has root on the microSD card, but /usr, /tmp, /var and > swap are > all on a mechanical USB hard disk. Unrecovered files/directories are > in /tmp. > > The running cycle is typically to build the latest revision of > current, compile, > reboot, fsck -fy twice and run stress2 -a till it crashes. Next, > reboot, run fsck -fy > three times, update using svnlite and repeat. > > After the reboot is complete, /lost+found is empty. > > Do I have something misconfigured? > > Thanks for reading, > > bob prohaska I had a similar-ish problem a while back, where a 128gb ufs filesystem showed 75gb in use, 43gb free, but kept getting "no space" errors on trying to copy a few big files to it. I finally found a filesystem snapshot (.snap file) in lost+found and when I removed that suddenly everything was back to normal on that filesystem. -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 15 19:54:36 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 6B453A4810A for ; Tue, 15 Dec 2015 19:54:36 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 44B931116 for ; Tue, 15 Dec 2015 19:54:35 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D7F1621809 for ; Tue, 15 Dec 2015 14:54:34 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute4.internal (MEProxy); Tue, 15 Dec 2015 14:54:34 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=fMkzm2j70TxUEn3 XRGsbp7/3HSc=; b=Xg25HiDWzWq/QVOQPZZxrIToPudqafzgRoUytPNmGNjnPHZ nk0IefBX3srZTkM0uqm75DaRqtEZ34q2JTxpj0ruzkKS1sSUJJyl+d4psdM+0pib b8cUUK+JRXgKuumDn81jpwzqZ1c/fvLAPP4eHXKik6IRY0lz2RLzp9iXs02A= Received: by web3.nyi.internal (Postfix, from userid 99) id ACC3710E4D7; Tue, 15 Dec 2015 14:54:34 -0500 (EST) Message-Id: <1450209274.4299.468358681.22757635@webmail.messagingengine.com> X-Sasl-Enc: b5mF2qlQmO3EHpfPXgf7A196vP46qRvsncxzadiFsg+C 1450209274 From: Mark Felder To: bob prohaska Cc: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5c8c9c89 In-Reply-To: <20151215191845.GB29187@www.zefox.net> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> Subject: Re: No space left in lost+found Date: Tue, 15 Dec 2015 13:54:34 -0600 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 19:54:36 -0000 On Tue, Dec 15, 2015, at 13:18, bob prohaska wrote: > Hi Mark, > > Here's what I get, da0p4 is /tmp > > root@www:/lost+found # tunefs -p /dev/da0p4 > tunefs: soft update journaling: (-j) enabled > root@www:/lost+found # tunefs -p /dev/mmcsd0s2a > tunefs: soft update journaling: (-j) enabled I would recommend turning off soft update journaling and see if your problem goes away. If that doesn't work, perhaps disable soft updates entirely. Anyone else have thoughts on this? -- Mark Felder ports-secteam member feld@FreeBSD.org From owner-freebsd-arm@freebsd.org Tue Dec 15 20:27:24 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 4B205A485C7 for ; Tue, 15 Dec 2015 20:27:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 13CF911BB for ; Tue, 15 Dec 2015 20:27:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 15 Dec 2015 20:27:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBFKRLfH021453; Tue, 15 Dec 2015 13:27:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450211241.25138.75.camel@freebsd.org> Subject: Re: No space left in lost+found From: Ian Lepore To: Mark Felder , bob prohaska Cc: freebsd-arm@freebsd.org Date: Tue, 15 Dec 2015 13:27:21 -0700 In-Reply-To: <1450209274.4299.468358681.22757635@webmail.messagingengine.com> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> <1450209274.4299.468358681.22757635@webmail.messagingengine.com> 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 20:27:24 -0000 On Tue, 2015-12-15 at 13:54 -0600, Mark Felder wrote: > > On Tue, Dec 15, 2015, at 13:18, bob prohaska wrote: > > Hi Mark, > > > > Here's what I get, da0p4 is /tmp > > > > root@www:/lost+found # tunefs -p /dev/da0p4 > > tunefs: soft update journaling: (-j) enabled > > > root@www:/lost+found # tunefs -p /dev/mmcsd0s2a > > tunefs: soft update journaling: (-j) enabled > > I would recommend turning off soft update journaling and see if your > problem goes away. If that doesn't work, perhaps disable soft updates > entirely. Anyone else have thoughts on this? > I've always been anti-journaling, but only some of reasons are based inprovable facts. Over the years there have been a lot of complaints about it. Probably some of them were genuine then, but have long since been fixed. Some of them may have been user error or bad hardware. But all in all, it has left me with a very negative opinion of journaling with ufs. But that's all emotion, not really hard facts. A few factual things... Journaling means doing a lot more writing and on an sdcard that's slow. A lot of people say it's also bad in terms of wearing out the card, but that doesn't worry me so much, it's a lot harder to kill an sdcard than most people think. To me the strongest argument against it for most small-system users is that the whole point of journaling is to take a small performance hit on each write to avoid a long (sometimes hours-long) downtime doing fsck after a crash. It doesn't improve reliability by storing extra info that can make a better recovery than fsck alone, it's just a "pay me now or pay me later" performance tradeoff. But on an sdcard the performance hit for extra writing isn't small, and the time to do a full fsck after a crash isn't large. So in that sense journaling adds nothing of value. IMO, soft updates (without journaling) is almost mandatory on an sdcard. Without it, there is so much extra metadata IO that performance is horrible. -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 15 22:36:22 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 22321A48B45 for ; Tue, 15 Dec 2015 22:36:22 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 DFD5A1A65 for ; Tue, 15 Dec 2015 22:36:21 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id F1D7B236BA4 for ; Tue, 15 Dec 2015 16:36:19 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Mp3 player (or other sound player) on RPI2? Message-ID: <567095B8.90504@denninger.net> Date: Tue, 15 Dec 2015 16:35:36 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070306010002000603080706" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 22:36:22 -0000 This is a cryptographically signed message in MIME format. --------------ms070306010002000603080706 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mpg123 apparently has a bad incompatibility with the desired bitrate on the default audio interface and produces only noise. "Espeak" works.... but I'd like to be able to play a Mp3 file..... is there a command-line tool that works on the Rpi/Rpi2? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070306010002000603080706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUyMjM1MzZaME8GCSqGSIb3DQEJBDFCBEB/ AMUyTf2/KPptL8V/VWny8AuhilguQVFzKDW4JbrruA2yQtkMG6yd+3dYJgi97Be3un01Ab1t wfYtQEv/2bx4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAiulig7XH i6ly0QAr56m1fgtU8G4/75KbXCQaoFn6Yy9rZ31RHUE9yci2HSGUnCCSygrCkOI0BWD+Ynp+ pBhqjl2tWu8jpMYJ7exReqW0vEM1j5zdqRG46rMPEpb8sPh5MuqnepPxmdN3HFe7qwe/eSJi QB8BsK0QcMVWoagVo8jLgsrKpW1cuO98Lckw6S9umryEGw0QEOpXaTIj2stvfbj0YWxIbVel 2Q5ZnWk6tln+qZjDhrsr85m0Dg0e/gDuqyA+klg64rmytnrm8+7ZszJr3dHMIHLSWIhYxhMV ekf0dOQ1kJmeYQi/MUihThFgqUrBxPwejlcUlBDbYwosYBw8IFe+5sREo64DfTj0IFAZHSIE hjZqqP5hIiO6B+7NOYCij+eiJrZL8GRg5/Km1vouE9Cbm8k6vbU/uJL/eEXDfoxtarNh3CR8 ISaaKA2kw5GyODt2K+JjDH3Ge0fFNiEiyg0JAsVBwMzovSgKDBEMvogZhRgyti8I6FI8/IUW x8exIky3ng0HM9rOWud15ZOEc18aMyauAyE8MlO+fxTTS35xpmgJAMQofqQTfmunFr1nI8uw FFrChlNTGAiQhre6W3R1aqFVhRkxPW3YmXL2m7Qws7BjQtvwuCIo069TnLWG7S6EIRcEt4fE xT7RRD/QZtqQKkaANjvQyUkZ4+8AAAAAAAA= --------------ms070306010002000603080706-- From owner-freebsd-arm@freebsd.org Wed Dec 16 01:38:54 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 303D4A4911A for ; Wed, 16 Dec 2015 01:38:54 +0000 (UTC) (envelope-from stas@deglitch.com) Received: from mx0.deglitch.com (mx0.deglitch.com [IPv6:2a00:13c0:63:7194:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id EABD815B1 for ; Wed, 16 Dec 2015 01:38:53 +0000 (UTC) (envelope-from stas@deglitch.com) Received: from [IPv6:2620:10d:c082:1803:4131:61b8:c346:700c] (unknown [IPv6:2620:10d:c090:200::3:1a7a]) by mx0.deglitch.com (Postfix) with ESMTPSA id A46E88FC45; Tue, 15 Dec 2015 17:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=deglitch.com; s=default; t=1450229930; bh=Jg2aLLZJX+9kDsgVofPuwNGogxrz2NfqjlHPgTZGro4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cBs43RC+vmY57INnRIZ8wq3x0YSA7PcnZWMJQWBSaE9UCuA4rcWNZ0Eur694+9zCT /o8f3ro9mThtUnTLa716Oq4n6Z9dNv9FwyHrjh4b9fNXyLZw2f8Hb6YkQYVZOwFylT cStfCiVKQiIfYR3v9pb4YOGrwtnZXV/OOa+mnwA0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Mp3 player (or other sound player) on RPI2? From: Stanislav Sedov In-Reply-To: <567095B8.90504@denninger.net> Date: Tue, 15 Dec 2015 17:38:46 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: References: <567095B8.90504@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3112) 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: Wed, 16 Dec 2015 01:38:54 -0000 > On Dec 15, 2015, at 2:35 PM, Karl Denninger wrote: > > Mpg123 apparently has a bad incompatibility with the desired bitrate on > the default audio interface and produces only noise. "Espeak" works.... > but I'd like to be able to play a Mp3 file..... is there a command-line > tool that works on the Rpi/Rpi2? I have not tried that, but can't you force a different output bitrate in mpg123? It looks like it has a --rate option for that. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-arm@freebsd.org Wed Dec 16 13:33:28 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 E0C6EA4936F for ; Wed, 16 Dec 2015 13:33:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5536E1A30; Wed, 16 Dec 2015 13:33:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBG7hL2k096256 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Dec 2015 09:43:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBG7hL2k096256 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBG7hLtb096255; Wed, 16 Dec 2015 09:43:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Dec 2015 09:43:21 +0200 From: Konstantin Belousov To: Ian Lepore Cc: Mark Felder , bob prohaska , freebsd-arm@freebsd.org Subject: Re: No space left in lost+found Message-ID: <20151216074321.GO3625@kib.kiev.ua> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> <1450209274.4299.468358681.22757635@webmail.messagingengine.com> <1450211241.25138.75.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1450211241.25138.75.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Wed, 16 Dec 2015 13:33:28 -0000 On Tue, Dec 15, 2015 at 01:27:21PM -0700, Ian Lepore wrote: > On Tue, 2015-12-15 at 13:54 -0600, Mark Felder wrote: > > > > On Tue, Dec 15, 2015, at 13:18, bob prohaska wrote: > > > Hi Mark, > > > > > > Here's what I get, da0p4 is /tmp > > > > > > root@www:/lost+found # tunefs -p /dev/da0p4 > > > tunefs: soft update journaling: (-j) enabled > > > > > root@www:/lost+found # tunefs -p /dev/mmcsd0s2a > > > tunefs: soft update journaling: (-j) enabled > > > > I would recommend turning off soft update journaling and see if your > > problem goes away. If that doesn't work, perhaps disable soft updates > > entirely. Anyone else have thoughts on this? > > > > I've always been anti-journaling, but only some of reasons are based inprovable facts. > > Over the years there have been a lot of complaints about it. Probably > some of them were genuine then, but have long since been fixed. Some > of them may have been user error or bad hardware. But all in all, it > has left me with a very negative opinion of journaling with ufs. > > But that's all emotion, not really hard facts. A few factual things... Factual thing about +J is that there are several unresolved deadlocks under high metadata i/o load. Also I saw several sporadic reports of fsck code having issues, but this mostly occured for the trashed journal and can be blamed to lack of proper sanity checks. Minor thing is that +J and snapshots do not live together. Returning to the OP problem, please show the output of ls -ld your/lost+found > > Journaling means doing a lot more writing and on an sdcard that's slow. > A lot of people say it's also bad in terms of wearing out the card, > but that doesn't worry me so much, it's a lot harder to kill an sdcard > than most people think. > > To me the strongest argument against it for most small-system users is > that the whole point of journaling is to take a small performance hit > on each write to avoid a long (sometimes hours-long) downtime doing > fsck after a crash. It doesn't improve reliability by storing extra > info that can make a better recovery than fsck alone, it's just a "pay > me now or pay me later" performance tradeoff. > > But on an sdcard the performance hit for extra writing isn't small, and > the time to do a full fsck after a crash isn't large. So in that sense > journaling adds nothing of value. > > IMO, soft updates (without journaling) is almost mandatory on an > sdcard. Without it, there is so much extra metadata IO that > performance is horrible. From owner-freebsd-arm@freebsd.org Wed Dec 16 13:39:21 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 289ABA49F52; Wed, 16 Dec 2015 13:39:21 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 A6A0A1BB9; Wed, 16 Dec 2015 13:39:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 40135153418; Wed, 16 Dec 2015 11:01:22 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUiH6xEfncLt; Wed, 16 Dec 2015 11:00:54 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:ec88:e8ea:2fbd:5e1f] (unknown [IPv6:2001:4cb8:3:1:ec88:e8ea:2fbd:5e1f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C0A8C15340A; Wed, 16 Dec 2015 11:00:19 +0100 (CET) Subject: Re: "libssl.so.8" not found To: Brad Davis , Warner Losh References: <20151214071840.GA3771@c720-r285885-amd64> <20151214153517.GB49345@corpmail.liquidneon.com> Cc: Ronald Klop , freebsd-arm , Matthias Apitz , FreeBSD Current From: Willem Jan Withagen X-Enigmail-Draft-Status: N1110 Message-ID: <56713633.10401@digiware.nl> Date: Wed, 16 Dec 2015 11:00:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151214153517.GB49345@corpmail.liquidneon.com> Content-Type: text/plain; charset=windows-1252 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: Wed, 16 Dec 2015 13:39:21 -0000 On 14-12-2015 16:35, Brad Davis wrote: > On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote: >> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote: >> >>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop >>> wrote: >>> >>> On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz >>>> wrote: >>>> >>>> El d??a Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley >>>>> escribi??: >>>>> >>>>> Hi There, >>>>>> >>>>>> I am trying to bring up an Arm image off the FreeBSD website for my >>>>>> hummingboard. The problem seems to be when I run pkg the system installs >>>>>> the latest version - 1.6.2, and then fails with: >>>>>> >>>>>> Shared object "libssl.so.8" not found, required by "pkg" >>>>>> >>>>>> I've seen this in NextBSD, and DesktopBSD and even on my previous arm >>>>>> image >>>>>> but I was able to get around the problem by creating links from >>>>>> libssl.so.7 >>>>>> to libssl.so.8. >>>>>> >>>>> >>>>> I have had the same issue on r285885 with ports as well from July this >>>>> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not >>>>> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and >>>>> now pkg >>>>> complains about it database, but still works: >>>>> >>>>> $ pkg info pkg >>>>> pkg: warning: database version 32 is newer than libpkg(3) version 31, >>>>> but still compatible >>>>> pkg-1.5.5 >>>>> >>>>> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it >>>>> should have been done more conservative, IMHO >>>>> >>>>> matthias >>>>> >>>>> >>>> I had the same problem on my amd64 laptop. Your FreeBSD version is too >>>> old. Upgrading the FreeBSD base will give you the new libssl version. After >>>> that you can upgrade your packages. >>>> >>>> What version of FreeBSD is running on this hummingboard? I guess >>>> 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages are >>>> build on this newer version. In 10-STABLE this is kept backwards >>>> compatible, but in 11-CURRENT you have to keep up yourself. >>>> >>>> Regards, >>>> >>>> Ronald. >>>> >>> >>> It has to do with this message in /usr/src/UPDATING: >>> >>> >>> https://svnweb.freebsd.org/base/head/UPDATING?r1=290206&r2=290207&pathrev=292177& >> >> >> As a temporary measure, for bootstrapping or installing packages, you can >> also >> use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library >> that >> you'll find you need to map too. This will get you over the hump. However, >> once you do upgrade, you'll need to remove the lines because slogin and such >> have a check for the right version of openssl, and will give an error >> message if >> you try to use them cross-threaded. > > Or just use pkg-static. :) Cool trick, never though about that. However that does not help with auxilary tools that are code to use pkg. :( So in the end I just manually build the pkg port, which will compile against whatever is available as ssl-lib. Not the best solution, since next time Bapt releases a new version, the game starts again. perhaps in this case it is best to move pkg-static to pkg? and always use a static linked version. It is not like a deamon running for ever. So the temporary overhead of 4Mb <> 150K code space would be acceptable. --WjW From owner-freebsd-arm@freebsd.org Wed Dec 16 13:40:54 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 04F2CA48170 for ; Wed, 16 Dec 2015 13:40:54 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFB2D17D2 for ; Wed, 16 Dec 2015 13:40:53 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 110526DF91B; Wed, 16 Dec 2015 09:37:36 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id tBG8bZBd077244; Wed, 16 Dec 2015 09:37:35 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id tBG8bYHb075178; Wed, 16 Dec 2015 09:37:34 +0100 (CET) (envelope-from lars) Date: Wed, 16 Dec 2015 09:37:34 +0100 From: Lars Engels To: Karl Denninger Cc: "freebsd-arm@freebsd.org" Subject: Re: Mp3 player (or other sound player) on RPI2? Message-ID: <20151216083734.GJ78415@e-new.0x20.net> References: <567095B8.90504@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <567095B8.90504@denninger.net> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 16 Dec 2015 13:40:54 -0000 On Tue, Dec 15, 2015 at 04:35:36PM -0600, Karl Denninger wrote: > Mpg123 apparently has a bad incompatibility with the desired bitrate on > the default audio interface and produces only noise. "Espeak" works.... > but I'd like to be able to play a Mp3 file..... is there a command-line > tool that works on the Rpi/Rpi2? You could give audio/mpg321 a try. From owner-freebsd-arm@freebsd.org Wed Dec 16 14:15:12 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 AEE4FA48BC7 for ; Wed, 16 Dec 2015 14:15:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 74B161617 for ; Wed, 16 Dec 2015 14:15:12 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B994E23662F for ; Wed, 16 Dec 2015 08:15:10 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: More trouble in the bcm code... Message-ID: <567171ED.907@denninger.net> Date: Wed, 16 Dec 2015 08:15:09 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040706080803020804040906" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 16 Dec 2015 14:15:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040706080803020804040906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =46rom a fresh checkout and build yesterday: FreeBSD 11.0-CURRENT #0 r292266: Tue Dec 15 10:10:20 CST 2015 After some amount of use I start getting this on the dmesg output, and attempting to use PCM (audio) returns the following. Ideas for running this down? bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10007 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10007 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040706080803020804040906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTYxNDE1MDlaME8GCSqGSIb3DQEJBDFCBED/ Yd2zvCwEYLs7PFDn+YhbkXlePE32XTKPupSfrOL+12XLO+gmrHSNFeNfpkm8ZKW3YftID2fn zyX8VPQiSZjvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAXImWg9OI ejjRF+Xs4LhashcAH+vXU/HAjcUI4GyeG9rZfUALylAe+xsfNZN49C8y6v9QDTrkPU6w2IPU 6DDa7GXqLXV6cHNPPyL40qbCClUNusORhsjYIkz+Awt1gprnagxViosv5+F+cKXURxf4eEp3 7sjALeWqe8gxFMJXz8XkKrYSPehwK6gVNfULrriA6/fgJUqVa4ONj+9v7puvaNY84nviwdgg o0l3jcPOzje0PfS1DtL2NgtFzHKani+erThyEcSMRdlp/EQTRdONtA8dfMn1cv++NNxRbCQx T2sWY9yDZT3zGAYGNgyt1bP6ltz17qknn5uSjGdKQGa9/MzS8eNqRZGrC9nk5iiDqtJW0xPI 2flpdiugpRVjgCDZlE8b3ao98Mhs5sr1Ix6n1OZVkXNIFKSed+drDeRBabC9kQ3JGrIdguWW t+ZDPzxrnI51H8psIdMjtdgfAhU1EVPAv9NmFIrEJIe85lz6xScT0QxSWg450aB5rgUqtN2v fWq1PB4Kz1Ae+9NMkG100/Dfn42/zfIMYJg51sLZ8/Z9sy6ze2HGNYijVlMGO6+Qe76me50S HaZw55/rMBFZJb8eWY/dDhZFJTUWBHj7N17asmlCYAkUztJm5jtrRHp/h4LZBxNuELM9BmfP LALem7pjwnPEeIgxxRChdN/C7YYAAAAAAAA= --------------ms040706080803020804040906-- From owner-freebsd-arm@freebsd.org Wed Dec 16 14:15:45 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 F18E0A48C76 for ; Wed, 16 Dec 2015 14:15:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 BD1D81835 for ; Wed, 16 Dec 2015 14:15:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 344F9236640 for ; Wed, 16 Dec 2015 08:15:45 -0600 (CST) Subject: Re: More trouble in the bcm code... To: freebsd-arm@freebsd.org References: <567171ED.907@denninger.net> From: Karl Denninger Message-ID: <56717211.3030701@denninger.net> Date: Wed, 16 Dec 2015 08:15:45 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <567171ED.907@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020009040406040009000808" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 16 Dec 2015 14:15:46 -0000 This is a cryptographically signed message in MIME format. --------------ms020009040406040009000808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Oops - forgot to include that this is on a Raspberry Pi2. On 12/16/2015 08:15, Karl Denninger wrote: > From a fresh checkout and build yesterday: > FreeBSD 11.0-CURRENT #0 r292266: Tue Dec 15 10:10:20 CST 2015 > > After some amount of use I start getting this on the dmesg output, and > attempting to use PCM (audio) returns the following. > > Ideas for running this down? > > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10007 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10007 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, > channel dead > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, > channel dead > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, > channel dead > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > bcm_dma0: unused DMA intr CH=3D3, CS=3D20f10027 > pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, > channel dead > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020009040406040009000808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTYxNDE1NDVaME8GCSqGSIb3DQEJBDFCBEAU etxdFHOhbZiBRUYiUHpbYsS7tRmhRs6I/3ar/WSoEjWv9nKn0l6objQab2A4yMCiXBYndu+s 7UT9fNwKewP7MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAX5NXlfMV Bfw+BMviR9Z8KNtf5RPbFbsP5GU6eVDhEKP2ffnYrZ7XGWkY7tCHqzh6kzwm/UoLXeTBzpmc +ynYjTDbTInqlPewL+0X/QOF9ztr8ZqKp3Nj6zcvtiQlxZaGi5u44Q5F44bRBrLT/X6BOTVK qGgffBSWIgi3ZWFv9SHhUGe1O+oHlp/oc1cF1KjYupA29SV2fH5hZzINOkDrqpSUOHfD5RMw vmI7Rozj4rMgN/f2SMHPQepzVFUhQzSNMbkzyiR/kDWJdzEBNz+l2XHPokLbUGp8JlqgUhNi F+B/1GhzuZXC9hFra1wXs7kKWrW4oUC9f39aTFu34ScMZObLwFJXkvP9Ub64FVHa0QE4i16N m2GyCXPdLlFIeg14E2wcGCgwbV8tPGuNyudfXb4iAztT8s9FeZdax45ZfwG+HpqCQOJGzb57 v6A5Og3UFbVCWh9srqHw5EF64433yqpj353Ap1g2Uo+jUXB+TGuyJygtZj+kB2xOIbxMW551 09AB/JvGbKV9NbT0shKdGoguwsOmzB3Guo79o3cPwxV6GPpnNami/mg8TijbX6AD0cbzHoaf o7uxrAoBwu8Gm/hvdqfSEZ4X9qhrm2vmXVsQEPFDof0ez3qUpoR2oBlo8OkpE2B75objBap5 aA+6aQqmyZ3wAFtydve8JPA5Bj0AAAAAAAA= --------------ms020009040406040009000808-- From owner-freebsd-arm@freebsd.org Wed Dec 16 15:41:28 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 89916A49603; Wed, 16 Dec 2015 15:41:28 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "valentine.liquidneon.com", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 602DB1A8F; Wed, 16 Dec 2015 15:41:27 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id 0D0071D850; Wed, 16 Dec 2015 15:41:21 +0000 (UTC) Date: Wed, 16 Dec 2015 15:41:21 +0000 From: Brad Davis To: Willem Jan Withagen Cc: Brad Davis , Warner Losh , Ronald Klop , freebsd-arm , Matthias Apitz , FreeBSD Current Subject: Re: "libssl.so.8" not found Message-ID: <20151216154120.GE49345@corpmail.liquidneon.com> References: <20151214071840.GA3771@c720-r285885-amd64> <20151214153517.GB49345@corpmail.liquidneon.com> <56713633.10401@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56713633.10401@digiware.nl> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Wed, 16 Dec 2015 15:41:28 -0000 On Wed, Dec 16, 2015 at 11:00:19AM +0100, Willem Jan Withagen wrote: > On 14-12-2015 16:35, Brad Davis wrote: > > On Mon, Dec 14, 2015 at 06:03:25AM -0700, Warner Losh wrote: > >> On Mon, Dec 14, 2015 at 2:21 AM, Ronald Klop wrote: > >> > >>> On Mon, 14 Dec 2015 10:11:35 +0100, Ronald Klop > >>> wrote: > >>> > >>> On Mon, 14 Dec 2015 08:18:40 +0100, Matthias Apitz > >>>> wrote: > >>>> > >>>> El d??a Sunday, December 13, 2015 a las 10:40:22PM -0800, Russell Haley > >>>>> escribi??: > >>>>> > >>>>> Hi There, > >>>>>> > >>>>>> I am trying to bring up an Arm image off the FreeBSD website for my > >>>>>> hummingboard. The problem seems to be when I run pkg the system installs > >>>>>> the latest version - 1.6.2, and then fails with: > >>>>>> > >>>>>> Shared object "libssl.so.8" not found, required by "pkg" > >>>>>> > >>>>>> I've seen this in NextBSD, and DesktopBSD and even on my previous arm > >>>>>> image > >>>>>> but I was able to get around the problem by creating links from > >>>>>> libssl.so.7 > >>>>>> to libssl.so.8. > >>>>>> > >>>>> > >>>>> I have had the same issue on r285885 with ports as well from July this > >>>>> year and pkg 1.5.5 ... I accidently updated pkg to 1.6.x which could not > >>>>> find libssl.so.8; I forced back to 1.5.5 with an older pkg-static and > >>>>> now pkg > >>>>> complains about it database, but still works: > >>>>> > >>>>> $ pkg info pkg > >>>>> pkg: warning: database version 32 is newer than libpkg(3) version 31, > >>>>> but still compatible > >>>>> pkg-1.5.5 > >>>>> > >>>>> I don't know why pkg 1.6.2 was produced with this recent libssl.so.8; it > >>>>> should have been done more conservative, IMHO > >>>>> > >>>>> matthias > >>>>> > >>>>> > >>>> I had the same problem on my amd64 laptop. Your FreeBSD version is too > >>>> old. Upgrading the FreeBSD base will give you the new libssl version. After > >>>> that you can upgrade your packages. > >>>> > >>>> What version of FreeBSD is running on this hummingboard? I guess > >>>> 11-CURRENT. Probably ssl was upgraded in FreeBSD and the new packages are > >>>> build on this newer version. In 10-STABLE this is kept backwards > >>>> compatible, but in 11-CURRENT you have to keep up yourself. > >>>> > >>>> Regards, > >>>> > >>>> Ronald. > >>>> > >>> > >>> It has to do with this message in /usr/src/UPDATING: > >>> > >>> > >>> https://svnweb.freebsd.org/base/head/UPDATING?r1=290206&r2=290207&pathrev=292177& > >> > >> > >> As a temporary measure, for bootstrapping or installing packages, you can > >> also > >> use libmap.conf to map libssl.so.7 to libssl.so.8. There's a second library > >> that > >> you'll find you need to map too. This will get you over the hump. However, > >> once you do upgrade, you'll need to remove the lines because slogin and such > >> have a check for the right version of openssl, and will give an error > >> message if > >> you try to use them cross-threaded. > > > > Or just use pkg-static. :) > > Cool trick, never though about that. > However that does not help with auxilary tools that are code to use pkg. :( > > So in the end I just manually build the pkg port, which will compile > against whatever is available as ssl-lib. Not the best solution, since > next time Bapt releases a new version, the game starts again. No. This was caused by ssl being bumped, not pkg. Pkg is updated regularly without this issue. > perhaps in this case it is best to move pkg-static to pkg? > and always use a static linked version. It is not like a deamon running > for ever. So the temporary overhead of 4Mb <> 150K code space would be > acceptable. There is talk about making the static version the default. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Wed Dec 16 15:48:51 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 5A2BCA49B36; Wed, 16 Dec 2015 15:48:51 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 172201F8C; Wed, 16 Dec 2015 15:48:49 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.9/8.14.9) with ESMTP id tBGFIkYO088720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2015 17:18:46 +0200 (EET) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: "libssl.so.8" not found From: Daniel Kalchev In-Reply-To: <20151214153517.GB49345@corpmail.liquidneon.com> Date: Wed, 16 Dec 2015 17:18:51 +0200 Cc: Warner Losh , Ronald Klop , freebsd-arm , Matthias Apitz , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151214071840.GA3771@c720-r285885-amd64> <20151214153517.GB49345@corpmail.liquidneon.com> To: Brad Davis X-Mailer: Apple Mail (2.3112) 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: Wed, 16 Dec 2015 15:48:51 -0000 > On 14.12.2015 =D0=B3., at 17:35, Brad Davis wrote: >=20 >=20 > Or just use pkg-static. :) >=20 I always wondered, why pkg is not static ONLY. That eliminates the = chicken/egg dilemma.=20 Yes, you eliminate the friendly reminder that your system is out of sync = with the FreeBSD package building platforms, but still=E2=80=A6 Daniel= From owner-freebsd-arm@freebsd.org Wed Dec 16 17:17:23 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 B03CAA49A32 for ; Wed, 16 Dec 2015 17:17:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B34D1EC1 for ; Wed, 16 Dec 2015 17:17:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tBGHHL6O037582; Wed, 16 Dec 2015 09:17:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tBGHHLjB037581; Wed, 16 Dec 2015 09:17:21 -0800 (PST) (envelope-from fbsd) Date: Wed, 16 Dec 2015 09:17:21 -0800 From: bob prohaska To: Konstantin Belousov Cc: freebsd-arm@freebsd.org Subject: Re: No space left in lost+found Message-ID: <20151216171721.GC29187@www.zefox.net> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> <1450209274.4299.468358681.22757635@webmail.messagingengine.com> <1450211241.25138.75.camel@freebsd.org> <20151216074321.GO3625@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216074321.GO3625@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i 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: Wed, 16 Dec 2015 17:17:23 -0000 Hi Konstantin, On Wed, Dec 16, 2015 at 09:43:21AM +0200, Konstantin Belousov wrote: > > Returning to the OP problem, please show the output of > ls -ld your/lost+found After a fresh rebuild and two passes of fsck -fy the system reports root@www:~ # ls -ld /tmp drwxrwxrwt 15 root wheel 3584 Dec 16 08:13 /tmp and root@www:~ # ls -ld /tmp/lost+found drwx------ 547 bob wheel 364544 Sep 1 20:10 /tmp/lost+found root@www:~ # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mmcsd0s2a 7031260 2327656 4141104 36% / devfs 1 1 0 100% /dev /dev/mmcsd0s1 51128 7332 43796 14% /boot/msdos /dev/da0p4 1279260 35500 1141420 3% /tmp /dev/da0p3 29442460 18778412 8308652 69% /usr /dev/da0p1 4053308 156140 3572904 4% /var so the filesystem does not appear full. However, fsck still reports messages of the form UNREF DIR I=82723 OWNER=bob MODE=40777 SIZE=512 MTIME=Dec 10 10:43 2015 RECONNECT? yes SORRY. NO SPACE IN lost+found DIRECTORY UNEXPECTED SOFT UPDATE INCONSISTENCY It turns out that /tmp/lost+found contains many files: root@www:/tmp/lost+found # ls | wc -w 22782 Seems like most of them should have been cleaned up automatically at some point in the past. That by itself appears odd, if not wrong. There have been no "out of inodes" messages. Journaling was turned off before the last OS build/install cycle. Build time remains about 16 hours, no other obvious effects. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Dec 17 07:07:58 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 C9EF6A49B9C for ; Thu, 17 Dec 2015 07:07:58 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C78C1E0B for ; Thu, 17 Dec 2015 07:07:58 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by mail-ig0-x22a.google.com with SMTP id jw2so5212798igc.1 for ; Wed, 16 Dec 2015 23:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=P6eoFGA3V7s2bJNfegzFSqb6nFrskQklzfemafa7FDA=; b=cj8QhJ9UEWRVH0rn2af65j5kMe8DNkCphsve0EWkd2rywEl6aEjBAmuSEepW0YLs7V L8D2AqGDpfIdGvUIfactA4guAa1j2DXTbmfCQO9X+k4TxtAIMxR0oFhRMaO6uMiPFPBh LkuRRf4ecK5uPXPylhODYPG96vWl2cGsSOHv4nx11D6MNSbe1mJWAZO5isGGlZrmk5W/ 2mi2Pd7vw+X79bO28nNhNjXm4YBVPbNnIl08Abejld4sOVzGh+ojBhKQCxYxnr8HBjsw RcpnDUPCT5uaGdlya2PDZ6pdTU9mNXP6VQhlRvcreEY6H7TvkXG/VT1YfgFVKvOV4ABr WybQ== MIME-Version: 1.0 X-Received: by 10.50.142.9 with SMTP id rs9mr2135743igb.76.1450336078088; Wed, 16 Dec 2015 23:07:58 -0800 (PST) Received: by 10.107.51.213 with HTTP; Wed, 16 Dec 2015 23:07:58 -0800 (PST) Date: Thu, 17 Dec 2015 15:07:58 +0800 Message-ID: Subject: I cannot boot my RPI 2 with latest snapshot From: RayCherng Yu To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Thu, 17 Dec 2015 07:07:59 -0000 I download the latest snapshot to boot my RPI2. I gor this massage: http://imgur.com/UUyKuYQ I have tried another image (20151119) and it didn't work, either . Raspbian work fine in this sd card(Kinston 64g). Anyone has the same problem? I don't have a HDMI screen, this screenshot is taken from my LED TV with hdmi to d-sub. --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. From owner-freebsd-arm@freebsd.org Thu Dec 17 07:54:28 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 2B89BA494E3 for ; Thu, 17 Dec 2015 07:54:28 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 10E5D1127 for ; Thu, 17 Dec 2015 07:54:28 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=tBX4JbrLMSPw7L3fSwsNno4y2Z3mMEzCUg/M5yWRZVo=; b=Y5RBfzfYUq9lulsIDreAiEu4DQ kPc33p25ySKcWCraIzYRBZhDzCKaazBAhtCrTAkTUIDUS4eHAejH4lIQIPojtPaYWZBr5NPUHOZ+u 3D9BFbSwlN9FFGEotKhODlS5mf0rK9JGhafAstNTQskQx5HXnEeodaarG5ku3nohnBUg=; Received: from [39.253.72.222] (port=64280 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1a9TOM-001dWV-0P; Thu, 17 Dec 2015 00:54:26 -0700 Date: Thu, 17 Dec 2015 15:18:50 +0800 From: Erich Dollansky To: RayCherng Yu Cc: freebsd-arm@freebsd.org Subject: Re: I cannot boot my RPI 2 with latest snapshot Message-ID: <20151217151850.359ce4c0@X220.alogt.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: 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: Thu, 17 Dec 2015 07:54:28 -0000 Hi, On Thu, 17 Dec 2015 15:07:58 +0800 RayCherng Yu wrote: > I download the latest snapshot to boot my RPI2. > > I gor this massage: > > http://imgur.com/UUyKuYQ > > > I have tried another image (20151119) and it didn't work, either . r291495 works for me. Erich From owner-freebsd-arm@freebsd.org Thu Dec 17 08:07:43 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 C8D3EA48004 for ; Thu, 17 Dec 2015 08:07:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BC491773 for ; Thu, 17 Dec 2015 08:07:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id e126so47056821ioa.1 for ; Thu, 17 Dec 2015 00:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=PGZThj0KeIyN3CrHevjjKe7BMMckJ27xhN+muu91/bk=; b=wxlyMLzNz+PjuNfjj6mi5EGiz+GqBCsA1ja6ofuV/xzfuV1evz8H1T2iwE1mpptMPU nLmNRn9BD2Y1dCVZrB/rhYNsIMmtet8clYEo+PDDUuWepML60KbjPZJiz3NyPOaEKlx0 tVCfPduZfKVqCcGy1Z2aC5Gx/JVKWTimiWc7QzZGc99BVHr9a/SbMSKIg5WXbnafyDlA WKkcJrdIlvh4z+H16VZj/5bdQ1aFkOT3w5/hWUiOR/mD6hfvqwTU5TMB4yk6/Yk0FjpO Nsw1rxXUabZ5F3+Yx7E60G85gFndKXLK/ONg+oWNVVxUwPkUhHdSYOrl21SbXLKJoPf2 ssXA== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr42844065ioe.123.1450339663081; Thu, 17 Dec 2015 00:07:43 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.121.202 with HTTP; Thu, 17 Dec 2015 00:07:42 -0800 (PST) Date: Thu, 17 Dec 2015 00:07:42 -0800 X-Google-Sender-Auth: V_mhLrTDJFnhbHR3k_otlb6laWo Message-ID: Subject: RFC: migrate arm/arm/intrng.c -> kern/subr_intr.c in prep for MIPS using it From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 17 Dec 2015 08:07:43 -0000 Hi, kan@ has been working on bringing in support for the CI20 board - where he used the arm intrng code in his mips port. So, I figured it is a good time to migrate the arm code into a generic spot to be reused. Here's my initial port: http://people.freebsd.org/~adrian/arm/20151216-arm-intrng-generic-1.diff It: * moves the machdep bits into a separate file (arm/arm/machdep_intr.c); * move intrng.c into sys/kern/subr_intr.c; * rename the ARM_ -> INTR_, and arm_ -> intr_ symbols; * fix up a variety of consumers of said code. It's a WIP - I plan on doing the minimum needed to put it there so we can use the code for other ports, and not try to solve the "how do we integrate this cleanly into the existing interrupt code" problem. This intr sharing code should make kan's job a lot easier. :) Thanks! -a From owner-freebsd-arm@freebsd.org Thu Dec 17 11:58:06 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 38637A4A4D1 for ; Thu, 17 Dec 2015 11:58:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C404B1648 for ; Thu, 17 Dec 2015 11:58:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tBHBvsr5098912 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Dec 2015 13:57:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBHBvsr5098912 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBHBvr9b098911; Thu, 17 Dec 2015 13:57:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Dec 2015 13:57:53 +0200 From: Konstantin Belousov To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: No space left in lost+found Message-ID: <20151217115753.GZ3625@kib.kiev.ua> References: <20151215181047.GA29187@www.zefox.net> <1450204738.4176380.468287977.048387B9@webmail.messagingengine.com> <20151215191845.GB29187@www.zefox.net> <1450209274.4299.468358681.22757635@webmail.messagingengine.com> <1450211241.25138.75.camel@freebsd.org> <20151216074321.GO3625@kib.kiev.ua> <20151216171721.GC29187@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216171721.GC29187@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Thu, 17 Dec 2015 11:58:06 -0000 On Wed, Dec 16, 2015 at 09:17:21AM -0800, bob prohaska wrote: > Hi Konstantin, > > On Wed, Dec 16, 2015 at 09:43:21AM +0200, Konstantin Belousov wrote: > > > > Returning to the OP problem, please show the output of > > ls -ld your/lost+found > > After a fresh rebuild and two passes of fsck -fy the system reports > > root@www:~ # ls -ld /tmp > drwxrwxrwt 15 root wheel 3584 Dec 16 08:13 /tmp > and > root@www:~ # ls -ld /tmp/lost+found > drwx------ 547 bob wheel 364544 Sep 1 20:10 /tmp/lost+found > > root@www:~ # df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/mmcsd0s2a 7031260 2327656 4141104 36% / > devfs 1 1 0 100% /dev > /dev/mmcsd0s1 51128 7332 43796 14% /boot/msdos > /dev/da0p4 1279260 35500 1141420 3% /tmp > /dev/da0p3 29442460 18778412 8308652 69% /usr > /dev/da0p1 4053308 156140 3572904 4% /var > > so the filesystem does not appear full. However, fsck still > reports messages of the form > > UNREF DIR I=82723 OWNER=bob MODE=40777 > SIZE=512 MTIME=Dec 10 10:43 2015 > RECONNECT? yes > > SORRY. NO SPACE IN lost+found DIRECTORY > UNEXPECTED SOFT UPDATE INCONSISTENCY > > It turns out that /tmp/lost+found contains many files: > root@www:/tmp/lost+found # ls | wc -w > 22782 > Seems like most of them should have been cleaned up automatically > at some point in the past. That by itself appears odd, if not wrong. > There have been no "out of inodes" messages. Nothing 'should' clean /lost+found automatically. It is your files, same as the files linked under other directories. I doubt that you want your files be automatically cleaned, and even in case you want, others don't. AFAIR (I did not rechecked this) fsck does not auto-expand the /lost+found directory. > > Journaling was turned off before the last OS build/install cycle. > Build time remains about 16 hours, no other obvious effects. > > Thanks for reading! > > bob prohaska From owner-freebsd-arm@freebsd.org Thu Dec 17 13:10: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 A3384A4ACD9 for ; Thu, 17 Dec 2015 13:10:40 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7669E11A6; Thu, 17 Dec 2015 13:10:40 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: by mail-io0-x235.google.com with SMTP id 186so55131194iow.0; Thu, 17 Dec 2015 05:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LRPpyZKBEV+/7L8ER/GBdiG+xQAHG7EScepVj5ddasU=; b=HuAAShr7qRTd2ggGOXDitDnRTlE/437RRrP10C3ZZRBE0IZ7Umdejb+cLdpbrP9qat aY3vQ0UTbXwHjF7iezsCcC4c7E2K7oxofZPTXDhk+nw4HDhTTo/lP4NtkqWpsoKhSBAz /NFDRe6WQWvre4xEwckM8zy8quOnSEeXRbMG500faMn+q7iwXKpqbJYqynA+eZLdG8i1 TRotrOdOCiee7+JOxmWsso+Zrf97B6B7ojeCGb/9RYxwzC7rOfjY8CFYJWTwnbP8/5KV SwTF9B7YJzfgc99+o8jX2M9BWqCkigKOwZaNC2JNXneM6wYfyl9vgW3N277VGefnmjxE kh+g== MIME-Version: 1.0 X-Received: by 10.107.26.83 with SMTP id a80mr22319577ioa.30.1450357839839; Thu, 17 Dec 2015 05:10:39 -0800 (PST) Received: by 10.64.130.38 with HTTP; Thu, 17 Dec 2015 05:10:39 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 14:10:39 +0100 Message-ID: Subject: Re: RFC: migrate arm/arm/intrng.c -> kern/subr_intr.c in prep for MIPS using it From: Svatopluk Kraus To: Adrian Chadd Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 17 Dec 2015 13:10:40 -0000 Just some suggestions about renaming. arm_irqsrc -> intr_src or intr_source ARM_ISRCT_xyz -> INTR_SRCT_xyz ARM_ISRCF_xyz -> INTR_SRCF_xyz ARM_ISRC_NAMELEN -> INTR_SRC_NAMELEN sys/arm/arm/machdep_intr.c ... remove unneeded headers? sys/conf/files.arm ... rename arm_intrng option And FYI, the framework needs some more love. Svata On Thu, Dec 17, 2015 at 9:07 AM, Adrian Chadd wrote: > Hi, > > kan@ has been working on bringing in support for the CI20 board - > where he used the arm intrng code in his mips port. > > So, I figured it is a good time to migrate the arm code into a generic > spot to be reused. > > Here's my initial port: > > http://people.freebsd.org/~adrian/arm/20151216-arm-intrng-generic-1.diff > > It: > > * moves the machdep bits into a separate file (arm/arm/machdep_intr.c); > * move intrng.c into sys/kern/subr_intr.c; > * rename the ARM_ -> INTR_, and arm_ -> intr_ symbols; > * fix up a variety of consumers of said code. > > It's a WIP - I plan on doing the minimum needed to put it there so we > can use the code for other ports, and not try to solve the "how do we > integrate this cleanly into the existing interrupt code" problem. > > This intr sharing code should make kan's job a lot easier. :) > > Thanks! > > > -a > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Dec 17 17:21:08 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 720D7A49465 for ; Thu, 17 Dec 2015 17:21:08 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BF6A14D3 for ; Thu, 17 Dec 2015 17:21:08 +0000 (UTC) (envelope-from raycherng@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id q126so62223036iof.2 for ; Thu, 17 Dec 2015 09:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ewUdqfZkx+t2wmwYDuNaGuipv4j+t7I9NlpVYAnpWt8=; b=ePA0hcmjUpy1az+pEQYnUKngNEWayVyGQxFZ7s3byl9gzRKXXd/6Nd+SpjJu9gSEm2 eexKryIC9Z9Msu/4sEsSyDIH92emQcUlmzpAU45Q1/Epg5uT0yai//NqqDMdkt0W/XZL 016NhS01zOcYM8p5XwkrgvYgcv84dZCMwXWtTEgao4+eyKY5uCLLPJ/9iYY9evNUZ5qJ 66IoV8YiZbOfYkXbvmjS4ilvKaxlB7QEs8L+npimipQBN+7O/H5dwBgsKoPmKCYajREi AO6Abt/vsXJgWzKunQcPVeJwz8Yue26A1YqseSgJZKpbx9yHL4dGp38mGtOvoj/moggO CjhA== MIME-Version: 1.0 X-Received: by 10.107.152.3 with SMTP id a3mr48533336ioe.177.1450372867633; Thu, 17 Dec 2015 09:21:07 -0800 (PST) Received: by 10.107.51.213 with HTTP; Thu, 17 Dec 2015 09:21:07 -0800 (PST) In-Reply-To: <20151217151850.359ce4c0@X220.alogt.com> References: <20151217151850.359ce4c0@X220.alogt.com> Date: Fri, 18 Dec 2015 01:21:07 +0800 Message-ID: Subject: Re: I cannot boot my RPI 2 with latest snapshot From: RayCherng Yu To: Erich Dollansky Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Thu, 17 Dec 2015 17:21:08 -0000 I change the sd card to SanDisk 8g and it works now. But the Kinston 64g microSDXC work with Raspbian....FreeBSD doesn't work ....:-( 2015-12-17 15:18 GMT+08:00 Erich Dollansky : > Hi, > > On Thu, 17 Dec 2015 15:07:58 +0800 > RayCherng Yu wrote: > > > I download the latest snapshot to boot my RPI2. > > > > I gor this massage: > > > > http://imgur.com/UUyKuYQ > > > > > > I have tried another image (20151119) and it didn't work, either . > > > r291495 works for me. > > Erich > --=20 "Life is like a snowball. The important thing is finding wet snow and a really long hill." "Price is what you pay. Value is what you get." "The first rule of Investing is don't lose money; the second rule is don't forget rule #1..." "Wall Street is the only place that people ride to work in a Rolls-Royce to get advice from those who take the subway..." =E2=80=94 Warren Buffett. From owner-freebsd-arm@freebsd.org Thu Dec 17 22:35:55 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 B28DEA4B4E5 for ; Thu, 17 Dec 2015 22:35:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 97D361F16 for ; Thu, 17 Dec 2015 22:35:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=+DG2GV/eY2C0DqxO/6RMBsPoFH85TwwQYhHVLjuaJNE=; b=R0GkCJXXEe+e+9auDfTxR40dZ7 NS9suAi8sXTHWJlAUkUVyChbM28LwBtLrvjfUdnRMLu/6eAbbvht9dNbTA7Re1+ECDxLuGcHP2hfQ ei6NbZX/hUOYfo5tuIykB+UtchDE43yfAK+e2OoCwRp2EYzEQGC2QQRNkXognM30aECw=; Received: from [114.121.155.169] (port=41873 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1a9h9J-000kEk-1V; Thu, 17 Dec 2015 15:35:49 -0700 Date: Fri, 18 Dec 2015 05:42:31 +0800 From: Erich Dollansky To: RayCherng Yu Cc: freebsd-arm@freebsd.org Subject: Re: I cannot boot my RPI 2 with latest snapshot Message-ID: <20151218054231.2b1ff10a@X220.alogt.com> In-Reply-To: References: <20151217151850.359ce4c0@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: 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: Thu, 17 Dec 2015 22:35:55 -0000 > Hi, On Fri, 18 Dec 2015 01:21:07 +0800 RayCherng Yu wrote: > I change the sd card to SanDisk 8g and it works now. > But the Kinston 64g microSDXC work with Raspbian....FreeBSD doesn't > work ....:-( > there are some threads here saying the same. SanDisk and Samsung works for me. Erich > 2015-12-17 15:18 GMT+08:00 Erich Dollansky > : > > > Hi, > > > > On Thu, 17 Dec 2015 15:07:58 +0800 > > RayCherng Yu wrote: > > > > > I download the latest snapshot to boot my RPI2. > > > > > > I gor this massage: > > > > > > http://imgur.com/UUyKuYQ > > > > > > > > > I have tried another image (20151119) and it didn't work, > > > either . > > > > > > r291495 works for me. > > > > Erich > > > > From owner-freebsd-arm@freebsd.org Thu Dec 17 23:03:20 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 D002AA492B0 for ; Thu, 17 Dec 2015 23:03:20 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [220.233.87.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D03A10CA for ; Thu, 17 Dec 2015 23:03:19 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id tBHMvaWa003344 for ; Fri, 18 Dec 2015 09:57:36 +1100 (AEDT) (envelope-from freebsd-arm@sentry.org) Subject: Re: I cannot boot my RPI 2 with latest snapshot Cc: freebsd-arm@freebsd.org References: <20151217151850.359ce4c0@X220.alogt.com> <20151218054231.2b1ff10a@X220.alogt.com> From: Trev Message-ID: <56733DE0.3020807@sentry.org> Date: Fri, 18 Dec 2015 09:57:36 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20151218054231.2b1ff10a@X220.alogt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (shadow.sentry.org [127.0.0.1]); Fri, 18 Dec 2015 09:57:36 +1100 (AEDT) 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: Thu, 17 Dec 2015 23:03:20 -0000 Erich Dollansky wrote: >> On Fri, 18 Dec 2015 01:21:07 +0800 >> RayCherng Yu wrote: >> >> I change the sd card to SanDisk 8g and it works now. >> But the Kinston 64g microSDXC work with Raspbian....FreeBSD doesn't >> work ....:-( > there are some threads here saying the same. SanDisk and Samsung works > for me. Kingston - fail; SanDisk and Patriot - work for me. From owner-freebsd-arm@freebsd.org Thu Dec 17 23:26:51 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 022BEA4A228 for ; Thu, 17 Dec 2015 23:26:51 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 801F71EE5 for ; Thu, 17 Dec 2015 23:26:49 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id tBHNQjTS074360 for ; Fri, 18 Dec 2015 00:26:46 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Fri, 18 Dec 2015 00:26:42 +0100 (CET) Message-ID: <4767139884d.26a8636a@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: reverted behavior with debug file creation MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Fri, 18 Dec 2015 00:26:47 +0100 (CET) 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: Thu, 17 Dec 2015 23:26:51 -0000 FYI, if you run into the same problem. I was wondering why I have less disk space after a buildworld install, after searching I found a lot of debug files in /usr/lib/debug/. The reason for this is, the behavier of the debug file creation was changed. Instead to enable it with WITH_DEBUG_FILES in /etc/src.conf you have to disable it with WITHOUT_DEBUG_FILES. This is mentioned in /usr/src/UPDATING, but not in the manual for src.conf. best regards, Andreas From owner-freebsd-arm@freebsd.org Fri Dec 18 05:45:38 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 689BDA4B3A9 for ; Fri, 18 Dec 2015 05:45:38 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 3578F15D8 for ; Fri, 18 Dec 2015 05:45:37 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a9nCl-0005rp-9J for freebsd-arm@freebsd.org; Fri, 18 Dec 2015 05:03:47 +0000 Date: Fri, 18 Dec 2015 05:03:47 +0000 From: John To: freebsd-arm@freebsd.org Subject: asus chromebook C201P arm7 Message-ID: <20151218050347.GA22494@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: john 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: Fri, 18 Dec 2015 05:45:38 -0000 Hello list, Has anyone installed freebsd to a asus chromebook C201P yet? If so, I'd love to hear how you did it. What I'm looking to do is somehow dual-boot freebsd and chromium until I'm satisfied all is functional under freebsd. Or, to install arm to a usb stick and boot from that. At the moment, I'm using crouton which runs ubuntu in a chroot. Is there a way to run freebsd in a chromium chroot? thanks! -- John From owner-freebsd-arm@freebsd.org Fri Dec 18 09:01:54 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 A4306A4BF3B for ; Fri, 18 Dec 2015 09:01:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F11E17B7 for ; Fri, 18 Dec 2015 09:01:53 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1a9quy-0006Ei-0p for freebsd-arm@freebsd.org; Fri, 18 Dec 2015 10:01:45 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: asus chromebook C201P arm7 References: <20151218050347.GA22494@potato.growveg.org> Date: Fri, 18 Dec 2015 10:01:36 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <20151218050347.GA22494@potato.growveg.org> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Scan-Signature: 739ba1b2be5fabc1cc6069058737919f 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: Fri, 18 Dec 2015 09:01:54 -0000 On Fri, 18 Dec 2015 06:03:47 +0100, John wrote: > Hello list, > > Has anyone installed freebsd to a asus chromebook C201P yet? If so, > I'd love to hear how you did it. > > What I'm looking to do is somehow dual-boot freebsd and chromium until > I'm satisfied all is functional under freebsd. Or, to install arm to a > usb stick and boot from that. At the moment, I'm using crouton which > runs ubuntu in a chroot. Is there a way to run freebsd in a chromium > chroot? > > thanks! I don't know, but does this help? https://wiki.freebsd.org/FreeBSD/arm/Chromebook Ronald. From owner-freebsd-arm@freebsd.org Fri Dec 18 13:18: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 7DC0AA4BB51 for ; Fri, 18 Dec 2015 13:18:40 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from potato.growveg.org (potato.growveg.org [62.49.247.163]) (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 44864129B for ; Fri, 18 Dec 2015 13:18:40 +0000 (UTC) (envelope-from john@potato.growveg.org) Received: from john by potato.growveg.org with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a9uvc-0006Or-QD for freebsd-arm@freebsd.org; Fri, 18 Dec 2015 13:18:36 +0000 Date: Fri, 18 Dec 2015 13:18:36 +0000 From: John To: freebsd-arm@freebsd.org Subject: Re: asus chromebook C201P arm7 Message-ID: <20151218131836.GA24558@potato.growveg.org> Reply-To: freebsd-arm@freebsd.org Mail-Followup-To: freebsd-arm@freebsd.org References: <20151218050347.GA22494@potato.growveg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: john 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: Fri, 18 Dec 2015 13:18:40 -0000 On Fri, Dec 18, 2015 at 10:01:36AM +0100, Ronald Klop wrote: >I don't know, but does this help? Hi, Bits of it do, but that page is from a year or so ago and freebsd-arm is a fast moving target. Also it seems highly specific to that particular samsung chromebook whereas this is an acer c201p. Basically what I *think* I need to do is this: 1. cross-compile arm7 on another machine 2. install to a usb stick 3. boot the chromebook from that stick in order to test to make sure everything works. then decide whether to install or not. I think the article you linked to might be old, for example the bit about wifi, whereas I beleive this one has atheros wifi chip so it *should* work. -- John From owner-freebsd-arm@freebsd.org Fri Dec 18 18:18:39 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 7AFC7A49EFC for ; Fri, 18 Dec 2015 18:18:39 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4609114E3 for ; Fri, 18 Dec 2015 18:18:38 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450462711; bh=UEgKf0u9cqzK4qEybSc2dP1jNw5Evzgg42iVlpw+Cu0=; h=From:Subject:Date:Cc:To:From:Subject; b=t9L/xzgp+/+ZjriRo8yQ7Z1oOcs2WcnsM7X95dQHddQ+L/RS3mA+2HFIvwvXp0/G3wPtVI2KWIamOlvaNWY/BxPF3bWMujFlNH6jIkAvu0zwtKBUPv++3ExnOHtXWzrR3ONc9zzQvY4x+ENwTP0xa3UJ4udxQAhpwzp4unkKr6MvpINyLYn6ty2fq0yPNuf/ZcBVQuaQgc6LSvMUYkTcMu+jQ6CuKdmVt1EdZAjoHn0I11eWwqSIrYqo02SUM8Bmti5mNBKuhZDHKvkIvVx38jQIV2+HCZMi8adTQPfWNib9XPmMgtOg0urB8uMkGPCoXfWFEx13X7HkvSgozUXzKQ== Received: from [98.139.215.143] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 18:18:31 -0000 Received: from [98.139.211.207] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 18:18:31 -0000 Received: from [127.0.0.1] by smtp216.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 18:18:31 -0000 X-Yahoo-Newman-Id: 950016.42354.bm@smtp216.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tpegt6IVM1k6BRel9H9GpP3eIkruuQK3mq6._rWCvcUKDbZ jZFycyHJgiiAhaAYdD68Dm9NGzEXTKA4XgEUGvCcUGBuhFiY2BgTKXLwaVNz soonyBzk9jWDtY3Kir61qnH4KJtJjWawrwi.9gqHie52EjfVpnKlUCQwoN8s a2LESxWrv54KjXbZUbeBwZcodWR3Y_IicQcIkLoYkESFR6QXdpKXZ8zFrfN. vwEbZwxQjW7FQGhgrlaxK9Sska5xqElcbPm1Vb.MRjNIKl0mk2BKXmQU37YT 8Y7.f.oNTQ0M5PqjgzF79.VEmQI7BqLhVO0M0l6et6PTnD1tW5uB0aIjUlFY CQeMeBGnHu7XRMD4qf5Mk4WaxDsErui97bnjLCa2ptbB5gwn16msgnCNxNur NY1a6WaQ_o6vcr0EOA4Kbw7J.oQtoODqtMPtTunLvi4r_HSG_gbzEqzetIO3 Lwfgie_VdQEGeXTSfrRFG7AR7ix5cBlqahO_hBlDVBsBJipoAhCkd4bE6HG6 pV0mvTlZXMMK.TUQ11FMyn69m0Co.VhMVvL74 X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: u-boot and ubldr on arm64 Date: Fri, 18 Dec 2015 10:18:30 -0800 Message-Id: <5695944F-A052-4959-8F9A-ACD4CD3413D6@yahoo.com> Cc: Thomas Skibo To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) 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: Fri, 18 Dec 2015 18:18:39 -0000 Hello. I=E2=80=99ve been taking a stab at getting an arm64 kernel running on = qemu acting as a Zynq Ultrascale evaluation board. The first hurdle was = getting the u-boot API and ubldr to compile and run in 64-bit mode. = I=E2=80=99ve managed to get that much to work and wanted to let you know = in case this is interesting and I can share the code. Or, so you can = tell me that u-boot/ubldr is the wrong approach. In any case, here=E2=80=99s how far it boots. The next step is to whip = my kernel configuration into shape but I may have to put this aside = until after the holidays. Cheers, =E2=80=94Thomas =E2=80=94 Thomas Skibo thomasskibo@yahoo.com Script started on Fri 18 Dec 2015 09:34:49 AM PST skibo@robleda:~/Projects/Zynq/qemu$ source GO.txt=20 WARNING: Image format was not specified for '../debug.qemu/SDCARD.img' = and probing guessed raw. Automatically detecting the format is dangerous for raw images, = write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. QEMU 2.4.93 monitor - type 'help' for more information (qemu) c=1B[K (qemu)=20 U-Boot 2015.07-00006-gd3fba7f-dirty (Dec 18 2015 - 09:30:17 -0800) = Xilinx ZynqMP I2C: ready DRAM: 1 GiB Enabling Caches... EL Level: EL1 NAND: ERROR:arasan_nand_reset timedout ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT arasan_nand_init: nand_scan_ident failed NAND init failed 0 MiB MMC: zynq_sdhci: 0 Using default environment In: serial Out: serial Err: serial Bootmode: JTAG_MODE SCSI: SATA link 0 timeout. AHCI 0001.0000 32 slots 2 ports 1.5 Gbps 0x3 impl SATA mode flags: ncq only=20 scanning bus for devices... Found 0 device(s). Net: Gem.ff0b0000 Hit any key to stop autoboot: 5 =08=08=08 0=20 ZynqMP> fatls mmc 0 254704 ubldr=20 172 uenv.txt=20 160405 demo=20 1408 board.dtb=20 4 file(s), 0 dir(s) ZynqMP> fatload mmc 0 0x1000000 ubldr reading ubldr 254704 bytes read in 72 ms (3.4 MiB/s) ZynqMP> setenv fdt_file board.dtb ZynqMP> bootelf 0x1000000 ## Starting application at 0x010000b0 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @3df02860 FreeBSD/aarch64 U-Boot loader, Revision 1.2 (skibo@ashbury, Fri Dec 18 09:33:17 PST 2015) DRAM: 1024MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: = |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/boot/kernel/kernel data=3D0x5ead28+0x2f4620 = /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08syms=3D[0x8+0xc0120-=08\=08|=08= /=08-=08\=08+0x8+0xbde15|=08/=08-=08\=08|=08/=08] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting = [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel] in 7 = seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. loader> boot -v =1B[37m=1B[44mBooting...=1B[m \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/boot/kernel/board.dtb = size=3D0x580 Loaded DTB from file 'board.dtb'. /=08-=08\=08|=08/=08Kernel entry at 0x0x1201000... Kernel args: -v KDB: debugger backends: ddb KDB: current backend: ddb No CPU data, limiting to 1 core Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #11 r292424M: Fri Dec 18 01:16:09 PST 2015 skibo@ashbury:/usr/obj/arm64.aarch64/usr/src/sys/EP108 arm64 FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffff8000a61000. Preloaded dtb "/boot/kernel/board.dtb" at 0xffffff8000a61a28. CPU(0): ARM Cortex-A53 r0p4 CPU0 affinity: 0.0.0.0 FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs ULE: setup cpu 0 random: entropy device external interface null: openfirm: mem: nfslock: pseudo-device crypto: random: harvesting attach, 8 bytes (4 bits) from nexus0 ofwbus0: simplebus0: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from simplebus0 simplebus1: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from simplebus1 random: harvesting attach, 8 bytes (4 bits) from ofwbus0 gic0: mem = 0xf9010000-0xf901ffff,0xf902f000-0xf9030fff,0xf9040000-0xf905ffff,0xf906f0= 00-0xf9070fff on simplebus0 gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 192 random: harvesting attach, 8 bytes (4 bits) from gic0 uart0: mem 0xff000000-0xff000fff irq 53 on simplebus1 uart0: console (115200,n,8,1) uart0: fast interrupt uart0: PPS capture mode 2 (DCD) random: harvesting attach, 8 bytes (4 bits) from uart0 uart1: mem 0xff010000-0xff010fff irq 54 on simplebus1 uart1: fast interrupt uart1: PPS capture mode 2 (DCD) random: harvesting attach, 8 bytes (4 bits) from uart1 simplebus1: mem 0xff0b0000-0xff0b0fff irq 89,89 = compat cadence,gem (no driver attached) cryptosoft0: crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 Device configuration finished. procfs registered panic: No usable event timer found! cpuid =3D 0 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffffff80004460b4 lr =3D 0xffffff800004eaf8 sp =3D 0xffffff800000b8e0 fp =3D 0xffffff800000ba00 db_trace_self_wrapper() at vpanic+0x170 pc =3D 0xffffff800004eaf8 lr =3D 0xffffff80001c9088 sp =3D 0xffffff800000ba10 fp =3D 0xffffff800000ba90 vpanic() at panic+0x4c pc =3D 0xffffff80001c9088 lr =3D 0xffffff80001c9118 sp =3D 0xffffff800000baa0 fp =3D 0xffffff800000bb20 panic() at cpu_initclocks_bsp+0x3b4 pc =3D 0xffffff80001c9118 lr =3D 0xffffff800045bff8 sp =3D 0xffffff800000bb30 fp =3D 0xffffff800000bb80 cpu_initclocks_bsp() at initclocks+0x28 pc =3D 0xffffff800045bff8 lr =3D 0xffffff8000171994 sp =3D 0xffffff800000bb90 fp =3D 0xffffff800000bb90 initclocks() at mi_startup+0x11c pc =3D 0xffffff8000171994 lr =3D 0xffffff800016ea90 sp =3D 0xffffff800000bba0 fp =3D 0xffffff800000bbd0 mi_startup() at virtdone+0x5c pc =3D 0xffffff800016ea90 lr =3D 0xffffff800000108c sp =3D 0xffffff800000bbe0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x40: db>=20 From owner-freebsd-arm@freebsd.org Fri Dec 18 18:46:15 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 5E193A4C0DA for ; Fri, 18 Dec 2015 18:46:15 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (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 06FB9176A for ; Fri, 18 Dec 2015 18:46:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id DDD162284CA for ; Fri, 18 Dec 2015 12:46:07 -0600 (CST) Subject: Re: Mp3 player (or other sound player) on RPI2? References: <567095B8.90504@denninger.net> <20151216083734.GJ78415@e-new.0x20.net> To: "freebsd-arm@freebsd.org" From: Karl Denninger Message-ID: <5674546B.2080203@denninger.net> Date: Fri, 18 Dec 2015 12:46:03 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151216083734.GJ78415@e-new.0x20.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090603080900000502090303" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Fri, 18 Dec 2015 18:46:15 -0000 This is a cryptographically signed message in MIME format. --------------ms090603080900000502090303 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/16/2015 02:37, Lars Engels wrote: > On Tue, Dec 15, 2015 at 04:35:36PM -0600, Karl Denninger wrote: >> Mpg123 apparently has a bad incompatibility with the desired bitrate o= n >> the default audio interface and produces only noise. "Espeak" works..= =2E. >> but I'd like to be able to play a Mp3 file..... is there a command-lin= e >> tool that works on the Rpi/Rpi2? > You could give audio/mpg321 a try. That is working. Now if I can find the problem with the DMA system that kills audio at random after a while.... (the only way to clear it is a reboot.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090603080900000502090303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTgxODQ2MDNaME8GCSqGSIb3DQEJBDFCBEAM +iB0WU+d2V+z/bUj5JEagip9CShrtzHsfHdifzV3wVjNvbHy2zOW81Gh2+rv7jDivT54GZdc D9DH1Agau2MFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAJyKpe8pt hACO8UAFolK1Jji42HurXBT38J4ZPVrPxLKDp8xrPf2o2/etA+RNCLW06ssKW8J+2kyeBJcW OSVbPh55ENpa3MAwlWdGRplGGu6lBGiyuX0rF57QZWZkxZqot4GvCFZRML0ppSzEgdzz2Zws AVPf/yVqG18HX6C/h3yezL9poMwlgdDznGXgEeWnM1wDQRGrkzRnpmiDF19UHJP1g4V86j7K UgFSODH1uR+8bLdpTcvTKL102EUlEhdNvIoxu0T1Pv+beoVCvQvkyd/pGU5qqK6EkIdFZ/zp hfair/GRjBIv98GdPubLlgnpuHAZLSO6astkfXNWXozUIGnJEoOeE0gxcQEj9fpTR1Maa0FK XLQek+YjiTLJ47LPAKTFw3sqSY2jAqBGqmYb9OtKvn7h3ttavBUvMbssy5dMqbeA4UkSy16H 9UZuZ0PckJANjUcl2qGKOUwmfvT6cvBsqAka6K87Q2DpgYZ7cSH3rsTp6TR8h+eE9bYFEzYy Z3AqK1QQ6RpCNXuHnapFl99rWe9JRvdifZRWtZBXZZjF6TI5hFcvibyKkc65FHIyXny8/Fxb ASNmKYpNaX+S1DKzIz+iVxayKD3/tdgoP4xT6jz13a+4cupgsE00IOjX8XQuJcjOsWWIzd6T /JSBVnhZMZVQfMhpBcZi6ocGqgsAAAAAAAA= --------------ms090603080900000502090303-- From owner-freebsd-arm@freebsd.org Fri Dec 18 22:57:50 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 702EDA4BA2E for ; Fri, 18 Dec 2015 22:57:50 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm34-vm7.bullet.mail.bf1.yahoo.com (nm34-vm7.bullet.mail.bf1.yahoo.com [72.30.239.79]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AE3A19C6 for ; Fri, 18 Dec 2015 22:57:49 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450479357; bh=vA6qZhHXoHql89VfB+Km1P1qvdhnR6Hy06KjDNapy9Y=; h=From:Subject:Date:To:From:Subject; b=c0sR3Y2cGB5TzmxT27tlxoiaYT/NFfWVfoohx3bYESlAztmDzIQkPWs+K9Dfsoz5FOyV6RNWvi96dp4rTnzXBwRGyFnRA4vpYiPhvKAvYL5JkkADkoGvXljrFUNtsVc5sIDtzSItsxkRE9pa9d2eI2ygfOO+OkDkaurVELFTSRBE9bioK5l5z0cV/7nckGsJswvdCppk0xyubMESIuRIVTH0niIMQpIFRTE68+pfWdK/i8u3j/ah80I858nhCG5+QNng0BzKrZfo1aTanmYGv3vahLsi3cKkVc2d9hyxAnXxFbaCm/YZ8FY2YuaPudltPyCk8wWc4YXavSvI9ZoQUg== Received: from [98.139.215.140] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 22:55:57 -0000 Received: from [98.139.211.162] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 22:55:57 -0000 Received: from [127.0.0.1] by smtp219.mail.bf1.yahoo.com with NNFMP; 18 Dec 2015 22:55:57 -0000 X-Yahoo-Newman-Id: 422530.99386.bm@smtp219.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GQdg_boVM1l28PhaD9hOfWX2kgXgFrZjJ2Tl_SHmlcch.mU 6XLD24HSEza4aS7JiX751VdNzhQ_PBBMaGhI4U_Y1T6hviZJoUPlBgmTdCYM 3CHR7nMFshEPkXNbpM6jFKuXvyltCOYryml61KYD9A3nJqJZAgeJiZfadjSY pgHx1W81ghBxaR5w_xUIOry.bka22pqUSTrupQ7OGukISEYQKOIz6bck34.O crfVOsK3yN8CX2QmgiychxV4d4.9MBAoEULrnsi7UUHIi3KpNeeuaYXpnIeD npO.nFaJCvr5S_7n8dWaiN2CNCazUIuAroAX3ZdnfxLuuHDhD6pmuzJn5SXp Qmj7VfAnD3GBleDqhJVV0IsupAKBuq0HPWKj0dyJr7FO69iTTrB0jaPPlZHk 8d37CDjNsiuHBDKQqvw8NauauaZ.x_NqjWdDNDwJLnVInpPPY4alVqdzr7Wh AjolA831SwyiT_ddLTdBL8wOQwh1ThVJm_Z3zHG245BfQb2mQVckiG95kBT_ SB8i4qf7Ea9HEJtGXY9RcDWxrjvFIoBe.cKmXVg-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: u-boot and ubldr on arm64 Message-Id: Date: Fri, 18 Dec 2015 14:55:55 -0800 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) 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: Fri, 18 Dec 2015 22:57:50 -0000 Wow. That came together fast. It was only a matter of getting a few = drivers properly configured into the kernel and getting the right = entries in the device tree. Hats off to you guys working on the arm64 = implementation. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com FreeBSD booting on a simulated Zynq UltraScale =E2=80=A6 Script started on Fri 18 Dec 2015 02:36:06 PM PST =1B]0;skibo@robleda: = ~/Projects/Zynq/qemu=07skibo@robleda:~/Projects/Zynq/qemu$ source GO.txt=20= WARNING: Image format was not specified for '../debug.qemu/SDCARD.img' = and probing guessed raw. Automatically detecting the format is dangerous for raw images, = write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. QEMU 2.4.93 monitor - type 'help' for more information (qemu) c=1B[K (qemu)=20 U-Boot 2015.07-00006-gd3fba7f-dirty (Dec 18 2015 - 11:17:12 -0800) = Xilinx ZynqMP I2C: ready DRAM: 1 GiB Enabling Caches... EL Level: EL1 NAND: =20 ERROR:arasan_nand_reset timedout ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT ERROR:arasan_nand_read_buf timedout:Buff RDY ERROR:arasan_nand_read_buf timedout:Xfer CMPLT arasan_nand_init: nand_scan_ident failed NAND init failed 0 MiB MMC: zynq_sdhci: 0 Using default environment In: serial Out: serial Err: serial Bootmode: JTAG_MODE SCSI: SATA link 0 timeout. AHCI 0001.0000 32 slots 2 ports 1.5 Gbps 0x3 impl SATA mode flags: ncq only=20 scanning bus for devices... Found 0 device(s). Net: Gem.ff0b0000 Hit any key to stop autoboot: 5 =08=08=08 0=20 ZynqMP> fatload mmc 0 0x1000000 ubldr reading ubldr 254704 bytes read in 74 ms (3.3 MiB/s) ZynqMP> setenv fdt_file board.dtb ZynqMP> bootelf 0x1000000 ## Starting application at 0x010000b0 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @3df02860 FreeBSD/aarch64 U-Boot loader, Revision 1.2 (skibo@ashbury, Fri Dec 18 12:37:40 PST 2015) DRAM: 1024MB Number of U-Boot devices: 2 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk Probing all disk devices... Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: = |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08= -=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/boot/kernel/kernel data=3D0x5f4a28+0x2f4620 = /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08= |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08= \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08syms=3D[0x8+0xc1020\=08|=08= /=08-=08\=08|=08+0x8+0xbebb3/=08-=08\=08|=08/=08-=08] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting = [/boot/kernel/kernel]... =20 \=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/boot/kernel/board= .dtb size=3D0x716 Loaded DTB from file 'board.dtb'. /=08-=08\=08|=08Kernel entry at 0x0x1201000... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #13 r292424M: Fri Dec 18 14:30:15 PST 2015 skibo@ashbury:/usr/obj/arm64.aarch64/usr/src/sys/EP108 arm64 FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 WARNING: WITNESS option enabled, expect reduced performance. CPU(0): ARM Cortex-A53 r0p4 FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 gic0: mem = 0xf9010000-0xf901ffff,0xf902f000-0xf9030fff,0xf9040000-0xf905ffff,0xf906f0= 00-0xf9070fff on simplebus0 gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 192 generic_timer0: irq 29,30,27,26 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 20000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 20000000 Hz quality 1000 uart0: mem 0xff000000-0xff000fff irq 53 on simplebus1 uart0: console (115200,n,8,1) uart1: mem 0xff010000-0xff010fff irq 54 on simplebus1 cgem0: mem = 0xff0b0000-0xff0b0fff irq 89,89 on simplebus1 miibus0: on cgem0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto e1000phy1: PHY 23 on miibus0 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: Ethernet address: 00:0a:35:00:01:22 sdhci_fdt0: mem = 0xff160000-0xff160fff irq 80 on simplebus1 sdhci_fdt0: 1 slot(s) allocated mmc0: on sdhci_fdt0 sdhci_fdt1: mem = 0xff170000-0xff170fff irq 81 on simplebus1 sdhci_fdt1: 1 slot(s) allocated cryptosoft0: Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. mmcsd0: 1GB at mmc0 = 26.0MHz/4bit/65535-block Release APs APs not started WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... warning: no time-of-day clock registered, system time will not be set = accurately /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, = generating a new one Setting hostuuid: 4e162d3e-a5d7-11e5-8aa7-000a35000122. Setting hostid: 0x4f90b3ff. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 65088 free (24 frags, 8133 blocks, 0.0% = fragmentation) Mounting local file systems:random: unblocking device. . Setting hostname: ep108. Setting up = harvesting:[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,K= EYBOARD,ATTACH,CACHED Feeding entropy:. cgem0: link state changed to UP Starting Network: lo0 cgem0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 cgem0: flags=3D8843 metric 0 mtu = 1500 options=3D80008 ether 00:0a:35:00:01:22 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 ELF ldconfig path: /lib /usr/lib /usr/lib/compat Starting devd. Starting dhclient. DHCPDISCOVER on cgem0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 10.0.2.2 DHCPREQUEST on cgem0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 10.0.2.15 -- renewal in 43200 seconds. add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. Creating and/or trimming log files. Setting date via ntp. 18 Dec 22:38:59 ntpdate[411]: step time server 204.9.54.119 offset = -14.044636 sec Starting casperd. Clearing /tmp (X related). Updating motd:. Mounting late file systems:. Generating RSA1 host key. 2048 83:c8:bc:8c:44:42:d1:1f:54:ec:3c:5e:3e:35:b6:da root@ep108 (RSA1) Generating RSA host key. 2048 67:0e:ba:8b:ba:17:7f:5a:b3:ee:16:87:45:75:38:dd root@ep108 (RSA) Generating DSA host key. 1024 e9:68:09:85:a3:aa:b6:63:6b:ea:56:4e:c7:cc:f6:79 root@ep108 (DSA) Generating ECDSA host key. 256 07:95:21:95:89:8c:b7:f5:8e:b6:b7:5d:ad:3a:75:a0 root@ep108 (ECDSA) Generating ED25519 host key. 256 9b:45:c1:ad:ca:ee:97:d1:66:35:05:73:5c:04:21:d4 root@ep108 = (ED25519) Performing sanity check on sshd configuration. Starting sshd. Starting background file system checks in 60 seconds. Fri Dec 18 22:43:31 UTC 2015 FreeBSD/arm64 (ep108) (ttyu0) login: root FreeBSD 11.0-CURRENT (EP108) #13 r292424M: Fri Dec 18 14:30:15 PST 2015 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: = https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the = /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting = questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. root@ep108:~ # ifconfig cgem0: flags=3D8843 metric 0 mtu = 1500 options=3D80008 ether 00:0a:35:00:01:22 inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255=20 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 root@ep108:~ # ping 192.18.=08=1B[K=08=1B[K68.1.6 PING 192.168.1.6 (192.168.1.6): 56 data bytes ^C --- 192.168.1.6 ping statistics --- 9 packets transmitted, 0 packets received, 100.0% packet loss root@ep108:~ # netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire default 10.0.2.2 UGS cgem0 10.0.2.0/24 link#1 U cgem0 10.0.2.15 link#1 UHS lo0 localhost link#2 UH lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 localhost UGRS lo0 localhost link#2 UH lo0 ::ffff:0.0.0.0/96 localhost UGRS lo0 fe80::/10 localhost UGRS lo0 fe80::%lo0/64 link#2 U lo0 fe80::1%lo0 link#2 UHS lo0 ff02::/16 localhost UGRS lo0 root@ep108:~ # ping 10.0.2.2 PING 10.0.2.2 (10.0.2.2): 56 data bytes 64 bytes from 10.0.2.2: icmp_seq=3D0 ttl=3D255 time=3D17.714 ms 64 bytes from 10.0.2.2: icmp_seq=3D1 ttl=3D255 time=3D8.325 ms 64 bytes from 10.0.2.2: icmp_seq=3D2 ttl=3D255 time=3D19.037 ms 64 bytes from 10.0.2.2: icmp_seq=3D3 ttl=3D255 time=3D7.879 ms 64 bytes from 10.0.2.2: icmp_seq=3D4 ttl=3D255 time=3D16.681 ms 64 bytes from 10.0.2.2: icmp_seq=3D5 ttl=3D255 time=3D31.147 ms 64 bytes from 10.0.2.2: icmp_seq=3D6 ttl=3D255 time=3D10.499 ms 64 bytes from 10.0.2.2: icmp_seq=3D7 ttl=3D255 time=3D8.870 ms 64 bytes from 10.0.2.2: icmp_seq=3D8 ttl=3D255 time=3D22.995 ms 64 bytes from 10.0.2.2: icmp_seq=3D9 ttl=3D255 time=3D18.287 ms 64 bytes from 10.0.2.2: icmp_seq=3D10 ttl=3D255 time=3D8.224 ms 64 bytes from 10.0.2.2: icmp_seq=3D11 ttl=3D255 time=3D8.943 ms 64 bytes from 10.0.2.2: icmp_seq=3D12 ttl=3D255 time=3D7.763 ms 64 bytes from 10.0.2.2: icmp_seq=3D13 ttl=3D255 time=3D8.771 ms 64 bytes from 10.0.2.2: icmp_seq=3D14 ttl=3D255 time=3D7.967 ms ^C --- 10.0.2.2 ping statistics --- 15 packets transmitted, 15 packets received, 0.0% packet loss round-trip min/avg/max/stddev =3D 7.763/13.540/31.147/6.862 ms root@ep108:~ #=20 root@ep108:~ # sysctl -a | grep cgem dev.miibus.0.%parent: cgem0 dev.cgem.0.stats.rx_frames_udp_csum_errs: 0 dev.cgem.0.stats.rx_frames_tcp_csum_errs: 0 dev.cgem.0.stats.rx_frames_ip_hdr_csum_errs: 0 dev.cgem.0.stats.rx_overrun_errs: 0 dev.cgem.0.stats.rx_resource_errs: 0 dev.cgem.0.stats.rx_align_errs: 0 dev.cgem.0.stats.rx_symbol_errs: 0 dev.cgem.0.stats.rx_frames_length_errs: 0 dev.cgem.0.stats.rx_frames_fcs_errs: 0 dev.cgem.0.stats.rx_frames_jabber: 0 dev.cgem.0.stats.rx_frames_oversize: 0 dev.cgem.0.stats.rx_frames_undersize: 0 dev.cgem.0.stats.rx_frames_1024to1536b: 0 dev.cgem.0.stats.rx_frames_512to1023b: 1291 dev.cgem.0.stats.rx_frames_256to511b: 0 dev.cgem.0.stats.rx_frames_128to255b: 1187 dev.cgem.0.stats.rx_frames_65to127b: 9734 dev.cgem.0.stats.rx_frames_64b: 1069 dev.cgem.0.stats.rx_frames_pause: 0 dev.cgem.0.stats.rx_frames_multi: 0 dev.cgem.0.stats.rx_frames_bcast: 1291 dev.cgem.0.stats.rx_frames: 13321 dev.cgem.0.stats.rx_bytes: 8138301600956416 dev.cgem.0.stats.tx_carrier_sense_errs: 0 dev.cgem.0.stats.tx_deferred_frames: 0 dev.cgem.0.stats.tx_late_collisn: 0 dev.cgem.0.stats.tx_excsv_collisn: 0 dev.cgem.0.stats.tx_multi_collisn: 0 dev.cgem.0.stats.tx_single_collisn: 0 dev.cgem.0.stats.tx_under_runs: 0 dev.cgem.0.stats.tx_frames_1024to1536b: 0 dev.cgem.0.stats.tx_frames_512to1023b: 0 dev.cgem.0.stats.tx_frames_256to511b: 1293 dev.cgem.0.stats.tx_frames_128to255b: 0 dev.cgem.0.stats.tx_frames_65to127b: 12343 dev.cgem.0.stats.tx_frames_64b: 1713 dev.cgem.0.stats.tx_frames_pause: 0 dev.cgem.0.stats.tx_frames_multi: 0 dev.cgem.0.stats.tx_frames_bcast: 3006 dev.cgem.0.stats.tx_frames: 15349 dev.cgem.0.stats.tx_bytes: 7029916570746880 dev.cgem.0._txdefragfails: 0 dev.cgem.0._txdefrags: 0 dev.cgem.0._txdmamapfails: 0 dev.cgem.0._txfull: 0 dev.cgem.0._rxdmamapfails: 0 dev.cgem.0._rxnobufs: 0 dev.cgem.0._rxoverruns: 0 dev.cgem.0.rxhangwar: 1 dev.cgem.0.rxbufs: 256 dev.cgem.0.%parent: simplebus1 dev.cgem.0.%pnpinfo: name=3Dethernet@ff0b0000 compat=3Dcadence,gem dev.cgem.0.%location:=20 dev.cgem.0.%driver: cgem dev.cgem.0.%desc: Cadence CGEM Gigabit Ethernet Interface dev.cgem.%parent:=20 root@ep108:~ #=20 root@ep108:~ # ls .cshrc .k5login .login .profile root@ep108:~ # ls / .cshrc boot libexec root var .profile dev media sbin .snap entropy mnt sys COPYRIGHT etc proc tmp bin lib rescue usr root@ep108:~ # halt Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 0 done All buffers synced. lock order reversal: 1st 0xffffffc002a3fb78 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1224 2nd 0xffffffc002a3f5f0 syncer (syncer) @ = /usr/src/sys/kern/vfs_subr.c:2604 stack backtrace: #0 0xffffff8000221ec8 at witness_debugger+0x68 #1 0xffffff80001aa1e4 at __lockmgr_args+0x980 #2 0xffffff8000468da0 at VOP_LOCK1_APV+0xf8 #3 0xffffff80002836f4 at _vn_lock+0x80 #4 0xffffff8000275a20 at vputx+0x1ac #5 0xffffff800026dd9c at dounmount+0x410 #6 0xffffff8000276f14 at vfs_unmountall+0x7c #7 0xffffff800025a120 at bufshutdown+0x390 #8 0xffffff80001cc090 at kern_reboot+0x190 #9 0xffffff80001cbe94 at sys_reboot+0x38c #10 0xffffff800045bd9c at do_el0_sync+0x474 #11 0xffffff800044a9d0 at handle_el0_sync+0x64 lock order reversal: 1st 0xffffffc002a3fb78 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1224 2nd 0xffffffc002a3f9a0 devfs (devfs) @ = /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 stack backtrace: #0 0xffffff8000221ec8 at witness_debugger+0x68 #1 0xffffff80001aa1e4 at __lockmgr_args+0x980 #2 0xffffff8000468da0 at VOP_LOCK1_APV+0xf8 #3 0xffffff80002836f4 at _vn_lock+0x80 #4 0xffffff8000400bf0 at ffs_flushfiles+0xa0 #5 0xffffff80003e7c14 at softdep_flushfiles+0x2d4 #6 0xffffff8000403350 at ffs_unmount+0x88 #7 0xffffff800026dec0 at dounmount+0x534 #8 0xffffff8000276f14 at vfs_unmountall+0x7c #9 0xffffff800025a120 at bufshutdown+0x390 #10 0xffffff80001cc090 at kern_reboot+0x190 #11 0xffffff80001cbe94 at sys_reboot+0x38c #12 0xffffff800045bd9c at do_el0_sync+0x474 #13 0xffffff800044a9d0 at handle_el0_sync+0x64 Uptime: 21m11s The operating system has halted. Please press any key to reboot. (qemu) q=1B[K=1B[Dqu=1B[K=1B[D=1B[Dqui=1B[K=1B[D=1B[D=1B[Dquit=1B[K =1B]0;skibo@robleda: = ~/Projects/Zynq/qemu=07skibo@robleda:~/Projects/Zynq/qemu$ exit Script done on Fri 18 Dec 2015 02:43:42 PM PST From owner-freebsd-arm@freebsd.org Fri Dec 18 23:24:52 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 7D0DAA4C94E for ; Fri, 18 Dec 2015 23:24:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FF001E9C for ; Fri, 18 Dec 2015 23:24:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id o67so105326093iof.3 for ; Fri, 18 Dec 2015 15:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1/321ciyoRdnyqEAeSh9/PvCJIVzu6mHiMkER3G6/0g=; b=nFba77o3WwCLQdHqmfMmw4agxsG2kXJxFEdMhI+kvJDv+TWL2OMFgOyHKz8aav1VWH sSsB/lYQptaHEcfkcPrdnBCWE4moLcSjNjKO8+kB7OnOrHYoKV9GU0lCWzV7Cs67MFvQ VP2Tyka45zhMRqoZEoQl24jsjrOi+js0uU33u6P4Tpc8AKigcEumqoLQOMh/N8dfb6Lj tWexu4k0G6M6bo2c/F48jcUelV1EW7X3BaeqAANlBD1nWH3467bANJpaSVpAw/hvHqAZ W1y9GAkQychLyynqQPnnTdM/fUcKBiL1B6bLbZM6YtLe/1AwPtr41AqfM+hJ/iBEMhvO m0bg== MIME-Version: 1.0 X-Received: by 10.107.162.21 with SMTP id l21mr7391142ioe.123.1450481091708; Fri, 18 Dec 2015 15:24:51 -0800 (PST) Received: by 10.36.121.202 with HTTP; Fri, 18 Dec 2015 15:24:51 -0800 (PST) In-Reply-To: <5695944F-A052-4959-8F9A-ACD4CD3413D6@yahoo.com> References: <5695944F-A052-4959-8F9A-ACD4CD3413D6@yahoo.com> Date: Fri, 18 Dec 2015 15:24:51 -0800 Message-ID: Subject: Re: u-boot and ubldr on arm64 From: Adrian Chadd To: Thomas Skibo Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 18 Dec 2015 23:24:52 -0000 hey cool! Can you post your patches to freebsd and uboot? Let's get them somewhere reviewed! -a On 18 December 2015 at 10:18, Thomas Skibo via freebsd-arm wrote: > > Hello. > > I=E2=80=99ve been taking a stab at getting an arm64 kernel running on qem= u acting as a Zynq Ultrascale evaluation board. The first hurdle was getti= ng the u-boot API and ubldr to compile and run in 64-bit mode. I=E2=80=99v= e managed to get that much to work and wanted to let you know in case this = is interesting and I can share the code. Or, so you can tell me that u-boo= t/ubldr is the wrong approach. > > In any case, here=E2=80=99s how far it boots. The next step is to whip m= y kernel configuration into shape but I may have to put this aside until af= ter the holidays. > > Cheers, > =E2=80=94Thomas > > =E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com > > > Script started on Fri 18 Dec 2015 09:34:49 AM PST > skibo@robleda:~/Projects/Zynq/qemu$ source GO.txt > WARNING: Image format was not specified for '../debug.qemu/SDCARD.img' an= d probing guessed raw. > Automatically detecting the format is dangerous for raw images, = write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > QEMU 2.4.93 monitor - type 'help' for more information > (qemu) c [K > (qemu) > > U-Boot 2015.07-00006-gd3fba7f-dirty (Dec 18 2015 - 09:30:17 -0800) Xilinx= ZynqMP > > I2C: ready > DRAM: 1 GiB > Enabling Caches... > > EL Level: EL1 > NAND: ERROR:arasan_nand_reset timedout > ERROR:arasan_nand_read_buf timedout:Buff RDY > ERROR:arasan_nand_read_buf timedout:Xfer CMPLT > ERROR:arasan_nand_read_buf timedout:Buff RDY > ERROR:arasan_nand_read_buf timedout:Xfer CMPLT > ERROR:arasan_nand_read_buf timedout:Buff RDY > ERROR:arasan_nand_read_buf timedout:Xfer CMPLT > ERROR:arasan_nand_read_buf timedout:Buff RDY > ERROR:arasan_nand_read_buf timedout:Xfer CMPLT > arasan_nand_init: nand_scan_ident failed > NAND init failed > 0 MiB > MMC: zynq_sdhci: 0 > Using default environment > > In: serial > Out: serial > Err: serial > Bootmode: JTAG_MODE > SCSI: SATA link 0 timeout. > AHCI 0001.0000 32 slots 2 ports 1.5 Gbps 0x3 impl SATA mode > flags: ncq only > scanning bus for devices... > Found 0 device(s). > Net: Gem.ff0b0000 > Hit any key to stop autoboot: 5 0 > ZynqMP> fatls mmc 0 > 254704 ubldr > 172 uenv.txt > 160405 demo > 1408 board.dtb > > 4 file(s), 0 dir(s) > > ZynqMP> fatload mmc 0 0x1000000 ubldr > reading ubldr > 254704 bytes read in 72 ms (3.4 MiB/s) > ZynqMP> setenv fdt_file board.dtb > ZynqMP> bootelf 0x1000000 > ## Starting application at 0x010000b0 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @3df02860 > > FreeBSD/aarch64 U-Boot loader, Revision 1.2 > (skibo@ashbury, Fri Dec 18 09:33:17 PST 2015) > > DRAM: 1024MB > Number of U-Boot devices: 2 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > Probing all disk devices... > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: > | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ |= / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / = - \ | / - \ | /boot/kernel/kernel data=3D0x5ead28+0x2f4620 / - \ | / - \ | = / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / - \ | / -= \ | / syms=3D[0x8+0xc0120- \ | / - \ +0x8+0xbde15| / - \ | / ] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kerne= l] in 8 seconds... Booting [/boot/kernel/kernel] in 7 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > loader> boot -v > [37m [44mBooting... [m > \ | / - \ | / - \ | /boot/kernel/board.dtb size=3D0x580 > Loaded DTB from file 'board.dtb'. > / - \ | / Kernel entry at 0x0x1201000... > Kernel args: -v > KDB: debugger backends: ddb > KDB: current backend: ddb > No CPU data, limiting to 1 core > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #11 r292424M: Fri Dec 18 01:16:09 PST 2015 > skibo@ashbury:/usr/obj/arm64.aarch64/usr/src/sys/EP108 arm64 > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > WARNING: WITNESS option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffff8000a61000. > Preloaded dtb "/boot/kernel/board.dtb" at 0xffffff8000a61a28. > CPU(0): ARM Cortex-A53 r0p4 > CPU0 affinity: 0.0.0.0 > FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs > ULE: setup cpu 0 > random: entropy device external interface > null: > openfirm: > mem: > nfslock: pseudo-device > crypto: > random: harvesting attach, 8 bytes (4 bits) from nexus0 > ofwbus0: > simplebus0: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from simplebus0 > simplebus1: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from simplebus1 > random: harvesting attach, 8 bytes (4 bits) from ofwbus0 > gic0: mem 0xf9010000-0xf901ffff,0xf902= f000-0xf9030fff,0xf9040000-0xf905ffff,0xf906f000-0xf9070fff on simplebus0 > gic0: pn 0x0, arch 0x0, rev 0x0, implementer 0x0 irqs 192 > random: harvesting attach, 8 bytes (4 bits) from gic0 > uart0: mem 0xff000000-0xff000fff irq 53 on simplebus1 > uart0: console (115200,n,8,1) > uart0: fast interrupt > uart0: PPS capture mode 2 (DCD) > random: harvesting attach, 8 bytes (4 bits) from uart0 > uart1: mem 0xff010000-0xff010fff irq 54 on simplebus1 > uart1: fast interrupt > uart1: PPS capture mode 2 (DCD) > random: harvesting attach, 8 bytes (4 bits) from uart1 > simplebus1: mem 0xff0b0000-0xff0b0fff irq 89,89 compa= t cadence,gem (no driver attached) > cryptosoft0: > crypto: assign cryptosoft0 driver id 0, flags 100663296 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 23 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 25 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 24 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 26 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 27 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 28 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > random: harvesting attach, 8 bytes (4 bits) from cryptosoft0 > Device configuration finished. > procfs registered > panic: No usable event timer found! > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffffff80004460b4 lr =3D 0xffffff800004eaf8 > sp =3D 0xffffff800000b8e0 fp =3D 0xffffff800000ba00 > > db_trace_self_wrapper() at vpanic+0x170 > pc =3D 0xffffff800004eaf8 lr =3D 0xffffff80001c9088 > sp =3D 0xffffff800000ba10 fp =3D 0xffffff800000ba90 > > vpanic() at panic+0x4c > pc =3D 0xffffff80001c9088 lr =3D 0xffffff80001c9118 > sp =3D 0xffffff800000baa0 fp =3D 0xffffff800000bb20 > > panic() at cpu_initclocks_bsp+0x3b4 > pc =3D 0xffffff80001c9118 lr =3D 0xffffff800045bff8 > sp =3D 0xffffff800000bb30 fp =3D 0xffffff800000bb80 > > cpu_initclocks_bsp() at initclocks+0x28 > pc =3D 0xffffff800045bff8 lr =3D 0xffffff8000171994 > sp =3D 0xffffff800000bb90 fp =3D 0xffffff800000bb90 > > initclocks() at mi_startup+0x11c > pc =3D 0xffffff8000171994 lr =3D 0xffffff800016ea90 > sp =3D 0xffffff800000bba0 fp =3D 0xffffff800000bbd0 > > mi_startup() at virtdone+0x5c > pc =3D 0xffffff800016ea90 lr =3D 0xffffff800000108c > sp =3D 0xffffff800000bbe0 fp =3D 0x0000000000000000 > > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at kdb_enter+0x40: > db> > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Dec 19 01:13:06 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 AB96EA4CF33 for ; Sat, 19 Dec 2015 01:13:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 91E3E1AFA for ; Sat, 19 Dec 2015 01:13:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 19 Dec 2015 01:12:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBJ1D3MG028599; Fri, 18 Dec 2015 18:13:03 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450487583.25138.132.camel@freebsd.org> Subject: Re: mount_smbfs From: Ian Lepore To: John-Mark Gurney , Warner Losh Cc: freebsd-arm , Rui Paulo Date: Fri, 18 Dec 2015 18:13:03 -0700 In-Reply-To: <20150123213619.GP1949@funkthat.com> References: <54B9DCD1.3040306@foxvalley.net> <4759EAA0-D4AA-4923-9350-B7E753819169@me.com> <6E32991C3BD8465DB8DB0E65DFDA47AA@ad.peach.ne.jp> <20150123195403.GO1949@funkthat.com> <20150123213619.GP1949@funkthat.com> Content-Type: multipart/mixed; boundary="=-csbj0LHgt/uWaSTdnj7N" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Sat, 19 Dec 2015 01:13:06 -0000 --=-csbj0LHgt/uWaSTdnj7N Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, 2015-01-23 at 13:36 -0800, John-Mark Gurney wrote: > Warner Losh wrote this message on Fri, Jan 23, 2015 at 13:21 -0800: > > > > > On Jan 23, 2015, at 11:54 AM, John-Mark Gurney wrote: > > > > > > Daisuke Aoyama wrote this message on Sat, Jan 24, 2015 at 03:07 +0900: > > > > Quick hack patch is attached. > > > > > > Please use {l,b}e16dec, or if the code is suppose to be native endian, > > > make it dependant on __NO_STRICT_ALIGNMENT and add the proper endian > > > swap, not __arm__ as there are other arches that require the same fix... > > > > If there???s just a couple of places that need this, don???t bother making them dependent > > on __NO_STRICT_ALIGNMENT. That clutters things up a bit too much. Given the 3 > > or 4 places this is used, and the relative infrequency of the calls, just doing a memcpy > > unconditionally is always correct and reduces the risk of one branch of the #if being > > changed w/o the other. Since it is already using NBENCODE(), I think that using > > {l,b}e16enc (not dec) would be a larger code churn. > > Clearly neither of us looked at the code closely... NBENCODE should be > rewritten to take a pointer and use le16enc... Then memsetw should just > call NBENCODE internally as it goes... Well I looked at the code closely, even if it did take me almost a year to get around to it. :) The conclusion I reached is that alignment and endian problems should just be turned into a non-issue by discarding the existing macro and memsetw() function and writing a new inline function that deals purely with bytes instead of 16-bit values. It's up for review on phabricator at https://reviews.freebsd.org/D4622 And I'll also attach the diff to this mail for anyone who wants to test it (which I can't do, no smb server). -- Ian --=-csbj0LHgt/uWaSTdnj7N Content-Disposition: inline; filename="smbfs_nb_name.diff" Content-Type: text/x-patch; name="smbfs_nb_name.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: contrib/smbfs/lib/smb/nb_name.c =================================================================== --- contrib/smbfs/lib/smb/nb_name.c (revision 292290) +++ contrib/smbfs/lib/smb/nb_name.c (working copy) @@ -143,15 +143,13 @@ nb_encname_len(const char *str) return len; } -#define NBENCODE(c) (htole16((u_short)(((u_char)(c) >> 4) | \ - (((u_char)(c) & 0xf) << 8)) + 0x4141)) +static inline void +nb_char_encode(u_char **ptr, u_char c, int n) +{ -static void -memsetw(char *dst, int n, u_short word) -{ while (n--) { - *(u_short*)dst = word; - dst += 2; + *(*ptr)++ = 0x41 + (c >> 4); + *(*ptr)++ = 0x41 + (c & 0x0f); } } @@ -165,19 +163,15 @@ nb_name_encode(struct nb_name *np, u_char *dst) *cp++ = NB_ENCNAMELEN; name = np->nn_name; if (name[0] == '*' && name[1] == 0) { - *(u_short*)cp = NBENCODE('*'); - memsetw(cp + 2, NB_NAMELEN - 1, NBENCODE(' ')); - cp += NB_ENCNAMELEN; + nb_char_encode(&cp, '*', 1); + nb_char_encode(&cp, ' ', NB_NAMELEN - 1); } else { - for (i = 0; *name && i < NB_NAMELEN - 1; i++, cp += 2, name++) - *(u_short*)cp = NBENCODE(toupper(*name)); - i = NB_NAMELEN - i - 1; - if (i > 0) { - memsetw(cp, i, NBENCODE(' ')); - cp += i * 2; - } - *(u_short*)cp = NBENCODE(np->nn_type); - cp += 2; + for (i = 0; i < NB_NAMELEN - 1; i++) + if (*name != 0) + nb_char_encode(&cp, toupper(*name++), 1); + else + nb_char_encode(&cp, ' ', 1); + nb_char_encode(&cp, np->nn_type, 1); } *cp = 0; if (np->nn_scope == NULL) --=-csbj0LHgt/uWaSTdnj7N-- From owner-freebsd-arm@freebsd.org Sat Dec 19 20:58:34 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 B8202A4DC28 for ; Sat, 19 Dec 2015 20:58:34 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D3F91F4D; Sat, 19 Dec 2015 20:58:33 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1aAOa8-007Wk6-Mg; Sat, 19 Dec 2015 21:58:24 +0100 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: Ian Lepore cc: freebsd-arm , Rui Paulo , John-Mark Gurney , Warner Losh Subject: Re: mount_smbfs In-reply-to: <1450487583.25138.132.camel@freebsd.org> References: <54B9DCD1.3040306@foxvalley.net> <4759EAA0-D4AA-4923-9350-B7E753819169@me.com> <6E32991C3BD8465DB8DB0E65DFDA47AA@ad.peach.ne.jp> <20150123195403.GO1949@funkthat.com> <20150123213619.GP1949@funkthat.com> <1450487583.25138.132.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Dec 2015 21:58:23 +0100 Message-Id: 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: Sat, 19 Dec 2015 20:58:34 -0000 Ian Lepore wrote on Fri, 18 Dec 2015 at 18:13:03 -0700: > On Fri, 2015-01-23 at 13:36 -0800, John-Mark Gurney wrote: > > Warner Losh wrote this message on Fri, Jan 23, 2015 at 13:21 -0800: > > > > > > > On Jan 23, 2015, at 11:54 AM, John-Mark Gurney wrote: > > > > > > > > Daisuke Aoyama wrote this message on Sat, Jan 24, 2015 at 03:07 +0900: > > > > > Quick hack patch is attached. > > > > > > > > Please use {l,b}e16dec, or if the code is suppose to be native endian, > > > > make it dependant on __NO_STRICT_ALIGNMENT and add the proper endian > > > > swap, not __arm__ as there are other arches that require the same fix... > > > > > > If there???s just a couple of places that need this, don???t bother making them dependent > > > on __NO_STRICT_ALIGNMENT. That clutters things up a bit too much. Given the 3 > > > or 4 places this is used, and the relative infrequency of the calls, just doing a memcpy > > > unconditionally is always correct and reduces the risk of one branch of the #if being > > > changed w/o the other. Since it is already using NBENCODE(), I think that using > > > {l,b}e16enc (not dec) would be a larger code churn. > > > > Clearly neither of us looked at the code closely... NBENCODE should be > > rewritten to take a pointer and use le16enc... Then memsetw should just > > call NBENCODE internally as it goes... > > Well I looked at the code closely, even if it did take me almost a year > to get around to it. :) > > The conclusion I reached is that alignment and endian problems should > just be turned into a non-issue by discarding the existing macro and > memsetw() function and writing a new inline function that deals purely > with bytes instead of 16-bit values. > > It's up for review on phabricator at https://reviews.freebsd.org/D4622 > > And I'll also attach the diff to this mail for anyone who wants to test > it (which I can't do, no smb server). Done. Your patch applied to revision 292468 is working here nice. The PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180438 could be added to the phabricator information as well. Thank you. Ralf