From owner-freebsd-arm@freebsd.org Sun Dec 31 00:15:06 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75F4AEB3FB7 for ; Sun, 31 Dec 2017 00:15:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-135.reflexion.net [208.70.210.135]) (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 3478A74816 for ; Sun, 31 Dec 2017 00:15:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27172 invoked from network); 31 Dec 2017 00:08:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Dec 2017 00:08:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 30 Dec 2017 19:08:18 -0500 (EST) Received: (qmail 6442 invoked from network); 31 Dec 2017 00:08:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Dec 2017 00:08:18 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6B8C6EC9265; Sat, 30 Dec 2017 16:08:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv7 cross-build of port: devel/libunistring stuck in configure for over an hour: ***MEMORY-ERROR***: [27504]: GSlice: failed to allocate 496 bytes (alignment: 512): Cannot allocate memory From: Mark Millard In-Reply-To: Date: Sat, 30 Dec 2017 16:08:16 -0800 Cc: Freebsd-arm , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sean Bruno X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 00:15:06 -0000 [top shows /usr/local/bin/qemu-arm-static is stuck in uwait.] On 2017-Dec-30, at 3:15 PM, Mark Millard wrote: > = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/config.log >=20 > shows: >=20 > configure:25883: checking whether printf survives out-of-memory = conditions > configure:26055: /nxb-bin/usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -D_THREAD_SAFE conftest.c >&5 > configure:26058: $? =3D 0 >=20 > ***MEMORY-ERROR***: [27504]: GSlice: failed to allocate 496 bytes = (alignment: 512): Cannot allocate memory >=20 >=20 >=20 > And there is no more to the tail of the config.log file: it does not = grow. >=20 > # ls -lTdt = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/* > -rw-r--r-- 1 root wheel 130860 Dec 30 14:51:04 2017 = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/config.log > . . . >=20 >=20 > It has been sitting like this for well over an hour: >=20 > [06]: devel/libunistring | libunistring-0.9.8 configure (01:35:18)=20 >=20 >=20 >=20 > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r327364M amd64 = amd64 1200054 1200054 >=20 >=20 > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 457579 > Last Changed Rev: 457579 top indicates that it is /usr/local/bin/qemu-arm-static that is stuck (in uwait), a range of the "top -Cawopid" output shows: 27504 root 2 52 0 87228K 9324K 0K uwait 22 0:00 = 0.00% /usr/local/bin/qemu-arm-static ./conftest 27499 root 1 52 0 11260K 2540K 0K wait 10 0:00 = 0.00% /bin/sh ./configure --disable-static --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-silent- 9769 root 1 52 0 11260K 2544K 0K wait 22 0:01 = 0.00% /bin/sh ./configure --disable-static --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-silent- 8294 root 1 52 0 10224K 1772K 0K wait 13 0:00 = 0.00% [sh] 7730 root 1 20 0 10296K 1712K 0K wait 1 0:00 = 0.00% /usr/bin/make -C /usr/ports/devel/libunistring configure 7729 root 1 52 0 12944K 3552K 0K wait 5 0:00 = 0.00% sh: poudriere[FBSDFSSDjailArmV7-default][06]: build_pkg = (libunistring-0.9.8) (sh) 99854 root 1 20 0 12944K 3560K 0K select 0 0:00 = 0.00% sh: poudriere[FBSDFSSDjailArmV7-default][06]: build_pkg = (libunistring-0.9.8) (sh) 99817 root 1 27 0 12944K 3548K 0K piperd 17 0:03 = 0.00% sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w = -f /root/armv7-origins.txt 74826 root 1 52 0 12944K 3512K 0K nanslp 26 1:39 = 0.53% sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w = -f /root/armv7-origins.txt 74601 root 1 52 0 12728K 3608K 0K select 19 0:12 = 0.00% sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w = -f /root/armv7-origins.txt (This was after letting it get to the point that only the libunistring poudriere job was being run.) Apparently, "checking whether printf survives out-of-memory conditions" and qemu-arm-static to not mix well. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Dec 31 01:38:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4349EB8D01 for ; Sun, 31 Dec 2017 01:38:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (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 834E678D0D for ; Sun, 31 Dec 2017 01:38:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6004 invoked from network); 31 Dec 2017 01:31:53 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Dec 2017 01:31:53 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 30 Dec 2017 20:31:53 -0500 (EST) Received: (qmail 21260 invoked from network); 31 Dec 2017 01:31:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Dec 2017 01:31:53 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6810CEC935A; Sat, 30 Dec 2017 17:31:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: armv7 cross-build of port: devel/libunistring stuck in configure for over an hour: ***MEMORY-ERROR***: [27504]: GSlice: failed to allocate 496 bytes (alignment: 512): Cannot allocate memory From: Mark Millard In-Reply-To: Date: Sat, 30 Dec 2017 17:31:51 -0800 Cc: Freebsd-arm , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <97845FC0-403D-48EF-AD6F-394405FEB656@dsl-only.net> References: To: Sean Bruno X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 01:38:35 -0000 [qemu-aarch64-static has the same issue as qemu-arm-static.] On 2017-Dec-30, at 4:08 PM, Mark Millard wrote: > [top shows /usr/local/bin/qemu-arm-static is stuck in uwait.] >=20 > On 2017-Dec-30, at 3:15 PM, Mark Millard = wrote: >=20 >> = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/config.log >>=20 >> shows: >>=20 >> configure:25883: checking whether printf survives out-of-memory = conditions >> configure:26055: /nxb-bin/usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -g -fno-strict-aliasing = -mcpu=3Dcortex-a7 -DLIBICONV_PLUG -D_THREAD_SAFE conftest.c >&5 >> configure:26058: $? =3D 0 >>=20 >> ***MEMORY-ERROR***: [27504]: GSlice: failed to allocate 496 bytes = (alignment: 512): Cannot allocate memory >>=20 >>=20 >>=20 >> And there is no more to the tail of the config.log file: it does not = grow. >>=20 >> # ls -lTdt = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/* >> -rw-r--r-- 1 root wheel 130860 Dec 30 14:51:04 2017 = /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/06/wrkdirs/usr/port= s/devel/libunistring/work/libunistring-0.9.8/config.log >> . . . >>=20 >>=20 >> It has been sitting like this for well over an hour: >>=20 >> [06]: devel/libunistring | libunistring-0.9.8 configure (01:35:18)=20 >>=20 >>=20 >>=20 >> # uname -apKU >> FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r327364M amd64 = amd64 1200054 1200054 >>=20 >>=20 >> # svnlite info /usr/ports/ | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 457579 >> Last Changed Rev: 457579 >=20 > top indicates that it is /usr/local/bin/qemu-arm-static that is stuck > (in uwait), a range of the "top -Cawopid" output shows: >=20 > 27504 root 2 52 0 87228K 9324K 0K uwait 22 = 0:00 0.00% /usr/local/bin/qemu-arm-static ./conftest > 27499 root 1 52 0 11260K 2540K 0K wait 10 = 0:00 0.00% /bin/sh ./configure --disable-static --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-silent- > 9769 root 1 52 0 11260K 2544K 0K wait 22 0:01 = 0.00% /bin/sh ./configure --disable-static --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man --disable-silent- > 8294 root 1 52 0 10224K 1772K 0K wait 13 0:00 = 0.00% [sh] > 7730 root 1 20 0 10296K 1712K 0K wait 1 0:00 = 0.00% /usr/bin/make -C /usr/ports/devel/libunistring configure > 7729 root 1 52 0 12944K 3552K 0K wait 5 0:00 = 0.00% sh: poudriere[FBSDFSSDjailArmV7-default][06]: build_pkg = (libunistring-0.9.8) (sh) > 99854 root 1 20 0 12944K 3560K 0K select 0 = 0:00 0.00% sh: poudriere[FBSDFSSDjailArmV7-default][06]: build_pkg = (libunistring-0.9.8) (sh) > 99817 root 1 27 0 12944K 3548K 0K piperd 17 = 0:03 0.00% sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt > 74826 root 1 52 0 12944K 3512K 0K nanslp 26 = 1:39 0.53% sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt > 74601 root 1 52 0 12728K 3608K 0K select 19 = 0:12 0.00% sh -e /usr/local/share/poudriere/bulk.sh = -jFBSDFSSDjailArmV7 -w -f /root/armv7-origins.txt >=20 > (This was after letting it get to the point that > only the libunistring poudriere job was being run.) >=20 > Apparently, "checking whether printf survives out-of-memory = conditions" > and qemu-arm-static to not mix well. qemu-aarch64-static has the same issue as qemu-arm-static: configure:25883: checking whether printf survives out-of-memory = conditions configure:26055: /nxb-bin/usr/bin/cc -o conftest -O2 -pipe = -mcpu=3Dcortex-a53 -DLIBICONV_PLUG -g -fno-strict-aliasing = -mcpu=3Dcortex-a53 -DLIBICONV_PLUG -D_THREAD_SAFE conftest.c >&5 configure:26058: $? =3D 0 ***MEMORY-ERROR***: [10016]: GSlice: failed to allocate 496 bytes = (alignment: 512): Cannot allocate memory and top shows: 10016 root 2 52 0 221M 13296K 0K uwait 6 0:00 = 0.00% /usr/local/bin/qemu-aarch64-static ./conftest In both cases doing a kill -9 from top of the stuck qemu-*-static process allowed things to continue. "checking whether printf survives out-of-memory conditions" and qemu-aarch64-static or qemu-arm-static just do not mix well. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jan 1 18:10:55 2018 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 94A8DEB58E5 for ; Mon, 1 Jan 2018 18:10:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BD71765BC for ; Mon, 1 Jan 2018 18:10:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w01IAkiW007129 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Jan 2018 10:10:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w01IAkKX007128; Mon, 1 Jan 2018 10:10:46 -0800 (PST) (envelope-from fbsd) Date: Mon, 1 Jan 2018 10:10:46 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20180101181046.GA7042@www.zefox.net> References: <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> <20171223173152.GA25961@www.zefox.net> <798971d6-54f3-0453-6393-daa79fffd552@selasky.org> <20171223191120.GB25961@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171223191120.GB25961@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 18:10:55 -0000 On Sat, Dec 23, 2017 at 11:11:20AM -0800, bob prohaska wrote: > > Thanks for your attention, and apologies for what's beginning to > look like a red herring! > Well, the ungrounded USB shroud wasn't the problem. The pl2303ta locked up again. Unloading and reloading uplcom didn't help, unplugging the USB connector and waiting several minutes didn't help. However, unplugging the USB connector and plugging it into a powered hub _with_the_power_off_ did unstick the adapter. Probably the hub loaded down what little power could backfeed from the downstream serial port to turn the chip fully off. When reinserted in the RPI2 the adapter was recognized and seems to be working normally for now. It's rather clear the pl2303ta is latching up, but why it's worse on a -current machine than it is on an 11-stable machine is less obvious. One difference between the two is USB activity; the -current box uses a USB flash drive for most of the filesystems, along with a seldom-used mouse and keyboard. The -stable machine has all storage on the microSD card, no mouse and no keyboard. Thanks for reading, and any ideas. bob prohaska From owner-freebsd-arm@freebsd.org Mon Jan 1 18:23:54 2018 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 08A05EB62D0 for ; Mon, 1 Jan 2018 18:23:54 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9EB576C3F for ; Mon, 1 Jan 2018 18:23:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w01INlOf087479; Mon, 1 Jan 2018 10:23:47 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w01INlRV087478; Mon, 1 Jan 2018 10:23:47 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801011823.w01INlRV087478@pdx.rh.CN85.dnsmgr.net> Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 In-Reply-To: <20180101181046.GA7042@www.zefox.net> To: bob prohaska Date: Mon, 1 Jan 2018 10:23:47 -0800 (PST) CC: freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 18:23:54 -0000 > On Sat, Dec 23, 2017 at 11:11:20AM -0800, bob prohaska wrote: > > > > Thanks for your attention, and apologies for what's beginning to > > look like a red herring! > > > > Well, the ungrounded USB shroud wasn't the problem. The pl2303ta locked > up again. Unloading and reloading uplcom didn't help, unplugging the USB > connector and waiting several minutes didn't help. > > However, unplugging the USB connector and plugging it into a powered hub > _with_the_power_off_ did unstick the adapter. Probably the hub loaded down > what little power could backfeed from the downstream serial port to turn > the chip fully off. When reinserted in the RPI2 the adapter was recognized > and seems to be working normally for now. > > It's rather clear the pl2303ta is latching up, but why it's worse on a > -current machine than it is on an 11-stable machine is less obvious. One > difference between the two is USB activity; the -current box uses a USB > flash drive for most of the filesystems, along with a seldom-used mouse > and keyboard. The -stable machine has all storage on the microSD card, > no mouse and no keyboard. > > Thanks for reading, and any ideas. I would try disconnecting the gnd lead at the rs-232/ttl point, and connect all 4 RPI's directly togeather with a nice ground daisy chain with as short a wire as practical. And preferably with something larger than the 30gage wire or so that is in these USB/RS-232 adapters. Something like 24 gauge. The change in versions -could- be additional or different signal activity on the board(s) changing the amount of generated noise, might be interesting to see if there is a difference in power consumption between the 2 revisions, and or temperature level of the SOC (indicating power usage change indirectly). Trying to run logic between boards with low quality grounding is in general just asking for flakey things to happen. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jan 2 08:27:05 2018 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 4133DEBAB06 for ; Tue, 2 Jan 2018 08:27:05 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 F34E4751B5 for ; Tue, 2 Jan 2018 08:27:04 +0000 (UTC) (envelope-from dmarquess@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id b132so30639316qkc.13 for ; Tue, 02 Jan 2018 00:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EEUU5mJezZhM9yI4MoX4j4Zl9H0yj05XYm/sSFbbv5E=; b=HcJadCB8a9qu3LRCaaU0WvgfnJCK6f7XXr2CLMU3xjUS/1dZHcI/jG5kWs697Rddz5 t3OTDqpu9RN1oZtj2PinzMMLHOoiUkShxT5J/c+jsz/VwXvncqIHSo40Bt591xI6o73I jNby4bhMcf2LrH5qeOmbmjWjwn/5OpPoydu7qaEEJKb9vTDXUi+XVw79dpvG0B644Zje s3Szvmv+y91FHHmlZPlLiZ1me/3ZxT3QcPRnFLq09OcwHtOx4g8B4qtdziGC9wZtFidC 7k9f7YRL0DGhTvWVe9GmWQK5yxAziGnzZF8SMKIUzjaojAjFZf63lJ6wtUbRwtZwTixY KxjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EEUU5mJezZhM9yI4MoX4j4Zl9H0yj05XYm/sSFbbv5E=; b=KvmYNwWaIzup5B79BzyCPRlFS8b24fkPmKoSmfUkVt1/vg6C+UMC9RM0EPcDaJhXHd oQi+5HbLI2o41MVl96flFwViga63GqTq333VQP23cp+KahJ53g70UfFtnVmF0UD71tae /ugZizolIc2T5loXmL2t6GxnoCBFkSCQLaVlZ/sKsM2sIboXT0+cqPt/zJxjYvSmIBX/ LfHkXHwAApd/y/eI7f/AHG68hVXaYxpEOUe1ONTf5/6PlvIUyUZPgO90hrJGi6cCsEQS SK5CPLiIqu/JPaL+TCJQOfvloJuCjvfwg+X0cj1PM89UTEge8AdEklJqk+gCPIcoKk9Q bQnQ== X-Gm-Message-State: AKGB3mIp2UGaiPZghqQPUUg7YpykqZ/1HowOXEE4cTMGzhANb2XOHSQT aqZFLKOQIOdCocr69FL3Jb4Gc8x1MObp2YTwu4hWWQ== X-Google-Smtp-Source: ACJfBoujfyP3K9BOiM3HHXtbfIPjzf/VjLVZYTQSE7bMJVYPwWUTo9ZuLDtOL+lyKePd9VOEHp/J74xvGeusaFylssA= X-Received: by 10.55.20.218 with SMTP id 87mr45819557qku.9.1514881623889; Tue, 02 Jan 2018 00:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.105.53 with HTTP; Tue, 2 Jan 2018 00:27:03 -0800 (PST) From: Dustin Marquess Date: Tue, 2 Jan 2018 02:27:03 -0600 Message-ID: Subject: HiKey status To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 08:27:05 -0000 https://wiki.freebsd.org/arm64 has HiKey listed under "Running", yet the page that it links to ( https://wiki.freebsd.org/arm64/HiKey ) doesn't really have much information on it. Is it a working port? If so, is there a premade image somewhere for it? Crochet, sadly, doesn't seem to know about the HiKey. Thanks! -Dustin From owner-freebsd-arm@freebsd.org Tue Jan 2 19:55:31 2018 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 16509EB624B for ; Tue, 2 Jan 2018 19:55:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-169.reflexion.net [208.70.210.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 C8F1C700CF for ; Tue, 2 Jan 2018 19:55:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2442 invoked from network); 2 Jan 2018 19:48:43 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jan 2018 19:48:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 02 Jan 2018 14:48:43 -0500 (EST) Received: (qmail 18158 invoked from network); 2 Jan 2018 19:48:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jan 2018 19:48:43 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C8A6CEC7B31; Tue, 2 Jan 2018 11:48:42 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: rpi2 head -r327485 (e.g.): rpi2 leaves one "CPU n" always idle for some boots Message-Id: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> Date: Tue, 2 Jan 2018 11:48:42 -0800 To: Freebsd-arm , FreeBSD Hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:55:31 -0000 I've seen this over many versions of head for months but have never managed to find a way to force it to happen. It just shows up once and a while. Thus, I'm just dumping out some top and kernel information here for reference. I've used: openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & openssl speed 1>/dev/null 2>&1 & to give the rpi2 4 active processes. Various outputs are from different times without a reboot between. top -CaePores shows the likes of: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 614 root 1 20 0 10452K 10480K 0K select 1 0:00 = 0.03% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift 661 root 1 52 0 9984K 6132K 0K select 1 0:00 = 0.00% /usr/sbin/sshd 751 root 1 101 0 7256K 4276K 0K RUN 1 0:28 = 99.57% openssl speed 750 root 1 100 0 7256K 4276K 0K CPU0 0 0:32 = 94.83% openssl speed 753 root 1 86 0 7256K 4276K 0K RUN 3 0:13 = 52.36% openssl speed 752 root 1 86 0 7256K 4276K 0K CPU3 3 0:14 = 46.54% openssl speed 363 root 1 20 0 6428K 3840K 0K select 3 0:00 = 0.00% /sbin/devd . . . and: last pid: 754; load averages: 3.70, 2.38, 1.58 = = up 0+00:16:50 01:59:37 21 processes: 5 running, 16 sleeping CPU 0: 94.9% user, 0.0% nice, 0.0% system, 5.1% interrupt, 0.0% idle CPU 1: 99.6% user, 0.0% nice, 0.0% system, 0.4% interrupt, 0.0% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 3: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 12M Active, 1136K Inact, 56M Wired, 30M Buf, 722M Free Swap: 1536M Total, 6M Free =46rom problem boot to problem boot, the CPU that stays idle has varied but usually has been CPU 2. I've never seen 2 or more stuck in idle. show allpcpu shows the likes of: db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x3d2540 curthread =3D 0xd8478ae0: pid 2032 tid 100150 "openssl" curpcb =3D 0xd852ae98 fpcurthread =3D 0xd8478ae0: pid 2032 "openssl" idlethread =3D 0xc376fae0: tid 100002 "idle: cpu0" curpmap =3D 0xd8e43bf4 curvnet =3D 0 cpuid =3D 1 dynamic pcpu =3D 0x3998540 curthread =3D 0xd7e5b3a0: pid 2031 tid 100173 "openssl" curpcb =3D 0xda7e0e98 fpcurthread =3D 0xd7e5b3a0: pid 2031 "openssl" idlethread =3D 0xc376f740: tid 100003 "idle: cpu1" curpmap =3D 0xd8e43ec4 curvnet =3D 0 cpuid =3D 2 dynamic pcpu =3D 0x3999540 curthread =3D 0xc376f3a0: pid 10 tid 100004 "idle: cpu2" curpcb =3D 0xc378ae98 fpcurthread =3D none idlethread =3D 0xc376f3a0: tid 100004 "idle: cpu2" curpmap =3D 0 curvnet =3D 0 cpuid =3D 3 dynamic pcpu =3D 0x399a540 curthread =3D 0xd8477000: pid 2034 tid 100167 "openssl" curpcb =3D 0xd876de98 fpcurthread =3D 0xd8477000: pid 2034 "openssl" idlethread =3D 0xc376f000: tid 100005 "idle: cpu3" curpmap =3D 0xc377ab04 curvnet =3D 0 In other words: it appears that the cpuN (here cpu2) is left with idle scheduled all the time for some reason. ps from db> shows things like: db> ps pid ppid pgrp uid state wmesg wchan cmd 2034 714 2034 0 R+ openssl 2033 714 2033 0 R+ CPU 3 openssl 2032 714 2032 0 R+ CPU 0 openssl 2031 714 2031 0 R+ CPU 1 openssl (then later:) db> ps pid ppid pgrp uid state wmesg wchan cmd 2034 714 2034 0 R+ CPU 3 openssl 2033 714 2033 0 R+ openssl 2032 714 2032 0 R+ CPU 0 openssl 2031 714 2031 0 R+ CPU 1 openssl There is also: 10 0 0 0 RL (threaded) [idle] 100002 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 CanRun [idle: cpu3] =20 These are from: # uname -apKU FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 = 1200054 1200054 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jan 2 19:59:20 2018 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 72CA5EB6437 for ; Tue, 2 Jan 2018 19:59:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-148.reflexion.net [208.70.210.148]) (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 31CBF701D9 for ; Tue, 2 Jan 2018 19:59:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10082 invoked from network); 2 Jan 2018 19:59:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jan 2018 19:59:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 02 Jan 2018 14:59:13 -0500 (EST) Received: (qmail 13481 invoked from network); 2 Jan 2018 19:59:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jan 2018 19:59:13 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4E89DEC94C7; Tue, 2 Jan 2018 11:59:12 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 head -r327485 (e.g.): rpi2 leaves one "CPU n" always idle for some boots Date: Tue, 2 Jan 2018 11:59:11 -0800 References: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> To: Freebsd-arm , FreeBSD Hackers , FreeBSD Current In-Reply-To: <3258F809-F179-4EB7-857C-74667BECD360@dsl-only.net> Message-Id: <422E2742-7170-4D1A-894F-F310EE819E3A@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:59:20 -0000 On 2018-Jan-2, at 11:48 AM, Mark Millard wrote: > I've seen this over many versions of head for months > but have never managed to find a way to force it to > happen. It just shows up once and a while. >=20 > Thus, I'm just dumping out some top and kernel information > here for reference. I've used: >=20 > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & > openssl speed 1>/dev/null 2>&1 & >=20 > to give the rpi2 4 active processes. Various outputs > are from different times without a reboot between. >=20 > top -CaePores shows the likes of: >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 614 root 1 20 0 10452K 10480K 0K select 1 0:00 = 0.03% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 661 root 1 52 0 9984K 6132K 0K select 1 0:00 = 0.00% /usr/sbin/sshd > 751 root 1 101 0 7256K 4276K 0K RUN 1 0:28 = 99.57% openssl speed > 750 root 1 100 0 7256K 4276K 0K CPU0 0 0:32 = 94.83% openssl speed > 753 root 1 86 0 7256K 4276K 0K RUN 3 0:13 = 52.36% openssl speed > 752 root 1 86 0 7256K 4276K 0K CPU3 3 0:14 = 46.54% openssl speed > 363 root 1 20 0 6428K 3840K 0K select 3 0:00 = 0.00% /sbin/devd > . . . >=20 > and: >=20 > last pid: 754; load averages: 3.70, 2.38, 1.58 = = up 0+00:16:50 01:59:37 > 21 processes: 5 running, 16 sleeping > CPU 0: 94.9% user, 0.0% nice, 0.0% system, 5.1% interrupt, 0.0% = idle > CPU 1: 99.6% user, 0.0% nice, 0.0% system, 0.4% interrupt, 0.0% = idle > CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% = idle > CPU 3: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% = idle > Mem: 12M Active, 1136K Inact, 56M Wired, 30M Buf, 722M Free > Swap: 1536M Total, 6M Free >=20 > =46rom problem boot to problem boot, the CPU that stays > idle has varied but usually has been CPU 2. I've never > seen 2 or more stuck in idle. >=20 > show allpcpu shows the likes of: >=20 > db> show allpcpu > Current CPU: 0 >=20 > cpuid =3D 0 > dynamic pcpu =3D 0x3d2540 > curthread =3D 0xd8478ae0: pid 2032 tid 100150 "openssl" > curpcb =3D 0xd852ae98 > fpcurthread =3D 0xd8478ae0: pid 2032 "openssl" > idlethread =3D 0xc376fae0: tid 100002 "idle: cpu0" > curpmap =3D 0xd8e43bf4 > curvnet =3D 0 >=20 > cpuid =3D 1 > dynamic pcpu =3D 0x3998540 > curthread =3D 0xd7e5b3a0: pid 2031 tid 100173 "openssl" > curpcb =3D 0xda7e0e98 > fpcurthread =3D 0xd7e5b3a0: pid 2031 "openssl" > idlethread =3D 0xc376f740: tid 100003 "idle: cpu1" > curpmap =3D 0xd8e43ec4 > curvnet =3D 0 >=20 > cpuid =3D 2 > dynamic pcpu =3D 0x3999540 > curthread =3D 0xc376f3a0: pid 10 tid 100004 "idle: cpu2" > curpcb =3D 0xc378ae98 > fpcurthread =3D none > idlethread =3D 0xc376f3a0: tid 100004 "idle: cpu2" > curpmap =3D 0 > curvnet =3D 0 >=20 > cpuid =3D 3 > dynamic pcpu =3D 0x399a540 > curthread =3D 0xd8477000: pid 2034 tid 100167 "openssl" > curpcb =3D 0xd876de98 > fpcurthread =3D 0xd8477000: pid 2034 "openssl" > idlethread =3D 0xc376f000: tid 100005 "idle: cpu3" > curpmap =3D 0xc377ab04 > curvnet =3D 0 >=20 > In other words: it appears that the cpuN (here cpu2) is > left with idle scheduled all the time for some reason. >=20 > ps from db> shows things like: >=20 >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 2034 714 2034 0 R+ openssl > 2033 714 2033 0 R+ CPU 3 openssl > 2032 714 2032 0 R+ CPU 0 openssl > 2031 714 2031 0 R+ CPU 1 openssl >=20 > (then later:) >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 2034 714 2034 0 R+ CPU 3 openssl > 2033 714 2033 0 R+ openssl > 2032 714 2032 0 R+ CPU 0 openssl > 2031 714 2031 0 R+ CPU 1 openssl >=20 > There is also: >=20 > 10 0 0 0 RL (threaded) [idle] > 100002 CanRun [idle: cpu0] > 100003 CanRun [idle: cpu1] > 100004 CanRun [idle: cpu2] > 100005 CanRun [idle: cpu3] >=20 >=20 > These are from: >=20 > # uname -apKU > FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 = 1200054 1200054 I probably should have reported that as I remember the following sort of thing is true for the problem cpuN (here cpu2): 100074 D - 0xd6f5be80 [softirq_0] 100075 D - 0xd6f5be00 [softirq_1] 100076 RunQ [softirq_2] 100077 D - 0xd6f5bd00 [softirq_3] 100078 D - 0xd6f5bc80 [if_io_tqg_0] 100079 D - 0xd6f5bc00 [if_io_tqg_1] 100080 RunQ [if_io_tqg_2] 100081 D - 0xd6f5bb00 [if_io_tqg_3] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jan 2 22:27:38 2018 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 53DD4EBCB1C for ; Tue, 2 Jan 2018 22:27:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 18D40763B1 for ; Tue, 2 Jan 2018 22:27:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w02MRU3C011260 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jan 2018 14:27:31 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w02MRUmQ011259; Tue, 2 Jan 2018 14:27:30 -0800 (PST) (envelope-from fbsd) Date: Tue, 2 Jan 2018 14:27:30 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: RPI2 boot hangs with red light on Message-ID: <20180102222730.GB10596@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 22:27:38 -0000 An RPI2 with sources at 327493 and kernel at 322520 makes and installs world and kernel, but boot fails with the red LED stuck on. Starting with the reboot command, the console reports login: Jan 2 14:16:39 www shutdown: reboot by bob: Stopping cron. Waiting for PIDS: 624. Stopping sshd. Waiting for PIDS: 614. Stopping devd. Waiting for PIDS: 341. Writing entropy file:. Writing early boot entropy file:. . Terminated Jan 2 14:16:50 www syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Syncing disks, vnodes remaining... 3 Waiting (max 60 seconds) for system process `syncer' to stop... 4 3 2 1 0 0 1 0 0 done Waiting (max 60 seconds) for system process `bufdaemon' to stop... done All buffers synced. lock order reversal: 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271 2nd 0xc4828274 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2764 stack backtrace: lock order reversal: 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271 2nd 0xc4365814 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1410 stack backtrace: Uptime: 14h18m53s Rebooting... c� U-Boot 2015.04 (Jun 26 2017 - 22:31:06) DRAM: 944 MiB WARNING: Caches not enabled RPI 2 Model B MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr reading ubldr 293073 bytes read in 235 ms (1.2 MiB/s) ## Starting application at 0x02000098 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x3ab4b4c8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org) DRAM: 944MB Number of U-Boot devices: 1 U-Boot env: loaderdev='mmc 0' Found U-Boot device: disk Checking unit=0 slice= partition=... good. Booting from disk0s2a: /boot/kernel/kernel data=0x69ab94+0x1d946c syms=[0x4+0x72bd0+0x4+0xa6299] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x2200100... Kernel args: (null) At this point the only recourse seems to be cycling power. It was necessary to comment out the crossbuild tests in /usr/src/makefile.inc1 thus #.if make(buildworld) #BUILD_ARCH!= uname -p #.if ${MACHINE_ARCH} != ${BUILD_ARCH} #.error To cross-build, set TARGET_ARCH. #.endif #.endif to avoid stopping on the demand to set TARGET_ARCH error. In the past this practice caused no problems, but its necessity is puzzling. /etc/make.conf contains NO_CLEAN=yes KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 DESTDIR=/ #FORCE_PKG_REGISTER=yes DISABLE_VULNERABILITIES=yes MAKE_JOBS_UNSAFE=yes /etc/src.conf contains NO_CLEAN=yes KERNCONF=RPI2 TARGET=arm TARGET_ARCH=armv7 DESTDIR=/ Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jan 3 00:17:29 2018 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 F28BAE82504 for ; Wed, 3 Jan 2018 00:17:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-117.reflexion.net [208.70.210.117]) (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 B37457A381 for ; Wed, 3 Jan 2018 00:17:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10147 invoked from network); 2 Jan 2018 23:50:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 2 Jan 2018 23:50:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 02 Jan 2018 18:50:42 -0500 (EST) Received: (qmail 28868 invoked from network); 2 Jan 2018 23:50:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jan 2018 23:50:42 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9F866EC88A2; Tue, 2 Jan 2018 15:50:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 boot hangs with red light on From: Mark Millard In-Reply-To: <20180102222730.GB10596@www.zefox.net> Date: Tue, 2 Jan 2018 15:50:40 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> References: <20180102222730.GB10596@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:17:30 -0000 [My example here is for a non-debug kernel based on -r327485 --and also based on modern ports materials. The material is for reference only. I do not know what is happening in your context.] On 2018-Jan-2, at 2:27 PM, bob prohaska wrote: > An RPI2 with sources at 327493 > and kernel at 322520 makes and installs world and kernel, but > boot fails with the red LED stuck on. Starting with the reboot > command, the console reports >=20 > login: Jan 2 14:16:39 www shutdown: reboot by bob:=20 > Stopping cron. > Waiting for PIDS: 624. > Stopping sshd. > Waiting for PIDS: 614. > Stopping devd. > Waiting for PIDS: 341. > Writing entropy file:. > Writing early boot entropy file:. > . > Terminated > Jan 2 14:16:50 www syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop... done >=20 > Syncing disks, vnodes remaining... 3 Waiting (max 60 seconds) for = system process `syncer' to stop... 4 3 2 1 0 0 1 0 0 done > Waiting (max 60 seconds) for system process `bufdaemon' to stop... = done > All buffers synced. > lock order reversal: > 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271 > 2nd 0xc4828274 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2764 > stack backtrace: > lock order reversal: > 1st 0xc46a5274 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1271 > 2nd 0xc4365814 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1410 > stack backtrace: > Uptime: 14h18m53s > Rebooting... > c=EF=BF=BD >=20 > U-Boot 2015.04 (Jun 26 2017 - 22:31:06) This is older than is in ports these days [U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)]. > DRAM: 944 MiB > WARNING: Caches not enabled > RPI 2 Model B > MMC: bcm2835_sdhci: 0 > reading uboot.env >=20 > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment >=20 > In: serial > Out: lcd > Err: lcd > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 0=20 > Booting from: mmc 0 ubldr > reading ubldr > 293073 bytes read in 235 ms (1.2 MiB/s) > ## Starting application at 0x02000098 ... > Consoles: U-Boot console =20 > Compatible U-Boot API signature found @0x3ab4b4c8 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org) [Note that armv6 above.] What I get based on modern material is (and use of ubldr.bin instead of ubldr): Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 231872 bytes read in 32 ms (6.9 MiB/s) ## Starting application at 0x01000000 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @0x3af5d988 FreeBSD/armv7 U-Boot loader, Revision 1.2 I do not know if mixing older armv6 materials and newer armv7 materials has any problems. My context is all armv7 (cortex-a7 targeted). > DRAM: 944MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev=3D'mmc 0' > Found U-Boot device: disk > Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: > /boot/kernel/kernel data=3D0x69ab94+0x1d946c = syms=3D[0x4+0x72bd0+0x4+0xa6299] >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by U-Boot at address 0x100. Using modern materials indicated: /boot/dtb/bcm2836-rpi-2-b.dtb size=3D0x346b Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. > Kernel entry at 0x2200100... > Kernel args: (null) And I see on what I use: Kernel entry at 0x1200100... Kernel args: (null) I do not know if the vintage of materials has such a "Kernel entry" difference expected or not. After that I get: KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT r327485M arm FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on = LLVM 5.0.1) . . . > At this point the only recourse seems to be cycling power. >=20 >=20 > It was necessary to comment out the crossbuild tests in > /usr/src/makefile.inc1 thus I have had no such issue with my amd64 -> cortex-a7 cross builds for armv7. (Or for cortex-a53 for aarch64 as the target, or for powerpc64 or for powerpc.) I've not done self-hosted for the rpi2 in a long time. (I'm looking into other issues at this point and, so, will not start such a build at this time.) > #.if make(buildworld) > #BUILD_ARCH!=3D uname -p > #.if ${MACHINE_ARCH} !=3D ${BUILD_ARCH} > #.error To cross-build, set TARGET_ARCH. > #.endif > #.endif >=20 > to avoid stopping on the demand to set TARGET_ARCH error.=20 > In the past this practice caused no problems, but its necessity=20 > is puzzling.=20 >=20 > /etc/make.conf contains > NO_CLEAN=3Dyes I do not explicitly control NO_CLEAN. (Why here and in src.conf ?) > KERNCONF=3DRPI2 I use a file that includes GENERIC. As far as I know at this point RPI2 is no longer maintained. (Why here and in src.conf ?) > TARGET=3Darm > TARGET_ARCH=3Darmv7 > DESTDIR=3D/ For self hosted to the root file system I do not explicitly list/control DESTDIR. (Why here and in src.conf ?) > #FORCE_PKG_REGISTER=3Dyes > DISABLE_VULNERABILITIES=3Dyes > MAKE_JOBS_UNSAFE=3Dyes >=20 > /etc/src.conf contains > NO_CLEAN=3Dyes I do not explicitly control NO_CLEAN. > KERNCONF=3DRPI2 I use a file that includes GENERIC. As far as I know at this point RPI2 is no longer maintained. (I normally disable various debugging modes that GENERIC lists.) > TARGET=3Darm > TARGET_ARCH=3Darmv7 > DESTDIR=3D/ For self hosted to the root file system I do not explicitly list/control DESTDIR. > Thanks for reading, and any guidance! I boot with kernel, dtb file that the kernel uses, etc. being from a USB SSD stick on a powered hub. (u-boot uses a dtb file from a different place.) The text sequence for booting starts with. . . U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000) DRAM: 948 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e300000: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... 5 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 231872 bytes read in 32 ms (6.9 MiB/s) ## Starting application at 0x01000000 ... Consoles: U-Boot console =20 Compatible U-Boot API signature found @0x3af5d988 FreeBSD/armv7 U-Boot loader, Revision 1.2 DRAM: 948MB 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 disk0p1: /boot/kernel/kernel data=3D0x83a6dc+0x181924 = syms=3D[0x4+0x93900+0x4+0xd68cc] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 /boot/dtb/bcm2836-rpi-2-b.dtb size=3D0x346b Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. Kernel entry at 0x1200100... Kernel args: (null) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT r327485M arm FreeBSD clang version 5.0.1 (tags/RELEASE_501/final 320880) (based on = LLVM 5.0.1) . . . Note: The last time that I tried self hosted on an armv7 I used (not tailored to your intent, just for reference): # more /root/src.configs/src.conf.armv7-clang-bootstrap.armv7-host TO_TYPE=3Darmv7 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # # Linking lldb fails for armv7 WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D WITHOUT_LIBSOFT=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a7 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a7 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a7 (Direct use of -mcpu is not recommended but I happen to do so.) # more /root/src.configs/make.conf CFLAGS.gcc+=3D -v (Yep: essentially empty unless experimenting with gcc. Also ports use a separate /etc/make.conf . I do not use /etc/src.conf . See below.) # more = ~/sys_build_scripts.armv7-host/make_rpi2_nodebug_clang_bootstrap-armv7-hos= t.sh kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-armv7-host-= $(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.armv7-clang-bootstrap.armv7-hos= t" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/rpi2_clang/arm.armv7" \ make $* So my builds point to specific src.conf and make.conf files that are not in the default places. I normally use META_MODE. (Implicit NO_CLEAN involvement.) The modern ports involved are: sysutils/rpi-firmware sysutils/u-boot-rpi2 ubldr.bin for the fat file system is copied from the built /boot/ubldr.bin that is tied to the world build. rpi2.dtb for the fat file is from the kernel build's /boot/dtb/ . A way to see what comes from where and what goes to the fat file system is to look in the likes of: # more /usr/src/release/arm/RPI2.conf=20 #!/bin/sh # # $FreeBSD: head/release/arm/RPI2.conf 325950 2017-11-17 17:36:45Z gjb $ # EMBEDDED_TARGET_ARCH=3D"armv7" EMBEDDED_TARGET=3D"arm" EMBEDDEDBUILD=3D1 EMBEDDEDPORTS=3D"sysutils/u-boot-rpi2 sysutils/rpi-firmware" FAT_SIZE=3D"50m" FAT_TYPE=3D"16" IMAGE_SIZE=3D"3072M" KERNEL=3D"GENERIC" MD_ARGS=3D"-x 63 -y 255" NODOC=3D1 PART_SCHEME=3D"MBR" export BOARDNAME=3D"RPI2" arm_install_uboot() { UBOOT_DIR=3D"/usr/local/share/u-boot/u-boot-rpi2" RPI_FIRMWARE_DIR=3D"/usr/local/share/rpi-firmware" UBOOT_FILES=3D"u-boot.bin" RPI_FIRMWARE_FILES=3D"bootcode.bin config.txt \ fixup.dat fixup_cd.dat fixup_db.dat fixup_x.dat \ start.elf start_cd.elf start_db.elf start_x.elf" FATMOUNT=3D"${DESTDIR%${KERNEL}}/fat" UFSMOUNT=3D"${DESTDIR%${KERNEL}}/ufs" chroot ${CHROOTDIR} mkdir -p "${FATMOUNT}" "${UFSMOUNT}" chroot ${CHROOTDIR} mount_msdosfs /dev/${mddev}s1 ${FATMOUNT} chroot ${CHROOTDIR} mount /dev/${mddev}s2a ${UFSMOUNT} for _UF in ${UBOOT_FILES}; do chroot ${CHROOTDIR} cp -p ${UBOOT_DIR}/${_UF} \ ${FATMOUNT}/${_UF} done for _UF in ${RPI_FIRMWARE_FILES}; do chroot ${CHROOTDIR} cp -p ${RPI_FIRMWARE_DIR}/${_UF} \ ${FATMOUNT}/${_UF} done chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \ ${FATMOUNT}/ubldr.bin chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/dtb/rpi2.dtb \ ${FATMOUNT}/rpi2.dtb chroot ${CHROOTDIR} touch ${UFSMOUNT}/firstboot sync umount_loop ${CHROOTDIR}/${FATMOUNT} umount_loop ${CHROOTDIR}/${UFSMOUNT} chroot ${CHROOTDIR} rmdir ${FATMOUNT} chroot ${CHROOTDIR} rmdir ${UFSMOUNT} =20 return 0 } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 02:33:06 2018 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 DDE61EBFC38 for ; Thu, 4 Jan 2018 02:33:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B51774764 for ; Thu, 4 Jan 2018 02:33:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w042WwHI015437 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 18:32:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w042Wvn5015436; Wed, 3 Jan 2018 18:32:57 -0800 (PST) (envelope-from fbsd) Date: Wed, 3 Jan 2018 18:32:57 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 boot hangs with red light on Message-ID: <20180104023257.GA15177@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 02:33:07 -0000 On Tue, Jan 02, 2018 at 03:50:40PM -0800, Mark Millard wrote: > > On 2018-Jan-2, at 2:27 PM, bob prohaska wrote: > > > > > U-Boot 2015.04 (Jun 26 2017 - 22:31:06) > > This is older than is in ports these days > [U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)]. > Very true. > > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org) > > [Note that armv6 above.] > That does give me pause, but the kernel went to v7 at least a few build/install cycles ago and seemed to boot fine.... > What I get based on modern material is > (and use of ubldr.bin instead of ubldr): > Both ubldr and ubldr.bin are present in /boot and date from Jan 2nd. > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 231872 bytes read in 32 ms (6.9 MiB/s) > ## Starting application at 0x01000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x3af5d988 > > FreeBSD/armv7 U-Boot loader, Revision 1.2 > > > I do not know if mixing older armv6 materials > and newer armv7 materials has any problems. My > context is all armv7 (cortex-a7 targeted). > It didn't initially, far as I can tell. There's nothing obvious in /usr/src/UPDATING about a need to alter u-boot, though there is a reference to new variable names in November. None seem applicable to the Pi. > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > Using DTB provided by U-Boot at address 0x100. > > Using modern materials indicated: > > /boot/dtb/bcm2836-rpi-2-b.dtb size=0x346b > Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. > > > Kernel entry at 0x2200100... > > Kernel args: (null) > > And I see on what I use: > > Kernel entry at 0x1200100... > Kernel args: (null) > This looks very different. It's plausible that u-boot needs to be updated, but it'd be nice to see confirmation somewhere. Needless changes are a good way to push problems past redemption. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jan 4 02:59:01 2018 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 33E78EC13B3 for ; Thu, 4 Jan 2018 02:59:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-162.reflexion.net [208.70.210.162]) (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 CB471758AC for ; Thu, 4 Jan 2018 02:58:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23085 invoked from network); 4 Jan 2018 02:52:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Jan 2018 02:52:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 03 Jan 2018 21:52:13 -0500 (EST) Received: (qmail 27583 invoked from network); 4 Jan 2018 02:52:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2018 02:52:13 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ECA49EC7E18; Wed, 3 Jan 2018 18:52:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 boot hangs with red light on From: Mark Millard In-Reply-To: <20180104023257.GA15177@www.zefox.net> Date: Wed, 3 Jan 2018 18:52:12 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 02:59:01 -0000 [ubldr.bin needs to be copied to the msdosfs.] On 2018-Jan-3, at 6:32 PM, bob prohaska wrote: > On Tue, Jan 02, 2018 at 03:50:40PM -0800, Mark Millard wrote: >> >> On 2018-Jan-2, at 2:27 PM, bob prohaska wrote: >> >>> >>> U-Boot 2015.04 (Jun 26 2017 - 22:31:06) >> >> This is older than is in ports these days >> [U-Boot 2017.09 (Dec 16 2017 - 03:23:07 +0000)]. >> > > Very true. > >>> >>> FreeBSD/armv6 U-Boot loader, Revision 1.2 >>> (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org) >> >> [Note that armv6 above.] >> > > That does give me pause, but the kernel went to v7 at least > a few build/install cycles ago and seemed to boot fine.... > >> What I get based on modern material is >> (and use of ubldr.bin instead of ubldr): >> > > Both ubldr and ubldr.bin are present in /boot and date from Jan 2nd. That is where they are built but for the rpi2 that is not the copy used during boot: ubldr.bin needs to be copied to the msdosfs. (The following is based on modern materials, as that is what I have for reference.) In the original reply I'd quoted /usr/src/release/arm/RPI2.conf and part of that was: chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/ubldr.bin \ ${FATMOUNT}/ubldr.bin chroot ${CHROOTDIR} cp -p ${UFSMOUNT}/boot/dtb/rpi2.dtb \ ${FATMOUNT}/rpi2.dtb For modern materials ubldr.bin and rpi2.dtb are supposed to be copied to the msdosfs, with the rpifirmware materials and the like. The stages prior to the kernel load and its own dtb load are not from the UFS file system but from msdosfs. ubldr.bin and/or ubldr need to be copied over for older rpifirmware and u-boot-rpi2 materials as well as I understand. The copy that is on the msdosfs is the one being used (and so controls the vintage of ubldr.bin or ubldr that is used). >> Found FreeBSD U-Boot Loader (bin) >> reading ubldr.bin >> 231872 bytes read in 32 ms (6.9 MiB/s) >> ## Starting application at 0x01000000 ... >> Consoles: U-Boot console >> Compatible U-Boot API signature found @0x3af5d988 >> >> FreeBSD/armv7 U-Boot loader, Revision 1.2 >> >> >> I do not know if mixing older armv6 materials >> and newer armv7 materials has any problems. My >> context is all armv7 (cortex-a7 targeted). >> > > It didn't initially, far as I can tell. There's nothing obvious in > /usr/src/UPDATING about a need to alter u-boot, though there is a > reference to new variable names in November. None seem applicable > to the Pi. > >>> Hit [Enter] to boot immediately, or any other key for command prompt. >>> Booting [/boot/kernel/kernel]... >>> Using DTB provided by U-Boot at address 0x100. >> >> Using modern materials indicated: >> >> /boot/dtb/bcm2836-rpi-2-b.dtb size=0x346b >> Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. >> >>> Kernel entry at 0x2200100... >>> Kernel args: (null) >> >> And I see on what I use: >> >> Kernel entry at 0x1200100... >> Kernel args: (null) >> > > This looks very different. > > It's plausible that u-boot needs to be updated, but it'd be nice to see > confirmation somewhere. Needless changes are a good way to push problems > past redemption. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 04:21:43 2018 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 A2E91E856F4 for ; Thu, 4 Jan 2018 04:21:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 403F978D2A for ; Thu, 4 Jan 2018 04:21:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: be2e8885-f106-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id be2e8885-f106-11e7-8dac-d32f5c2d02ef; Thu, 04 Jan 2018 04:21:33 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w044LTe1002394; Wed, 3 Jan 2018 21:21:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515039689.1759.27.camel@freebsd.org> Subject: Re: RPI2 boot hangs with red light on From: Ian Lepore To: bob prohaska Cc: freebsd-arm@freebsd.org Date: Wed, 03 Jan 2018 21:21:29 -0700 In-Reply-To: <20180104023257.GA15177@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 04:21:43 -0000 On Wed, 2018-01-03 at 18:32 -0800, bob prohaska wrote: > > > >  > > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > > > (Mon Jun 26 22:46:48 UTC 2017 root@releng3.nyi.freebsd.org) > >  > > [Note that armv6 above.] > >  > > That does give me pause, but the kernel went to v7 at least > a few build/install cycles ago and seemed to boot fine.... There are no architectural differences between ubldr built for armv6 vs armv7, and either version could load either flavor of kernel.  There have been some bugfixes applied to ubldr in the past few months. -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 4 04:28:21 2018 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 8DF2BE85AAE for ; Thu, 4 Jan 2018 04:28:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 507B278EDF for ; Thu, 4 Jan 2018 04:28:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w044SIX2015683 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 20:28:18 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w044SHYu015682; Wed, 3 Jan 2018 20:28:17 -0800 (PST) (envelope-from fbsd) Date: Wed, 3 Jan 2018 20:28:17 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 boot hangs with red light on Message-ID: <20180104042817.GB15177@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 04:28:21 -0000 On Wed, Jan 03, 2018 at 06:52:12PM -0800, Mark Millard wrote: > [ubldr.bin needs to be copied to the msdosfs.] > Ok, rather clearly I've got things misconfigured. I'll try to clean up the mess before doing anything else. Thank you very much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jan 4 05:42:39 2018 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 3868BE8B9B5 for ; Thu, 4 Jan 2018 05:42:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DAE987AF8D; Thu, 4 Jan 2018 05:42:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w045gbkk015841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 21:42:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w045gafF015840; Wed, 3 Jan 2018 21:42:37 -0800 (PST) (envelope-from fbsd) Date: Wed, 3 Jan 2018 21:42:36 -0800 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI2 boot hangs with red light on Message-ID: <20180104054236.GA15764@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515039689.1759.27.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 05:42:39 -0000 On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote: > > There are no architectural differences between ubldr built for armv6 vs > armv7, and either version could load either flavor of kernel. ?There > have been some bugfixes applied to ubldr in the past few months. > > -- Ian It seems the problems lie elsewhere. I've updated the contents of /boot/msdos to -rwxr-xr-x 1 root wheel 1494 Jan 3 20:45 LICENCE.broadcom -rwxr-xr-x 1 root wheel 50248 Jan 3 20:45 bootcode.bin -rwxr-xr-x 1 root wheel 75 Jan 3 20:45 config.txt -rwxr-xr-x 1 root wheel 6551 Jan 3 20:45 fixup.dat -rwxr-xr-x 1 root wheel 2578 Jan 3 20:45 fixup_cd.dat -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_db.dat -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_x.dat -rwxr-xr-x 1 root wheel 13419 Jun 26 2017 rpi2.dtb -rwxr-xr-x 1 root wheel 2820196 Jan 3 20:45 start.elf -rwxr-xr-x 1 root wheel 667460 Jan 3 20:45 start_cd.elf -rwxr-xr-x 1 root wheel 4956676 Jan 3 20:45 start_db.elf -rwxr-xr-x 1 root wheel 3904228 Jan 3 20:45 start_x.elf -rwxr-xr-x 1 root wheel 380264 Jan 3 20:33 u-boot.bin -rwxr-xr-x 1 root wheel 892172 Jan 3 20:48 ubldr -rwxr-xr-x 1 root wheel 232112 Jan 3 20:48 ubldr.bin (yes, rpi2.dtb is stale, but it seems not to matter) A hands-off boot now looks like this: U-Boot 2017.09 (Jan 02 2018 - 23:46:36 -0800) DRAM: 948 MiB RPI 2 Model B (0xa21041) MMC: sdhci@7e300000: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... USB0: Core Release: 2.80a scanning bus 0 for devices... unable to get device descriptor (error=-22) ** First descriptor is NOT a primary desc on 0:1 ** 7 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 2 Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint 1 Timeout poll on interrupt endpoint 0 Timeout poll on interrupt endpoint switch to partitions #0, OK mmc0 is current device Timeout poll on interrupt endpoint Scanning mmc 0:1... Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 232112 bytes read in 38 ms (5.8 MiB/s) ## Starting application at 0x01000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x3af5d988 FreeBSD/armv7 U-Boot loader, Revision 1.2 (Mon Jan 1 16:41:31 PST 2018 bob@www.zefox.com) DRAM: 948MB 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=0 slice= partition=... Checking unit=1 slice= partition=... good. Booting from disk1s2a: /boot/kernel/kernel data=0x69ab94+0x1d946c syms=[0x4+0x72bd0+0x4+0xa6299] Hit [Enter] to boot immediately, or any other key for command prompt. Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 9 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 8 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 7 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 6 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 5 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 4 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 3 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 2 seconds... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel] in 1 second... Timeout poll on interrupt endpoint Booting [/boot/kernel/kernel]... /boot/dtb/bcm2836-rpi-2-b.dtb size=0x308d Loaded DTB from file 'bcm2836-rpi-2-b.dtb'. Kernel entry at 0x1200100... Kernel args: (null) It looks as if /boot/kernel loads but won't run, and /boot/kernel.spare, which formerly ran, no longer does. Curiously, an intermediate kernel, which didn't run, now loads and starts but halts with ugen0.8: at usbus0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number AA010509160727180727 da0: 40.000MB/s transfers da0: 59836MB (122544516 512 byte sectors) da0: quirks=0x2 Release APs WARNING: WITNESS option enabled, expect reduced performance. random: unblocking device. arc4random: no preloaded entropy cache Trying to mount root from ufs:/dev/ufs/rootfs [rw]... arc4random: no preloaded entropy cache arc4random: no preloaded entropy cache In this case the red LED is off. The behavior of the status LEDs remains quite different from formerly. Long-time behavior was a flash of red, then dark. Later, it's red on and a flash of green, with red staying on until the kernel started and both went dark. It's been pointed out that the RPI2 kernel is deprecated, and this is an RPI2 kernel. Might that be at least part of the trouble? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jan 4 06:08:32 2018 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 EC185EA252E for ; Thu, 4 Jan 2018 06:08:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-104.reflexion.net [208.70.210.104]) (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 9B9AF7B9F9 for ; Thu, 4 Jan 2018 06:08:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6817 invoked from network); 4 Jan 2018 06:08:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Jan 2018 06:08:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 01:08:25 -0500 (EST) Received: (qmail 28215 invoked from network); 4 Jan 2018 06:08:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2018 06:08:25 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 888A8EC7E18; Wed, 3 Jan 2018 22:08:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 boot hangs with red light on From: Mark Millard In-Reply-To: <20180104054236.GA15764@www.zefox.net> Date: Wed, 3 Jan 2018 22:08:23 -0800 Cc: Ian Lepore , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F956676-D79F-473B-88FE-43E452F11B83@dsl-only.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> <20180104054236.GA15764@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 06:08:33 -0000 On 2018-Jan-3, at 9:42 PM, bob prohaska wrote: > On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote: > . . . >=20 > It looks as if /boot/kernel loads but won't run, and = /boot/kernel.spare, which > formerly ran, no longer does. Curiously, an intermediate kernel, which = didn't > run, now loads and starts but halts with >=20 > ugen0.8: at usbus0 > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SPC-4 SCSI device > da0: Serial Number AA010509160727180727 > da0: 40.000MB/s transfers > da0: 59836MB (122544516 512 byte sectors) > da0: quirks=3D0x2 > Release APs > WARNING: WITNESS option enabled, expect reduced performance. > random: unblocking device. > arc4random: no preloaded entropy cache > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > arc4random: no preloaded entropy cache > arc4random: no preloaded entropy cache I've seen this "hang point" on a Pine64+ 2GB in the past. Hanging here is something addressed by the "UMA limit" part of head -r327485 . Bugzilla 224330 has material about it. As I understand -r326347 is what broke that specific aspect of things. (It had other issues as well, and apparently causes some other problem to show up that was previous hidden.) As for -r327485: Author: jeff Date: Tue Jan 2 04:35:56 2018 New Revision: 327485 URL:=20 https://svnweb.freebsd.org/changeset/base/327485 Log: Fix arc after r326347 broke various memory limit queries. Use UMA = features rather than kmem arena size to determine available memory. =20 Initialize the UMA limit to LONG_MAX to avoid spurious wakeups on boot = before the real limit is set. =20 PR: 224330 (partial), 224080 Reviewed by: markj, avg Sponsored by: Netflix / Dell EMC Isilon Differential Revision:=09 https://reviews.freebsd.org/D13494 . . . The "arc" reference is a ZFS file system handling issue. Note: I've no clue for "Timeout poll on interrupt endpoint". I've never seen such before. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 06:33:56 2018 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 32160EA2E44 for ; Thu, 4 Jan 2018 06:33:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-122.reflexion.net [208.70.210.122]) (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 D440B7C48E for ; Thu, 4 Jan 2018 06:33:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19364 invoked from network); 4 Jan 2018 06:33:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Jan 2018 06:33:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 01:33:54 -0500 (EST) Received: (qmail 17314 invoked from network); 4 Jan 2018 06:33:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2018 06:33:53 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4031AEC7E18; Wed, 3 Jan 2018 22:33:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 boot hangs with red light on From: Mark Millard In-Reply-To: <2F956676-D79F-473B-88FE-43E452F11B83@dsl-only.net> Date: Wed, 3 Jan 2018 22:33:52 -0800 Cc: Freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <585E8553-E290-4E6F-B05F-43A58E98F076@dsl-only.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> <20180104054236.GA15764@www.zefox.net> <2F956676-D79F-473B-88FE-43E452F11B83@dsl-only.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 06:33:56 -0000 On 2018-Jan-3, at 10:08 PM, Mark Millard wrote: > On 2018-Jan-3, at 9:42 PM, bob prohaska wrote: >=20 >> On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote: >> . . . >>=20 >> It looks as if /boot/kernel loads but won't run, and = /boot/kernel.spare, which >> formerly ran, no longer does. Curiously, an intermediate kernel, = which didn't >> run, now loads and starts but halts with >>=20 >> ugen0.8: at usbus0 >> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >> da0: Removable Direct Access SPC-4 SCSI device >> da0: Serial Number AA010509160727180727 >> da0: 40.000MB/s transfers >> da0: 59836MB (122544516 512 byte sectors) >> da0: quirks=3D0x2 >> Release APs >> WARNING: WITNESS option enabled, expect reduced performance. >> random: unblocking device. >> arc4random: no preloaded entropy cache >> Trying to mount root from ufs:/dev/ufs/rootfs [rw]... >> arc4random: no preloaded entropy cache >> arc4random: no preloaded entropy cache >=20 > I've seen this "hang point" on a Pine64+ 2GB > in the past. >=20 > Hanging here is something addressed by the > "UMA limit" part of head -r327485 . Bugzilla > 224330 has material about it. As I understand > -r326347 is what broke that specific aspect > of things. (It had other issues as well, > and apparently causes some other problem to > show up that was previous hidden.) >=20 > As for -r327485: >=20 > Author: jeff > Date: Tue Jan 2 04:35:56 2018 > New Revision: 327485 > URL:=20 > https://svnweb.freebsd.org/changeset/base/327485 >=20 >=20 > Log: > Fix arc after r326347 broke various memory limit queries. Use UMA = features > rather than kmem arena size to determine available memory. >=20 > Initialize the UMA limit to LONG_MAX to avoid spurious wakeups on = boot before > the real limit is set. >=20 > PR: 224330 (partial), 224080 > Reviewed by: markj, avg > Sponsored by: Netflix / Dell EMC Isilon > Differential Revision:=09 > https://reviews.freebsd.org/D13494 > . . . >=20 >=20 > The "arc" reference is a ZFS file system handling issue. >=20 >=20 >=20 > Note: I've no clue for "Timeout poll on interrupt endpoint". > I've never seen such before. I found the error message text for "Timeout poll . . ." in (for example) u-boot/blob/master/drivers/usb/host/dwc2.c in a routine named submit_int_msg (sometimes with a leading "_"). I did not find the message in a "grep -r" of /user/src/ . The above was from web searching. All I can conclude from these it is it appears that u-boot code might be generating the messages. I'm not familiar with any of this material. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 07:14:54 2018 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 C93E0EA4B30 for ; Thu, 4 Jan 2018 07:14:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-134.reflexion.net [208.70.210.134]) (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 6F0BF7D48F for ; Thu, 4 Jan 2018 07:14:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23678 invoked from network); 4 Jan 2018 07:08:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jan 2018 07:08:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 02:08:07 -0500 (EST) Received: (qmail 29647 invoked from network); 4 Jan 2018 07:08:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2018 07:08:07 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 873F7EC7B31; Wed, 3 Jan 2018 23:08:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RPI2 boot hangs with red light on From: Mark Millard In-Reply-To: <20180104054236.GA15764@www.zefox.net> Date: Wed, 3 Jan 2018 23:08:06 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <802335D5-A961-4ABB-91D8-97B108106BEB@dsl-only.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> <20180104054236.GA15764@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 07:14:54 -0000 On 2018-Jan-3, at 9:42 PM, bob prohaska wrote: > On Wed, Jan 03, 2018 at 09:21:29PM -0700, Ian Lepore wrote: >> >> There are no architectural differences between ubldr built for armv6 vs >> armv7, and either version could load either flavor of kernel. ?There >> have been some bugfixes applied to ubldr in the past few months. >> >> -- Ian > > It seems the problems lie elsewhere. I've updated the contents of > /boot/msdos to > -rwxr-xr-x 1 root wheel 1494 Jan 3 20:45 LICENCE.broadcom > -rwxr-xr-x 1 root wheel 50248 Jan 3 20:45 bootcode.bin > -rwxr-xr-x 1 root wheel 75 Jan 3 20:45 config.txt > -rwxr-xr-x 1 root wheel 6551 Jan 3 20:45 fixup.dat > -rwxr-xr-x 1 root wheel 2578 Jan 3 20:45 fixup_cd.dat > -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_db.dat > -rwxr-xr-x 1 root wheel 9694 Jan 3 20:45 fixup_x.dat > -rwxr-xr-x 1 root wheel 13419 Jun 26 2017 rpi2.dtb > -rwxr-xr-x 1 root wheel 2820196 Jan 3 20:45 start.elf > -rwxr-xr-x 1 root wheel 667460 Jan 3 20:45 start_cd.elf > -rwxr-xr-x 1 root wheel 4956676 Jan 3 20:45 start_db.elf > -rwxr-xr-x 1 root wheel 3904228 Jan 3 20:45 start_x.elf > -rwxr-xr-x 1 root wheel 380264 Jan 3 20:33 u-boot.bin > -rwxr-xr-x 1 root wheel 892172 Jan 3 20:48 ubldr > -rwxr-xr-x 1 root wheel 232112 Jan 3 20:48 ubldr.bin > (yes, rpi2.dtb is stale, but it seems not to matter) . . . I do not have ubldr, just ubldr.bin. Other than that, the sizes of the files listed above all match the sizes on the msdosfs partition that I use for the rpi2. (My dates are all Dec 22 but the rpi2's time may not have had a good combination of accuracy and precision.) "unable to get device descriptor (error=-22)" is from u-boot/blob/master/common/usb.c and its usb_new_device routine from what I can tell. It's cause and consequences might have contributed to the "Timeout poll on interrupt endpoint" messages from u-boot. May be eliminating all the usb devices that you can might sidestep some issue? (Also avoid from -r326347 through -r327484 for head: before or after as far as the kernel goes.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 14:45:00 2018 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 26F51EB9553 for ; Thu, 4 Jan 2018 14:45:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D23AD6C612 for ; Thu, 4 Jan 2018 14:44:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w04Eiu7W017463 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Jan 2018 06:44:57 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w04Eita5017462; Thu, 4 Jan 2018 06:44:55 -0800 (PST) (envelope-from fbsd) Date: Thu, 4 Jan 2018 06:44:55 -0800 From: bob prohaska To: Mark Millard Cc: Freebsd-arm , bob prohaska Subject: Re: RPI2 boot hangs with red light on Message-ID: <20180104144455.GA17191@www.zefox.net> References: <20180102222730.GB10596@www.zefox.net> <3EE68320-8359-495D-AFCE-098A2220C6AE@dsl-only.net> <20180104023257.GA15177@www.zefox.net> <1515039689.1759.27.camel@freebsd.org> <20180104054236.GA15764@www.zefox.net> <802335D5-A961-4ABB-91D8-97B108106BEB@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <802335D5-A961-4ABB-91D8-97B108106BEB@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:45:00 -0000 On Wed, Jan 03, 2018 at 11:08:06PM -0800, Mark Millard wrote: > > "unable to get device descriptor (error=-22)" is from > u-boot/blob/master/common/usb.c and its usb_new_device > routine from what I can tell. It's cause and > consequences might have contributed to the "Timeout > poll on interrupt endpoint" messages from u-boot. > > May be eliminating all the usb devices that you can > might sidestep some issue? > Excellent call, removing mouse, keyboard and pl2303TA adapter eliminate the timeout messages and make the console much easier to use. Only the USB flash drive holding /usr, /var, /tmp and swap remains. It looks as if u-boot and loader are both behaving reasonably; they respond to commands, with no extraneous output. A hands-off boot still fails silently with the red LED stuck on, for both /boot/kernel and /boot/kernel.spare. /boot/kernel.old, at r327228, _does_ boot, but with errors, like so: ..... Mounting late filesystems:. Jan 4 05:38:10 www kernel: pid 502 (cp), uid 0 inumber 53912 on /: filesystem full Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting sendmail. Starting sendmail_msp_queue. Starting cron. Starting background file system checks in 60 seconds. Thu Jan 4 05:38:13 PST 2018 FreeBSD/arm (www.zefox.com) (ttyu0) login: UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x9e441246 != bp: 0xfa67bf3a UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: 0x9e441246 != bp: 0xfa67bf3a handle_workitem_freefile: got error 5 while accessing filesystem Login on the console worked, repeated fsck -f cycles permitted return to multi-user without errors. Sources are now updated to 327548, /boot/kernel.old has been copied over /boot/kernel.spare and a new cycle of build/install in /usr/src is running. Thanks _very_ much! bob prohaska From owner-freebsd-arm@freebsd.org Thu Jan 4 19:28:00 2018 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 A1FEBEB05C7 for ; Thu, 4 Jan 2018 19:28:00 +0000 (UTC) (envelope-from hannah.layne@cloudserverdb.com) Received: from server.centrixwareplm.com (server.centrixwareplm.com [158.69.254.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71B417B3ED for ; Thu, 4 Jan 2018 19:28:00 +0000 (UTC) (envelope-from hannah.layne@cloudserverdb.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cloudserverdb.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1jc1E4fyiy0p1cvcwrqOV4itTe06Fpk01gWcITx0PKk=; b=p3qEka7+Ydf8xRFWAOxoAkmFee e0+EfSw751vG2oOgEmfMhCx+bDp5Fykcjt7Y1F19p5vhVFA9t6kCK+vauVmLy7uJfVC5D51IS5aT+ n/1w89rszc4Bcmzf3IP4ra9WJgMggobMH4HWzy+yDAVHVvoNRX65ylfc6dhUoivrovx5goGOCY8qF fYJ3Np0VnRP2kpnzo1QH8ks/q8rkJWJnk4X9dhFlrZkj0Ki+DigtSnTnpZ1KeZVym8zaqnuh+gPSw ZyiaUu7YWt0CaENnTehhvF+yv48JYL1+KjkLaZnricG5eURlfqCErxzVlaS5TPeKqYNAxtT3KVNY3 bhCWM8NA==; Received: from [103.87.129.18] (port=50768 helo=DESKTOPHRUQTER) by server.centrixwareplm.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eXAmu-0002Fl-5F for freebsd-arm@freebsd.org; Thu, 04 Jan 2018 14:02:48 -0500 From: "Hannah Layne" To: Subject: Follow-up Date: Thu, 4 Jan 2018 14:00:08 -0500 Message-ID: <7b8a01d3858e$9d0706d0$d7151470$@cloudserverdb.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdOFjjJnlS2R6oWpTeyjvgZM42VEgw== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.centrixwareplm.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - cloudserverdb.com X-Get-Message-Sender-Via: server.centrixwareplm.com: authenticated_id: hannah.layne@cloudserverdb.com X-Authenticated-Sender: server.centrixwareplm.com: hannah.layne@cloudserverdb.com X-Source: X-Source-Args: X-Source-Dir: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:28:00 -0000 Hello , Hope all is well! I was trying to reach you today in regards to an email I sent you last quarter. Any chance you can review the below email and let me know if this information is still of interest to you. We are a database organization. We provide Business executives contact information. This information can be used for marketing initiatives like, Email marketing, Direct mail marketing and cold calling. With so many database offers these days- it's very difficult to know who has the right contact data. Get some samples before you decide on your database vendor. Please email me the following parameters to run counts and samples for your review: Industry: Geography: Titles: Keep me informed for any additional details. I look forward to hearing from you. Regards Hannah Layne Folsom Street, San Francisco, CA 94013, USA If you don't wish to receive emails from us reply back with "Leave Out". ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ----------------------- From: Hannah Layne < hannah.layne@cloudserverdb.com> Sent: Monday, November 13, 2017 11:46 AM To: freebsd-arm@freebsd.org Subject: RE: Conference Call Hello , This is Hannah from Cloudserverdb. We are a database organization. We provide Business executive contact information. Below are few examples: Industry Specific Lists: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer Services, Cultural, Education, Energy, Utilities & Waste Treatment, Finance, Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services, Manufacturing, Media & Internet, Metals & Mining, Organizations, Real Estate, Retail, Software, Telecommunications, Transportation etc.. Technology specific Lists SAP users list, PeopleSoft Users list, SIEBEL customers List, Oracle Application Customers List, Microsoft Dynamic user List, Sales force User List, Microsoft Exchange user List, Quick Books List, Lawson Users List, Act Users List , JD Edward Users List, ASP Users List, Microsoft GP Applications Users List, Net Suite Users List, IBM DBMS Application Users List, McAfee Users List, MS Dynamics GP (Great Plains) and many more Title Specific Lists: C-level executives List - CEO, CFO, CIO, CTO, CMO, CISO, CSO, COO Key decision makers List - All C-level, VP level, Director level executives HR Executives List - VP of HR, HR Director & HR Manager etc., Marketing Executives List - CMO, VP of Marketing, Director of Marketing, Marketing Managers IT Executives List - CIO, CTO, CISO, IT-VP, IT-Director, IT Manager, MIS Manager etc., Thanks and let me know. Hannah Layne Folsom Street , San Francisco, CA 94013, USA If you don't wish to receive emails from us reply back "Leave Out". From owner-freebsd-arm@freebsd.org Thu Jan 4 22:47:04 2018 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 F2366EBD672 for ; Thu, 4 Jan 2018 22:47:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-164.reflexion.net [208.70.210.164]) (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 9F70E6538B for ; Thu, 4 Jan 2018 22:47:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28975 invoked from network); 4 Jan 2018 22:40:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 4 Jan 2018 22:40:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 17:40:23 -0500 (EST) Received: (qmail 11370 invoked from network); 4 Jan 2018 22:40:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jan 2018 22:40:22 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 350BAEC7A6E; Thu, 4 Jan 2018 14:40:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 Message-Id: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> Date: Thu, 4 Jan 2018 14:40:21 -0800 To: Freebsd-arm , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 22:47:05 -0000 All the below were: NO_ZFS=3Dyes , USE_TMPFS=3Dno , not using cccache, PARALLEL_JOBS=3D1 , ALLOW_MAKE_JOBS=3Dyes . On the RPi2 V1.1 I also set: MAX_EXECUTION_TIME=3D432000 , NOHANG_TIME=3D28800 . Pine64+ 2GB: (so, 2GiBytes of RAM on cortex-a53, eMMC in usdcard slot = via adapter) [05:45:14] [01] [00:00:00] Building devel/llvm50 | llvm50-5.0.0_6 [20:02:56] [01] [14:17:42] Finished devel/llvm50 | llvm50-5.0.0_6: = Success RPi3: (1 GiByte of RAM on cortex-a53, eMMC in usdcard slot via adapter) [03:43:37] [01] [00:00:00] Building devel/llvm50 | llvm50-5.0.0_6 [22:56:56] [01] [19:13:19] Finished devel/llvm50 | llvm50-5.0.0_6: = Success RPi2 V1.1: (1 GiByte of RAM on cortex-a7, USB SSD Stick on powered hub) [04:20:51] [01] [00:00:00] Building devel/llvm50 | llvm50-5.0.0_6 [37:40:02] [01] [33:19:11] Finished devel/llvm50 | llvm50-5.0.0_6: = Success (Somewhat under 2 hr 25 min of that in package.) These were all with default options for devel/llvm50. eMCC performance notes: The rpi3 can get between 10 MiByte/s and 12 MiByte/s, while the Pine64+ 2GB can get between 5 MiBytes/s and 6 MiBytes/s, from what I have observed. Swap partition notes: All 3 had significant swap space configured. The RPi3 and RPi2 needed several hundred MiBytes, I had configured around 1.5 GiBytes. Building devel/cmake used more than building devel/llvm50 , at least on the RPi2: 973 MiBytes was observed in top for devel/cmake on the RPi2. poudriere-devel note: I had adjusted the non-parameterized, hard-coded timeouts in poudriere's scripts for the RPi2 V1.1 so that, for example, package would be allowed to finish. MAX_EXECUTION_TIME and NOHANG_TIME adjustments do not cause some stages to scale the time allowed. top note: I run a modified top that keeps track of and reports the "maximum observed used" figure for the swap usage. So that figure is a low bound on the actual maximum while top was monitoring. For reference: # uname -apKU FreeBSD rpi2 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M arm armv7 = 1200054 1200054 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 457579 Last Changed Rev: 457579 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jan 4 23:40:51 2018 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 20280EC0972 for ; Thu, 4 Jan 2018 23:40:51 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 B9DAD6789F for ; Thu, 4 Jan 2018 23:40:50 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4dbb0574.dyn.telefonica.de [77.187.5.116]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id w04NelkC008460 for ; Fri, 5 Jan 2018 00:40:47 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Freebsd-arm Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Fri, 05 Jan 2018 00:40:45 +0100 (CET) Message-ID: <4b428a608dd.290862fc@mail.schwarzes.net> In-Reply-To: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> References: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Fri, 05 Jan 2018 00:40:47 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:40:51 -0000 On 04.01.18, Mark Millard wrote: > eMCC performance notes: > The rpi3 can get between 10 MiByte/s and > 12 MiByte/s, while the Pine64+ 2GB can get > between 5 MiBytes/s and 6 MiBytes/s, from > what I have observed. Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow in comparsion to RPI2B (or RPI3). root@rpi2b:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec) root@pine64plus:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec) Both devices running r327391 with without any debugging, INVARIANTS, etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB Mark, can you perform the write test with your eMMC to MicroSD Adapter? -asc From owner-freebsd-arm@freebsd.org Thu Jan 4 23:46:27 2018 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 80F3DEC0E6E for ; Thu, 4 Jan 2018 23:46:27 +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 6436D67C69 for ; Thu, 4 Jan 2018 23:46:26 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6faedc88-f1a9-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 6faedc88-f1a9-11e7-8486-0934409070aa; Thu, 04 Jan 2018 23:46:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w04NkO0Y002073; Thu, 4 Jan 2018 16:46:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515109584.1759.32.camel@freebsd.org> Subject: Re: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 From: Ian Lepore To: Andreas Schwarz , Freebsd-arm Date: Thu, 04 Jan 2018 16:46:24 -0700 In-Reply-To: <4b428a608dd.290862fc@mail.schwarzes.net> References: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> <4b428a608dd.290862fc@mail.schwarzes.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 23:46:27 -0000 On Fri, 2018-01-05 at 00:40 +0100, Andreas Schwarz wrote: > On 04.01.18, Mark Millard wrote: > > > > > eMCC performance notes: > > The rpi3 can get between 10 MiByte/s and > > 12 MiByte/s, while the Pine64+ 2GB can get > > between 5 MiBytes/s and 6 MiBytes/s, from > > what I have observed. > Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow  > in comparsion to RPI2B (or RPI3). > > root@rpi2b:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec) > > root@pine64plus:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec) > > Both devices running r327391 with without any debugging, INVARIANTS,  > etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB > > Mark, can you perform the write test with your eMMC to MicroSD  > Adapter? > > -asc It used to be that clang used files in /tmp to pass results between stages of the compile whereas gcc used pipes.  I'm not sure if that's still true, but if it is, then using tmpfs for /tmp should improve compile times and remove much of the sdcard performance impact. -- Ian From owner-freebsd-arm@freebsd.org Fri Jan 5 00:19:42 2018 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 AECE9EC2C65 for ; Fri, 5 Jan 2018 00:19:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-134.reflexion.net [208.70.210.134]) (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 5EC0B68C6A for ; Fri, 5 Jan 2018 00:19:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13388 invoked from network); 5 Jan 2018 00:19:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 00:19:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 19:19:40 -0500 (EST) Received: (qmail 574 invoked from network); 5 Jan 2018 00:19:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 00:19:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BD595EC7A6E; Thu, 4 Jan 2018 16:19:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 From: Mark Millard In-Reply-To: <1515109584.1759.32.camel@freebsd.org> Date: Thu, 4 Jan 2018 16:19:39 -0800 Cc: Andreas Schwarz , Freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <4877B065-798C-420C-80C2-D84AEC148243@dsl-only.net> References: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> <4b428a608dd.290862fc@mail.schwarzes.net> <1515109584.1759.32.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 00:19:42 -0000 On 2018-Jan-4, at 3:46 PM, Ian Lepore wrote: > On Fri, 2018-01-05 at 00:40 +0100, Andreas Schwarz wrote: >> On 04.01.18, Mark Millard wrote: >> >>> >>> eMCC performance notes: >>> The rpi3 can get between 10 MiByte/s and >>> 12 MiByte/s, while the Pine64+ 2GB can get >>> between 5 MiBytes/s and 6 MiBytes/s, from >>> what I have observed. >> Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow >> in comparsion to RPI2B (or RPI3). >> >> root@rpi2b:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec) >> >> root@pine64plus:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec) >> >> Both devices running r327391 with without any debugging, INVARIANTS, >> etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB >> >> Mark, can you perform the write test with your eMMC to MicroSD >> Adapter? >> >> -asc > > It used to be that clang used files in /tmp to pass results between > stages of the compile whereas gcc used pipes. I'm not sure if that's > still true, but if it is, then using tmpfs for /tmp should improve > compile times and remove much of the sdcard performance impact. Could well be. The Pine64+ 2GB does use the swap space some in building cmake and/or devel/llvm50 --without such extra RAM use involved. (I no longer have the figures around.) There might be more swapping if some form of tmpfs is used. When I instead boot the Pine64+ 2GB with a USB SSD stick on a powered hub, the I/O is not as constrained. (But it is more equipment to deal with.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 5 02:23:39 2018 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 482B6EA79F7 for ; Fri, 5 Jan 2018 02:23:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-148.reflexion.net [208.70.210.148]) (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 E8DEE6E602 for ; Fri, 5 Jan 2018 02:23:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25288 invoked from network); 5 Jan 2018 02:23:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 02:23:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 21:23:31 -0500 (EST) Received: (qmail 27094 invoked from network); 5 Jan 2018 02:23:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 02:23:31 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E0E5CEC9379; Thu, 4 Jan 2018 18:23:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 From: Mark Millard In-Reply-To: <4b428a608dd.290862fc@mail.schwarzes.net> Date: Thu, 4 Jan 2018 18:23:30 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> <4b428a608dd.290862fc@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 02:23:39 -0000 On 2018-Jan-4, at 3:40 PM, Andreas Schwarz wrote: > On 04.01.18, Mark Millard wrote: > >> eMCC performance notes: >> The rpi3 can get between 10 MiByte/s and >> 12 MiByte/s, while the Pine64+ 2GB can get >> between 5 MiBytes/s and 6 MiBytes/s, from >> what I have observed. > > Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow > in comparsion to RPI2B (or RPI3). > > root@rpi2b:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec) > > root@pine64plus:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec) > > Both devices running r327391 with without any debugging, INVARIANTS, > etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB > > Mark, can you perform the write test with your eMMC to MicroSD > Adapter? [I probably should have noted that I mount with -o noatime for all these contexts. And all 3 have heat sinks and fans. The RPi2B V1.1 and Pine64+ 2GB were running -r327364 at the time (and still are).] The RPi2 context is odd because the usdcard slot is partially broken: Its mechanism for hold in cards has failed but its mechanism for ejecting them still works. This is one reason why there is a USB SSD stick on a powered USB hub involved: USB is where the kernel, the dtb file that the kernel reads, the root file system, and the swap space are all from. I hold in the usdcard until the kernel starts to load then I let go. As the poudriere bulk activity was based (RPi2B V1.1: USB SSD stick). . . RPi2B V1.1 (cortex-a7) using the USB SSD stick: # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 48.251071 secs (22253223 bytes/sec) (Note: The powered hub and USB SSD stick are all USB 3.0 capable and for a good USB 3.0 context can sustain well over 10 times the above figure.) RPi3: (cortex-a53) using a 64 GB eMMC via a usdcard adapter: # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 72.442738 secs (14821939 bytes/sec) Pine64+ 2GB: (cortex-a53) using a 128 GB eMMC via a usdcard adapter: # dd if=/dev/zero of=/var/zero.img bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 189.560701 secs (5664369 bytes/sec) The RPi2B V1.1 and RPi3 have similar amounts of RAM, and so likely similar amounts of swapping activity (compared to the Pine64+ 2GB), but the slower I/O rate context (RPi3) took less time for the build than the faster I/O rate context (RPi2B V1.1). The Pine64+ 2GB did some swapping, but not much compared the the RPi2/3 (far more RAM). With this difference (and hardware differences), the slowest I/O rate of the 3 contexts took the least build time. RPi2B V1.1 eMMC via an adapter: no figures, I'm afraid. . . Each of my attempts to hold an eMMC with an adapter in the RPi2 usdcard slot for a test have resulted in a panic. I'm afraid I'll not be getting an RPi2B V1.1 timing for an eMMC via an usdcard slot adapter. eMMC adapter note: Some cases for single board computers interfere with using an eMMC via an adapter. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 5 02:34:50 2018 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 7D290EA85B5 for ; Fri, 5 Jan 2018 02:34:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (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 128696ED50 for ; Fri, 5 Jan 2018 02:34:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16617 invoked from network); 5 Jan 2018 02:34:48 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 02:34:48 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 21:34:48 -0500 (EST) Received: (qmail 10442 invoked from network); 5 Jan 2018 02:34:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 02:34:47 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1BC9DEC9379 for ; Thu, 4 Jan 2018 18:34:47 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Message-Id: Date: Thu, 4 Jan 2018 18:34:46 -0800 To: Freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 02:34:50 -0000 As of today I have access to a Rock64-4GB (Rock64_V2.0 board). I've seen at least one reference to Rock64 being used to test something checked in. So, my hope is that at some point the Rock64 will be supported in a publicly documented manor for how to set it up for booting FreeBSD head. Then I will set it up for such. === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 5 03:50:10 2018 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 E35EAEAD6AA for ; Fri, 5 Jan 2018 03:50:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-152.reflexion.net [208.70.210.152]) (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 A864B72C83 for ; Fri, 5 Jan 2018 03:50:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4663 invoked from network); 5 Jan 2018 03:50:02 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 03:50:02 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 04 Jan 2018 22:50:02 -0500 (EST) Received: (qmail 26018 invoked from network); 5 Jan 2018 03:50:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 03:50:02 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 012B6EC7C3B; Thu, 4 Jan 2018 19:50:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1 From: Mark Millard In-Reply-To: Date: Thu, 4 Jan 2018 19:50:01 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <2CCA0BCD-BB15-4817-BFDA-E6FC5580588E@dsl-only.net> References: <65D7B16B-E3D7-40F2-BE60-0EE5E5B26B31@dsl-only.net> <4b428a608dd.290862fc@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 03:50:11 -0000 [I should have mentioned: non-debug kernels were in use.] On 2018-Jan-4, at 6:23 PM, Mark Millard wrote: > On 2018-Jan-4, at 3:40 PM, Andreas Schwarz = wrote: >=20 >> On 04.01.18, Mark Millard wrote: >>=20 >>> eMCC performance notes: >>> The rpi3 can get between 10 MiByte/s and >>> 12 MiByte/s, while the Pine64+ 2GB can get >>> between 5 MiBytes/s and 6 MiBytes/s, from >>> what I have observed. >>=20 >> Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow=20 >> in comparsion to RPI2B (or RPI3). >>=20 >> root@rpi2b:~ # dd if=3D/dev/zero of=3D/var/zero.img bs=3D1m = count=3D1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec) >>=20 >> root@pine64plus:~ # dd if=3D/dev/zero of=3D/var/zero.img bs=3D1m = count=3D1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec) >>=20 >> Both devices running r327391 with without any debugging, INVARIANTS,=20= >> etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB >>=20 >> Mark, can you perform the write test with your eMMC to MicroSD=20 >> Adapter? >=20 > [I probably should have noted that I mount > with -o noatime for all these contexts. And > all 3 have heat sinks and fans. The RPi2B > V1.1 and Pine64+ 2GB were running -r327364 > at the time (and still are).] Also: non-debug kernels were in use for all 3 examples. > The RPi2 context is odd because the usdcard slot > is partially broken: Its mechanism for hold in > cards has failed but its mechanism for ejecting > them still works. This is one reason why there is > a USB SSD stick on a powered USB hub involved: > USB is where the kernel, the dtb file that the > kernel reads, the root file system, and the > swap space are all from. I hold in the usdcard > until the kernel starts to load then I let go. >=20 > As the poudriere bulk activity was based > (RPi2B V1.1: USB SSD stick). . . >=20 > RPi2B V1.1 (cortex-a7) using the USB SSD stick: > # dd if=3D/dev/zero of=3D/var/zero.img bs=3D1m count=3D1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 48.251071 secs (22253223 bytes/sec) >=20 > (Note: The powered hub and USB SSD stick are all USB 3.0 > capable and for a good USB 3.0 context can sustain well > over 10 times the above figure.) >=20 > RPi3: (cortex-a53) using a 64 GB eMMC via a usdcard adapter: > # dd if=3D/dev/zero of=3D/var/zero.img bs=3D1m count=3D1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 72.442738 secs (14821939 bytes/sec) >=20 > Pine64+ 2GB: (cortex-a53) using a 128 GB eMMC via a usdcard adapter: > # dd if=3D/dev/zero of=3D/var/zero.img bs=3D1m count=3D1024 > 1024+0 records in > 1024+0 records out > 1073741824 bytes transferred in 189.560701 secs (5664369 bytes/sec) >=20 > The RPi2B V1.1 and RPi3 have similar amounts of RAM, > and so likely similar amounts of swapping activity > (compared to the Pine64+ 2GB), but the slower I/O > rate context (RPi3) took less time for the build > than the faster I/O rate context (RPi2B V1.1). >=20 > The Pine64+ 2GB did some swapping, but not much compared > the the RPi2/3 (far more RAM). With this difference (and > hardware differences), the slowest I/O rate of the 3 > contexts took the least build time. Non-debug kernels were in use for all 3 examples. > RPi2B V1.1 eMMC via an adapter: no figures, I'm afraid. . . >=20 > Each of my attempts to hold an eMMC with an adapter > in the RPi2 usdcard slot for a test have resulted in > a panic. I'm afraid I'll not be getting an RPi2B V1.1 > timing for an eMMC via an usdcard slot adapter. >=20 >=20 > eMMC adapter note: >=20 > Some cases for single board computers interfere > with using an eMMC via an adapter. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 5 13:31:56 2018 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 E9C80EA9502 for ; Fri, 5 Jan 2018 13:31:56 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE91B68E7C for ; Fri, 5 Jan 2018 13:31:56 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 9E030D43; Fri, 5 Jan 2018 07:31:55 -0600 (CST) Date: Fri, 5 Jan 2018 07:31:54 -0600 From: Mark Linimon To: Mark Millard Cc: Freebsd-arm , Mark Linimon Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Message-ID: <20180105133154.GC31064@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 13:31:57 -0000 I bought one on spec several months ago hoping that by the time it shipped it would be supported :-) But IIUC the code "is being worked on" and not yet available for testing. mcl From owner-freebsd-arm@freebsd.org Fri Jan 5 14:27:51 2018 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 10D4DEAC329 for ; Fri, 5 Jan 2018 14:27:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-156.reflexion.net [208.70.210.156]) (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 9737E6B322 for ; Fri, 5 Jan 2018 14:27:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15666 invoked from network); 5 Jan 2018 14:27:43 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jan 2018 14:27:43 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 05 Jan 2018 09:27:43 -0500 (EST) Received: (qmail 2638 invoked from network); 5 Jan 2018 14:27:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jan 2018 14:27:42 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2FD9BEC8675; Fri, 5 Jan 2018 06:27:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Mark Millard In-Reply-To: <20180105133154.GC31064@lonesome.com> Date: Fri, 5 Jan 2018 06:27:41 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> References: <20180105133154.GC31064@lonesome.com> To: Mark Linimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 14:27:51 -0000 On 2018-Jan-5, at 5:31 AM, Mark Linimon wrote: > I bought one on spec several months ago hoping that by the time it > shipped it would be supported :-) But IIUC the code "is being worked > on" and not yet available for testing. I've used linux to prove that the one I have access to is working, including booting from eMMC and from the usdcard. A nasty for my context is that the early boot baudrate for the console is apparently 1.5Mbit/s and what I've been doing historically for console access does not support that. (This is not a linux-ism: it is true before linux is involved as far as I can tell.) === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 5 14:45:44 2018 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 E71C3EAD11C for ; Fri, 5 Jan 2018 14:45:44 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE6996BDA7 for ; Fri, 5 Jan 2018 14:45:44 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id C9A7ED23; Fri, 5 Jan 2018 08:45:42 -0600 (CST) Date: Fri, 5 Jan 2018 08:45:41 -0600 From: Mark Linimon To: Mark Millard Cc: Freebsd-arm Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Message-ID: <20180105144541.GA32430@lonesome.com> References: <20180105133154.GC31064@lonesome.com> <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 14:45:45 -0000 On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: > the early boot baudrate for the console is apparently 1.5Mbit/s I've had to use minicom. That's the only thing that I'm sure supports it. mcl From owner-freebsd-arm@freebsd.org Sat Jan 6 13:23:34 2018 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 3D6E0EB92EE for ; Sat, 6 Jan 2018 13:23:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 25BF86D8FA for ; Sat, 6 Jan 2018 13:23:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 252A1EB92E9; Sat, 6 Jan 2018 13:23:34 +0000 (UTC) Delivered-To: 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 24842EB92E8; Sat, 6 Jan 2018 13:23:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A046D8F9; Sat, 6 Jan 2018 13:23:33 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f] (p200300CD6BEB2600A47065D3E324200F.dip0.t-ipconnect.de [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 45999721E282E; Sat, 6 Jan 2018 14:23:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf From: Michael Tuexen In-Reply-To: <201801042237.w04MbFVR015965@repo.freebsd.org> Date: Sat, 6 Jan 2018 14:23:25 +0100 Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6F912304-B760-4DA2-AB74-C2C934026FC1@freebsd.org> References: <201801042237.w04MbFVR015965@repo.freebsd.org> To: Kyle Evans X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 13:23:34 -0000 > On 4. Jan 2018, at 23:37, Kyle Evans wrote: >=20 > Author: kevans > Date: Thu Jan 4 22:37:15 2018 > New Revision: 327563 > URL: https://svnweb.freebsd.org/changeset/base/327563 >=20 > Log: > if_awg: Use syscon prop if it exists >=20 > The emac bindings that are landing in Linux 4.15 specify a syscon = property > on the emac node that point to /soc/syscon. Use this property if it's > specified, but maintain backwards compatibility with the old method. >=20 > The older method is still used for boards that we get .dtb from = u-boot, such > as pine64, that did not yet have stable emac bindings. >=20 > Tested on: Banana Pi-M3 (a83t) > Tested on: Pine64 (a64) > Reviewed by: manu > Differential Revision: https://reviews.freebsd.org/D13296 This breaks booting on a RPi3. Please note that it is not only = panic'ing, but there are multiple errors before that. >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: UFS Probing 3 block devices.....* done UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0x39ab8008 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7f3b28 data=3D0xaac80+0x3a106d = syms=3D[0x8+0x10e870+0x8+0x101345] /boot/entropy size=3D0x1000 /boot/kernel/geom_label.ko text=3D0x2a80 text=3D0x2710 = data=3D0x10118+0xfeec syms=3D[0x8+0x1548+0x8+0xef2] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x8004000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT #21 r327563M: Sat Jan 6 14:16:20 CET 2018 = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on LLVM = 5.0.1) VT: init without driver. sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! module_register: cannot register g_label from kernel; already loaded = from geom_label.ko Module g_label failed to register: 17 Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error 12 random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 syscon_generic0: mem 0x40000000-0x400000ff on simplebus0 psci0: on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 local_intc0: could not allocate memory resource device_attach: local_intc0 attach returned 6 intc0: mem 0x7e00b200-0x7e00b3ff irq 16 = on simplebus0 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 local_intc0: could not allocate memory resource device_attach: local_intc0 attach returned 6 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 local_intc0: could not allocate memory resource device_attach: local_intc0 attach returned 6 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 local_intc0: could not allocate memory resource device_attach: local_intc0 attach returned 6 generic_timer0: irq 47,48,49,50 on simplebus0 generic_timer0: could not allocate resources device_attach: generic_timer0 attach returned 6 bcm_dma0: mem 0x7e007000-0x7e007eff irq = 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 on simplebus0 bcmwd0: mem 0x7e100000-0x7e100027 on simplebus0 bcmrng0: mem 0x7e104000-0x7e10400f on simplebus0 device_attach: bcmrng0 attach returned 6 mbox0: mem 0x7e00b880-0x7e00b8bf irq 17 on = simplebus0 gpio0: mem 0x7e200000-0x7e2000b3 irq = 18,19 on simplebus0 gpiobus0: on gpio0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e201fff irq 20 on = simplebus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e204fff irq 21 on = simplebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 iichb0: mem 0x7e804000-0x7e804fff irq 32 = on simplebus0 bcm283x_dwcotg0: mem = 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 38,39 on simplebus0 usbus0 on bcm283x_dwcotg0 sdhci_bcm0: mem 0x7e300000-0x7e3000ff = irq 42 on simplebus0 mmc0: on sdhci_bcm0 fb0: on simplebus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3db33000, screen_size 818688 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 local_intc0: could not allocate memory resource device_attach: local_intc0 attach returned 6 pmu0: irq 46 on simplebus0 pmu0: could not allocate resources device_attach: pmu0 attach returned 6 generic_timer0: irq 47,48,49,50 on simplebus0 generic_timer0: could not allocate resources device_attach: generic_timer0 attach returned 6 gpioled0: on ofwbus0 gpioled0: failed to map pin gpioled0: failed to map pin cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: panic: No usable event timer found! cpuid =3D 0 time =3D 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000062b308 lr =3D 0xffff000000086b78 sp =3D 0xffff0000000107c0 fp =3D 0xffff0000000109d0 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff000000086b78 lr =3D 0xffff0000003258a4 sp =3D 0xffff0000000109e0 fp =3D 0xffff000000010a60 vpanic() at panic+0x44 pc =3D 0xffff0000003258a4 lr =3D 0xffff00000032571c sp =3D 0xffff000000010a70 fp =3D 0xffff000000010af0 panic() at cpu_initclocks_bsp+0x410 pc =3D 0xffff00000032571c lr =3D 0xffff00000066a6ec sp =3D 0xffff000000010b00 fp =3D 0xffff000000010b50 cpu_initclocks_bsp() at initclocks+0x28 pc =3D 0xffff00000066a6ec lr =3D 0xffff0000002c4b9c sp =3D 0xffff000000010b60 fp =3D 0xffff000000010b60 initclocks() at mi_startup+0xc8 pc =3D 0xffff0000002c4b9c lr =3D 0xffff0000002c148c sp =3D 0xffff000000010b70 fp =3D 0xffff000000010bb0 mi_startup() at virtdone+0x54 pc =3D 0xffff0000002c148c lr =3D 0xffff000000001084 sp =3D 0xffff000000010bc0 fp =3D 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at 0 db>=20 Revision 327562 boots fine: Using DTB provided by EFI at 0x8004000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 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 12.0-CURRENT #19 r327562M: Sat Jan 6 14:00:01 CET 2018 = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on LLVM = 5.0.1) VT: init without driver. sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! module_register: cannot register g_label from kernel; already loaded = from geom_label.ko Module g_label failed to register: 17 Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error 12 random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 ofw_clkbus0: on ofwbus0 clk_fixed0: on ofw_clkbus0 clk_fixed1: on ofw_clkbus0 regfix0: on ofwbus0 regfix1: on ofwbus0 psci0: on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on = simplebus0 intc0: mem 0x7e00b200-0x7e00b3ff irq 16 = on simplebus0 generic_timer0: irq 47,48,49,50 on simplebus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 bcm_dma0: mem 0x7e007000-0x7e007eff irq = 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 on simplebus0 bcmwd0: mem 0x7e100000-0x7e100027 on simplebus0 bcmrng0: mem 0x7e104000-0x7e10400f on simplebus0 device_attach: bcmrng0 attach returned 6 mbox0: mem 0x7e00b880-0x7e00b8bf irq 17 on = simplebus0 gpio0: mem 0x7e200000-0x7e2000b3 irq = 18,19 on simplebus0 gpiobus0: on gpio0 gpioc0: on gpio0 uart0: mem 0x7e201000-0x7e201fff irq 20 on = simplebus0 uart0: console (115200,n,8,1) spi0: mem 0x7e204000-0x7e204fff irq 21 on = simplebus0 spibus0: on spi0 spibus0: at cs 0 mode 0 spibus0: at cs 1 mode 0 iichb0: mem 0x7e804000-0x7e804fff irq 32 = on simplebus0 bcm283x_dwcotg0: mem = 0x7e980000-0x7e98ffff,0x7e006000-0x7e006fff irq 38,39 on simplebus0 usbus0 on bcm283x_dwcotg0 sdhci_bcm0: mem 0x7e300000-0x7e3000ff = irq 42 on simplebus0 mmc0: on sdhci_bcm0 fb0: on simplebus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3db33000, screen_size 818688 pmu0: irq 46 on simplebus0 gpioled0: on ofwbus0 gpioled0: failed to map pin gpioled0: failed to map pin cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 cryptosoft0: Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to = accept, logging disabled iicbus0: on iichb0 iic0: on iicbus0 The GEOM class LABEL is already loaded. usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 mmcsd0: 64GB at mmc0 = 41.6MHz/4bit/65535-block bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF Release APs CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Memory Model Features 2 =3D <32b CCIDX,48b VA> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... Warning: no time-of-day clock registered, system time will not be set = accurately uhub0: 1 port with 1 removable, self powered sysctl: net.inet.sctp.udp_tunneling_port=3D9899 at line 11: Can't assign = requested address Setting hostuuid: 30303030-3030-3030-3138-303365396335. Setting hostid: 0xede1b97d. No suitable dump device was found. Starting file system checks: /dev/mmcsd0s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s2a: clean, 12823920 free (74496 frags, 1593678 blocks, 0.5% = fragmentation) ugen0.2: at usbus0 uhub1 on uhub0 uhub1: = on usbus0 uhub1: MTT enabled Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/perl5/5.24/mach/CORE uhub1: 5 ports with 4 removable, self powered Setting hostname: bsd10.fh-muenster.de. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 smscphy0: PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:03:e9:c5 Starting Network: lo0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 Starting devd. ue0: link state changed to UP smsc0: chip 0xec00, rev. 0002 ue0: link state changed to DOWN ue0: link state changed to UP Starting Network: ue0. ue0: flags=3D8843 metric 0 mtu = 1500 options=3D80009 ether b8:27:eb:03:e9:c5 inet 212.201.121.100 netmask 0xffffffe0 broadcast = 212.201.121.127=20 inet6 fe80::ba27:ebff:fe03:e9c5%ue0 prefixlen 64 scopeid 0x2=20 inet6 2a02:c6a0:4015:10::100 prefixlen 64=20 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D21 add net default: gateway 212.201.121.97 add host 127.0.0.1: gateway lo0 fib 0: route already in table add net default: gateway 212.201.121.97 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table 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 add net default: gateway fe80::a236:9fff:fe80:e9de%ue0 Creating and/or trimming log files. Starting syslogd. Setting date via ntp. 6 Jan 14:20:41 ntpdate[526]: step time server 204.9.54.119 offset = 84.882792 sec Clearing /tmp (X related). Updating motd:. Mounting late filesystems:. Starting thttpd. Configuring vt: blanktime. Performing sanity check on sshd configuration. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Sat Jan 6 14:20:42 CET 2018 FreeBSD/arm64 (bsd10.fh-muenster.de) (ttyu0) login:=20 The kernel config being used is: include GENERIC-NODEBUG ident TCP =20 makeoptions WITH_EXTRA_TCP_STACKS=3D1 options TCP_RFC7413 options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=3D5 options IPFIREWALL_DEFAULT_TO_ACCEPT nooptions COMPAT_FREEBSD32 Best regards Michael From owner-freebsd-arm@freebsd.org Sat Jan 6 14:24:58 2018 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 19BABEBBD8F for ; Sat, 6 Jan 2018 14:24:58 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E91C571469 for ; Sat, 6 Jan 2018 14:24:57 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E56E6EBBD8B; Sat, 6 Jan 2018 14:24:57 +0000 (UTC) Delivered-To: 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 E4CC7EBBD8A; Sat, 6 Jan 2018 14:24:57 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-io0-f196.google.com (mail-io0-f196.google.com [209.85.223.196]) (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 B4ED271468; Sat, 6 Jan 2018 14:24:57 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-io0-f196.google.com with SMTP id 87so8627590ior.5; Sat, 06 Jan 2018 06:24:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aY0SbdtumCWmBjPhvW055+jjBEQpBHEM2rj+tKkEESs=; b=KQQejPG/QHmtAjh6HHdYqcE/wo3DGQrs+8TMGO7fhKKvMUbZgoqpeKXDS0SFUGNv5/ ltaO0mmvt+ZX7hHZTapxy6jG5nyWTD6yjPaxf9j+laygxttBkg8ECTZzMxtHMDguwMVL Qh+zBBjF7tN9iJ6KGYDj3d7AxHXUyM7yth4VCBTB7gxLAFFZw/r++D/8SMVtfAQiXiGy J1KSfu6rLjcpVA7FiNSNgAxRrpCbWQ8UpzwklhI6nSI4O9SreNbxlc3lQWRiulkIRYNp QIw8iIRwi/az6FVhTmiCEUfH52fDT7OMkOyOrWXWD3sMKfJHa7vAFP07HUpnO166qmJV WAFw== X-Gm-Message-State: AKGB3mK1A/Y4gUgjtkgJB3hgLAc5L8q5rGIt3WDLmRGV6Irb75lkb+NJ UhXEyxtWNZEaVIxDnqTi6bt5VaLd X-Google-Smtp-Source: ACJfBovEkzfp9GOmDAcm1miOrKEyTmx98vVj+dAeng0sGIlNEnl0vW5JtOayuRjqj6DiU715FaZHHg== X-Received: by 10.107.24.195 with SMTP id 186mr3302151ioy.185.1515248691315; Sat, 06 Jan 2018 06:24:51 -0800 (PST) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id y66sm4809082iod.48.2018.01.06.06.24.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2018 06:24:50 -0800 (PST) Received: by mail-it0-f50.google.com with SMTP id p139so4597008itb.1; Sat, 06 Jan 2018 06:24:50 -0800 (PST) X-Received: by 10.36.51.202 with SMTP id k193mr6054046itk.130.1515248690343; Sat, 06 Jan 2018 06:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.149.147 with HTTP; Sat, 6 Jan 2018 06:24:29 -0800 (PST) In-Reply-To: <6F912304-B760-4DA2-AB74-C2C934026FC1@freebsd.org> References: <201801042237.w04MbFVR015965@repo.freebsd.org> <6F912304-B760-4DA2-AB74-C2C934026FC1@freebsd.org> From: Kyle Evans Date: Sat, 6 Jan 2018 08:24:29 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf To: Michael Tuexen Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 14:24:58 -0000 On Sat, Jan 6, 2018 at 7:23 AM, Michael Tuexen wrote: >> On 4. Jan 2018, at 23:37, Kyle Evans wrote: >> >> Author: kevans >> Date: Thu Jan 4 22:37:15 2018 >> New Revision: 327563 >> URL: https://svnweb.freebsd.org/changeset/base/327563 >> >> Log: >> if_awg: Use syscon prop if it exists >> >> The emac bindings that are landing in Linux 4.15 specify a syscon property >> on the emac node that point to /soc/syscon. Use this property if it's >> specified, but maintain backwards compatibility with the old method. >> >> The older method is still used for boards that we get .dtb from u-boot, such >> as pine64, that did not yet have stable emac bindings. >> >> Tested on: Banana Pi-M3 (a83t) >> Tested on: Pine64 (a64) >> Reviewed by: manu >> Differential Revision: https://reviews.freebsd.org/D13296 > This breaks booting on a RPi3. Please note that it is not only panic'ing, > but there are multiple errors before that. Ugh, sorry about that. >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi > > Initializing modules: UFS > Probing 3 block devices.....* done > UFS found 1 partition > Consoles: EFI console > Command line arguments: loader.efi > Image base: 0x39ab8008 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) > > FreeBSD/arm64 EFI loader, Revision 1.1 > (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=0x7f3b28 data=0xaac80+0x3a106d syms=[0x8+0x10e870+0x8+0x101345] > /boot/entropy size=0x1000 > /boot/kernel/geom_label.ko text=0x2a80 text=0x2710 data=0x10118+0xfeec syms=[0x8+0x1548+0x8+0xef2] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by EFI at 0x8004000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2018 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 12.0-CURRENT #21 r327563M: Sat Jan 6 14:16:20 CET 2018 > tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP arm64 > FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on LLVM 5.0.1) > VT: init without driver. > sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! > module_register: cannot register g_label from kernel; already loaded from geom_label.ko > Module g_label failed to register: 17 > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error 12 > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: on ofwbus0 > ofw_clkbus0: on ofwbus0 > clk_fixed0: on ofw_clkbus0 > clk_fixed1: on ofw_clkbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > syscon_generic0: mem 0x40000000-0x400000ff on simplebus0 > psci0: on ofwbus0 > local_intc0: mem 0x40000000-0x400000ff on simplebus0 > local_intc0: could not allocate memory resource > device_attach: local_intc0 attach returned 6 Apologies for the breakage; this should be alleviated by r327621. There will still be some errors (syscon_generic cannot allocate memory resource), but that should be completely innocent in this case and will give me time to track down why syscon shares register space with local intc here. From owner-freebsd-arm@freebsd.org Sat Jan 6 14:36:47 2018 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 24220EBC534 for ; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA0B71A9F for ; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0A04AEBC531; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) Delivered-To: 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 09663EBC530; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7B3E71A9E; Sat, 6 Jan 2018 14:36:45 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f] (p200300CD6BEB2600A47065D3E324200F.dip0.t-ipconnect.de [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9A05771E3F906; Sat, 6 Jan 2018 15:36:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf From: Michael Tuexen In-Reply-To: Date: Sat, 6 Jan 2018 15:36:25 +0100 Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1431AAD8-E4CB-437B-83D5-7691DC3FDD51@freebsd.org> References: <201801042237.w04MbFVR015965@repo.freebsd.org> <6F912304-B760-4DA2-AB74-C2C934026FC1@freebsd.org> To: Kyle Evans X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 14:36:47 -0000 > On 6. Jan 2018, at 15:24, Kyle Evans wrote: >=20 > On Sat, Jan 6, 2018 at 7:23 AM, Michael Tuexen = wrote: >>> On 4. Jan 2018, at 23:37, Kyle Evans wrote: >>>=20 >>> Author: kevans >>> Date: Thu Jan 4 22:37:15 2018 >>> New Revision: 327563 >>> URL: https://svnweb.freebsd.org/changeset/base/327563 >>>=20 >>> Log: >>> if_awg: Use syscon prop if it exists >>>=20 >>> The emac bindings that are landing in Linux 4.15 specify a syscon = property >>> on the emac node that point to /soc/syscon. Use this property if = it's >>> specified, but maintain backwards compatibility with the old method. >>>=20 >>> The older method is still used for boards that we get .dtb from = u-boot, such >>> as pine64, that did not yet have stable emac bindings. >>>=20 >>> Tested on: Banana Pi-M3 (a83t) >>> Tested on: Pine64 (a64) >>> Reviewed by: manu >>> Differential Revision: https://reviews.freebsd.org/D13296 >> This breaks booting on a RPi3. Please note that it is not only = panic'ing, >> but there are multiple errors before that. >=20 > Ugh, sorry about that. No problem... >=20 >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >>=20 >> Initializing modules: UFS >> Probing 3 block devices.....* done >> UFS found 1 partition >> Consoles: EFI console >> Command line arguments: loader.efi >> Image base: 0x39ab8008 >> EFI version: 2.05 >> EFI Firmware: Das U-boot (rev 0.00) >>=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >> (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) >> EFI boot environment >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x7f3b28 data=3D0xaac80+0x3a106d = syms=3D[0x8+0x10e870+0x8+0x101345] >> /boot/entropy size=3D0x1000 >> /boot/kernel/geom_label.ko text=3D0x2a80 text=3D0x2710 = data=3D0x10118+0xfeec syms=3D[0x8+0x1548+0x8+0xef2] >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0x8004000. >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2018 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 12.0-CURRENT #21 r327563M: Sat Jan 6 14:16:20 CET 2018 >> = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 >> FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on = LLVM 5.0.1) >> VT: init without driver. >> sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! >> module_register: cannot register g_label from kernel; already loaded = from geom_label.ko >> Module g_label failed to register: 17 >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: unblocking device. >> module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error = 12 >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on ofwbus0 >> ofw_clkbus0: on ofwbus0 >> clk_fixed0: on ofw_clkbus0 >> clk_fixed1: on ofw_clkbus0 >> regfix0: on ofwbus0 >> regfix1: on ofwbus0 >> syscon_generic0: mem 0x40000000-0x400000ff on simplebus0 >> psci0: on ofwbus0 >> local_intc0: mem 0x40000000-0x400000ff = on simplebus0 >> local_intc0: could not allocate memory resource >> device_attach: local_intc0 attach returned 6 >=20 > Apologies for the breakage; this should be alleviated by r327621. > There will still be some errors (syscon_generic cannot allocate memory > resource), but that should be completely innocent in this case and > will give me time to track down why syscon shares register space with > local intc here. I can confirm that r327621 boots again on RPi3 and the system is usable. Thanks for the quick fix/workaround. Best regards Michael From owner-freebsd-arm@freebsd.org Sat Jan 6 16:43:46 2018 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 2846BEC14D4; Sat, 6 Jan 2018 16:43:46 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7226176201; Sat, 6 Jan 2018 16:43:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 92966354; Sat, 6 Jan 2018 17:43:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=66H0oy BwzW0WRhL8BS9khqg6W0A=; b=laDfy/6jGA4RgPSpt6Kne1xTVrO5IF5zXMN2Cp iIrnEftywLQgTFbuwd1IQDJhPz8w1DNVaNSMTK/q0A48Sqi5BajYgRO92OgDZCMF bYo+ca+XpAzu0l0Doro5dkTvBspRkqgbfPLR6+Jmwz7XeAwjr1z8MMSv8h/yAH8i O+t+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= kAKLxFr7KfOJhbti6KJ9Vum6qtkHfsTWkJLN5VLOhUEixJWSALeuFEyTP99jrqUk FALbFnkQRugROYw9hoGmckIsyp52z4rV7SNY36ksP/We2tCMngBIwWJLTuPv0y2I +W9g/7iCGdiAAB6JHFgQnGW0amxik9HOvUgSpT635mM= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 5873a4a4; Sat, 6 Jan 2018 17:43:36 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 06 Jan 2018 17:43:36 +0100 From: Emmanuel Vadot To: Mark Linimon Cc: Mark Millard , Freebsd-arm , owner-freebsd-arm@freebsd.org Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Organization: Bidouilliste In-Reply-To: <20180105144541.GA32430@lonesome.com> References: <20180105133154.GC31064@lonesome.com> <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> <20180105144541.GA32430@lonesome.com> Message-ID: <6168e37ebf0210ddc49947030db83e9f@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:43:46 -0000 On 2018-01-05 15:45, Mark Linimon wrote: > On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: >> the early boot baudrate for the console is apparently 1.5Mbit/s > > I've had to use minicom. That's the only thing that I'm sure supports > it. > > mcl Works fine with tip(1) here using an FDTI usb<->serial, using a PL2303XA doesn't work (but should based on the datasheet), and my CP2108 should work but I haven't tested yet. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Jan 6 16:45:17 2018 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 AF787EC15B9; Sat, 6 Jan 2018 16:45:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 056497629D; Sat, 6 Jan 2018 16:45:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id cda76ddb; Sat, 6 Jan 2018 17:45:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; s=mail; bh=gMCIfY c94f/5WJtiOpOTx96NnDg=; b=UXbOCf1DOWrgICg2sE+H5ZJic3IdDCu3RanyWB CrqidTwRrnaPdYWDEBiuVx5/xG836fhnEoaROrdrXpYmgGmf99v2NjErld0fgKkq euZs2GqS7NSTpf/eSclxs0a3bG1ntzdVp/nPnO5RzY0kKO/D5pYp0A8Rg89hH8B/ 8D1Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h= mime-version:content-type:content-transfer-encoding:date:from:to :cc:subject:in-reply-to:references:message-id; q=dns; s=mail; b= Z7zoGVJovVkMAY4e5KhnizIaW1uONcgzafDmErin9jNabfBKkX/Yx2clbdAbep91 RnxIwr4MiJgCXbT60YsOpongO5B/SSdyEZQD+mzo+XrZ3I3av4k2POn5BMriRvEM rnk0D4L3bN0AhWltQLFPRo8tdw+BZtu9KAvBDRQrXBs= Received: from webmail.megadrive.org (www1.blih.net [212.83.177.180]) by mail.blih.net (OpenSMTPD) with ESMTP id 5878a9c9; Sat, 6 Jan 2018 17:45:14 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 06 Jan 2018 17:45:14 +0100 From: Emmanuel Vadot To: Mark Linimon Cc: Freebsd-arm , owner-freebsd-arm@freebsd.org Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Organization: Bidouilliste In-Reply-To: <6168e37ebf0210ddc49947030db83e9f@megadrive.org> References: <20180105133154.GC31064@lonesome.com> <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> <20180105144541.GA32430@lonesome.com> <6168e37ebf0210ddc49947030db83e9f@megadrive.org> Message-ID: <41bcf0afe2a94d80909837b43d25022c@megadrive.org> X-Sender: manu@bidouilliste.com User-Agent: Roundcube Webmail/1.1.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 16:45:17 -0000 On 2018-01-06 17:43, Emmanuel Vadot wrote: > On 2018-01-05 15:45, Mark Linimon wrote: >> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: >>> the early boot baudrate for the console is apparently 1.5Mbit/s >> >> I've had to use minicom. That's the only thing that I'm sure supports >> it. >> >> mcl > > Works fine with tip(1) here using an FDTI usb<->serial, using a > PL2303XA doesn't work (but should based on the datasheet), and my > CP2108 should work but I haven't tested yet. Also my PL2303XA adapter works on linux using minicom but only for RX, that might be a driver issue. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Jan 6 21:23:37 2018 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 D5FADDF0AE8 for ; Sat, 6 Jan 2018 21:23:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-137.reflexion.net [208.70.210.137]) (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 805498066C for ; Sat, 6 Jan 2018 21:23:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23946 invoked from network); 6 Jan 2018 21:23:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2018 21:23:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 06 Jan 2018 16:23:30 -0500 (EST) Received: (qmail 18383 invoked from network); 6 Jan 2018 21:23:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2018 21:23:30 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D6CB4EC94BC; Sat, 6 Jan 2018 13:23:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Mark Millard In-Reply-To: <41bcf0afe2a94d80909837b43d25022c@megadrive.org> Date: Sat, 6 Jan 2018 13:23:29 -0800 Cc: Freebsd-arm , owner-freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9FDFF16A-02D4-4EC3-BB66-AF9C0FA3B2EE@dsl-only.net> References: <20180105133154.GC31064@lonesome.com> <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> <20180105144541.GA32430@lonesome.com> <6168e37ebf0210ddc49947030db83e9f@megadrive.org> <41bcf0afe2a94d80909837b43d25022c@megadrive.org> To: Emmanuel Vadot , Mark Linimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 21:23:37 -0000 On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot = wrote: > On 2018-01-06 17:43, Emmanuel Vadot wrote: >> On 2018-01-05 15:45, Mark Linimon wrote: >>> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: >>>> the early boot baudrate for the console is apparently 1.5Mbit/s >>> I've had to use minicom. That's the only thing that I'm sure = supports it. >>> mcl >> Works fine with tip(1) here using an FDTI usb<->serial, using a >> PL2303XA doesn't work (but should based on the datasheet), and my >> CP2108 should work but I haven't tested yet. >=20 > Also my PL2303XA adapter works on linux using minicom but only for RX, = that might be a driver issue. I've been using Serial on an old MacOS X laptop. I've done more experiments. Here is what I've observed. . . For a CH340G, Serial did not allow 1500000 (built-in driver for USB ID 1a86:7523:0254) but Serial is being updated to allow it. (I have a preliminary release now, so I have 1500000 support now.) However, there was extensive dropped text from sustained output in my limited testing of this combination. [The CH340G is from the type of serial console for the ROCK64 that is sold at pine64.org .] I got access to a CP2102 and tried it with Serial (again a built-in driver, but for USB ID 10c4:ea60:0100). There is far less dropped text, although it does happen on occasion for sustained serial output. I've not tried a FT232R with Serial (AppleUSBFTDI driver for USB ID 0403:6001:0600) but could have access to do so. I've not tried a LP2303X/HX/TA with Serial (built-in driver for USB ID 067b:2303:0300) but could have access to do so. (The device identifications are as reported by Serial, both USB ID and "Chip" name.) As stands for ubuntu 16.04's top on the ROCK64, running via a 70 line window in Serial, I've yet to see a screen update that looked completely good. But most lines for the CP2102 and Serial combination look good for each update so far. By contrast, the CH340G with Serial had text all over the place with few lines ever looking good. The bad lines were hard to interpret. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Jan 6 21:58:52 2018 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 CF257DF4F12 for ; Sat, 6 Jan 2018 21:58:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B56D1CE3 for ; Sat, 6 Jan 2018 21:58:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w06Lwb9Q013784; Sat, 6 Jan 2018 13:58:37 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w06LwbY1013783; Sat, 6 Jan 2018 13:58:37 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday In-Reply-To: <9FDFF16A-02D4-4EC3-BB66-AF9C0FA3B2EE@dsl-only.net> To: Mark Millard Date: Sat, 6 Jan 2018 13:58:37 -0800 (PST) CC: Emmanuel Vadot , Mark Linimon , Freebsd-arm X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 21:58:52 -0000 > On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot wrote: > > > On 2018-01-06 17:43, Emmanuel Vadot wrote: > >> On 2018-01-05 15:45, Mark Linimon wrote: > >>> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: > >>>> the early boot baudrate for the console is apparently 1.5Mbit/s > >>> I've had to use minicom. That's the only thing that I'm sure supports it. > >>> mcl > >> Works fine with tip(1) here using an FDTI usb<->serial, using a > >> PL2303XA doesn't work (but should based on the datasheet), and my > >> CP2108 should work but I haven't tested yet. > > > > Also my PL2303XA adapter works on linux using minicom but only for RX, that might be a driver issue. > > I've been using Serial on an old MacOS X laptop. > I've done more experiments. Here is what I've > observed. . . > > For a CH340G, Serial did not allow 1500000 > (built-in driver for USB ID 1a86:7523:0254) > but Serial is being updated to allow it. (I > have a preliminary release now, so I have > 1500000 support now.) I have to seriously laugh at the idea of doing TTL serial ports at 1.5MHz down unbalanced, unterminated single end wires. Just not a reliable way to communicate. Hopefully your doing this at 5V, at least then you have a good noise margin, at 3.3V you lose another 33% of that. Also most of these USB/232 adapters have no way to do flow control, so you better have a darn big fifo or your host usb stack better be darn fast at getting data off the chip. Would be interesting to do a quick Zo calculation for the setup and put a proper set of termination resistors on the receive end of the signals to see how it cleans it up. Or even look at it with a good DSO to see how bad and long it rings. I know that 1.5Mhz is kinda slow, but it is the edge rate that matters, and TTL drivers have pretty fast edge rates, 1nS to 3nS is common, so effectivly your trying to send a 300Mhz to 1Ghz signal down a wire, its gona be ugly at the other end! > However, there was extensive dropped text from > sustained output in my limited testing of this > combination. > > [The CH340G is from the type of serial console > for the ROCK64 that is sold at pine64.org .] > > I got access to a CP2102 and tried it with Serial > (again a built-in driver, but for USB ID > 10c4:ea60:0100). There is far less dropped text, > although it does happen on occasion for sustained > serial output. > > I've not tried a FT232R with Serial (AppleUSBFTDI > driver for USB ID 0403:6001:0600) but could have > access to do so. > > I've not tried a LP2303X/HX/TA with Serial > (built-in driver for USB ID 067b:2303:0300) but > could have access to do so. > > (The device identifications are as reported by > Serial, both USB ID and "Chip" name.) > > > > As stands for ubuntu 16.04's top on the ROCK64, > running via a 70 line window in Serial, I've > yet to see a screen update that looked completely > good. > > But most lines for the CP2102 and Serial > combination look good for each update so far. > > By contrast, the CH340G with Serial had text > all over the place with few lines ever looking > good. The bad lines were hard to interpret. > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Sat Jan 6 22:24:06 2018 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 A3AF2DF629B for ; Sat, 6 Jan 2018 22:24:06 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 3F87F211B for ; Sat, 6 Jan 2018 22:24:05 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 47a601b0-f330-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 47a601b0-f330-11e7-8dac-d32f5c2d02ef; Sat, 06 Jan 2018 22:23:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w06MNp9R002072; Sat, 6 Jan 2018 15:23:51 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1515277431.1865.20.camel@freebsd.org> Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Ian Lepore To: "Rodney W. Grimes" , Mark Millard Cc: Mark Linimon , Freebsd-arm Date: Sat, 06 Jan 2018 15:23:51 -0700 In-Reply-To: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> References: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:24:06 -0000 On Sat, 2018-01-06 at 13:58 -0800, Rodney W. Grimes wrote: > > > > On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot > bidouilliste.com> wrote: > > > > > > > > On 2018-01-06 17:43, Emmanuel Vadot wrote: > > > > > > > > On 2018-01-05 15:45, Mark Linimon wrote: > > > > > > > > > > On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: > > > > > > > > > > > > the early boot baudrate for the console is apparently > > > > > > 1.5Mbit/s > > > > > I've had to use minicom.  That's the only thing that I'm sure > > > > > supports it. > > > > > mcl > > > > Works fine with tip(1) here using an FDTI usb<->serial, using a > > > > PL2303XA doesn't work (but should based on the datasheet), and > > > > my > > > > CP2108 should work but I haven't tested yet. > > > Also my PL2303XA adapter works on linux using minicom but only > > > for RX, that might be a driver issue. > > I've been using Serial on an old MacOS X laptop. > > I've done more experiments. Here is what I've > > observed. . . > > > > For a CH340G, Serial did not allow 1500000 > > (built-in driver for USB ID 1a86:7523:0254) > > but Serial is being updated to allow it. (I > > have a preliminary release now, so I have > > 1500000 support now.) > I have to seriously laugh at the idea of doing > TTL serial ports at 1.5MHz down unbalanced, > unterminated single end wires.  Just not a > reliable way to communicate. > I've validated ftdi<->ftdi and ftdi<->imx6-uart at 3.3v ttl level over 24ga jumper wires about 20 inches long at 4mpbs.  Purposely not a good signal environment, just bare jumpers strung across my desk. I've also tested transfers between pairs of good-quality end-user type usb-serial adapters connected with a null modem adapter at 2mbps; those connections amounted to a couple meters of wire, but they were at rs232 line level.  I've never found adapters that can go faster than 2mpbs, because of the cheap ttl<->rs232 chips they contain (most of them max out around 1mbps). > Hopefully your doing this at 5V, at least > then you have a good noise margin, at 3.3V > you lose another 33% of that. > > Also most of these USB/232 adapters have no > way to do flow control, so you better have > a darn big fifo or your host usb stack better > be darn fast at getting data off the chip. > Modern ftdi chips have 2K or 4K fifo.  I would expect other modern ubs- serial chips to have similarly big fifos, but even the older ones all had 256 or 384 bytes.  And on a usb 2.0 bus it can empty out 512b every 125us. -- Ian From owner-freebsd-arm@freebsd.org Sat Jan 6 22:26:07 2018 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 8A6F4DF6459 for ; Sat, 6 Jan 2018 22:26:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (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 4976C21E8 for ; Sat, 6 Jan 2018 22:26:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21928 invoked from network); 6 Jan 2018 22:26:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2018 22:26:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 06 Jan 2018 17:26:00 -0500 (EST) Received: (qmail 4185 invoked from network); 6 Jan 2018 22:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2018 22:25:59 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 58655EC8BF3; Sat, 6 Jan 2018 14:25:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Mark Millard In-Reply-To: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> Date: Sat, 6 Jan 2018 14:25:58 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:26:07 -0000 [I wish I had control of the rate to allow it to be slowed down.] On 2018-Jan-6, at 1:58 PM, Rodney W. Grimes wrote: >> On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot = wrote: >>=20 >>> On 2018-01-06 17:43, Emmanuel Vadot wrote: >>>> On 2018-01-05 15:45, Mark Linimon wrote: >>>>> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: >>>>>> the early boot baudrate for the console is apparently 1.5Mbit/s >>>>> I've had to use minicom. That's the only thing that I'm sure = supports it. >>>>> mcl >>>> Works fine with tip(1) here using an FDTI usb<->serial, using a >>>> PL2303XA doesn't work (but should based on the datasheet), and my >>>> CP2108 should work but I haven't tested yet. >>>=20 >>> Also my PL2303XA adapter works on linux using minicom but only for = RX, that might be a driver issue. >>=20 >> I've been using Serial on an old MacOS X laptop. >> I've done more experiments. Here is what I've >> observed. . . >>=20 >> For a CH340G, Serial did not allow 1500000 >> (built-in driver for USB ID 1a86:7523:0254) >> but Serial is being updated to allow it. (I >> have a preliminary release now, so I have >> 1500000 support now.) >=20 > I have to seriously laugh at the idea of doing > TTL serial ports at 1.5MHz down unbalanced, > unterminated single end wires. Just not a > reliable way to communicate. The ROCK64 simply starts out at this rate before anything else has control, or at least that is my understanding. So as a console for the early boot sequence I'm stuck with the fast rate as far as I know. > Hopefully your doing this at 5V, at least > then you have a good noise margin, at 3.3V > you lose another 33% of that. Again, not under my control. But as I understand it is 5V. > Also most of these USB/232 adapters have no > way to do flow control, so you better have > a darn big fifo or your host usb stack better > be darn fast at getting data off the chip. Early boot code likely does not deal with genearl flow control either, not being willing to wait/suspend for long --or so would be my guess. The normal instructions are to disable XON/XOFF, RTS/CTS, and DTR/DSR (if it is even possible). (The context is normally 3 wire.) I would not expect general flow control until far more software infrastructure is around. > Would be interesting to do a quick Zo calculation > for the setup and put a proper set of termination > resistors on the receive end of the signals to > see how it cleans it up. Or even look at it with > a good DSO to see how bad and long it rings. I do not have the equipment or other context for such. But, yea, it would be nice. > I know that 1.5Mhz is kinda slow, but it is the > edge rate that matters, and TTL drivers have > pretty fast edge rates, 1nS to 3nS is common, > so effectivly your trying to send a 300Mhz=20 > to 1Ghz signal down a wire, its gona be ugly > at the other end! I have a general awareness of this, though I'm no electrical engineer. I've helped expose the signal structures that logic analyzers get via interposer and probing systems, both for processors and for memory. >> However, there was extensive dropped text from >> sustained output in my limited testing of this >> combination. >>=20 >> [The CH340G is from the type of serial console >> for the ROCK64 that is sold at pine64.org .] >>=20 >> I got access to a CP2102 and tried it with Serial >> (again a built-in driver, but for USB ID >> 10c4:ea60:0100). There is far less dropped text, >> although it does happen on occasion for sustained >> serial output. >>=20 >> I've not tried a FT232R with Serial (AppleUSBFTDI >> driver for USB ID 0403:6001:0600) but could have >> access to do so. >>=20 >> I've not tried a LP2303X/HX/TA with Serial >> (built-in driver for USB ID 067b:2303:0300) but >> could have access to do so. >>=20 >> (The device identifications are as reported by >> Serial, both USB ID and "Chip" name.) >>=20 >>=20 >>=20 >> As stands for ubuntu 16.04's top on the ROCK64, >> running via a 70 line window in Serial, I've >> yet to see a screen update that looked completely >> good. >>=20 >> But most lines for the CP2102 and Serial >> combination look good for each update so far. >>=20 >> By contrast, the CH340G with Serial had text >> all over the place with few lines ever looking >> good. The bad lines were hard to interpret. >>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Jan 6 23:55:38 2018 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 85757DFAB8D for ; Sat, 6 Jan 2018 23:55:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (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 3331B68C4F for ; Sat, 6 Jan 2018 23:55:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13086 invoked from network); 6 Jan 2018 23:55:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Jan 2018 23:55:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 06 Jan 2018 18:55:36 -0500 (EST) Received: (qmail 2604 invoked from network); 6 Jan 2018 23:55:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2018 23:55:36 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F1C0EC9458; Sat, 6 Jan 2018 15:55:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Mark Millard In-Reply-To: <9FDFF16A-02D4-4EC3-BB66-AF9C0FA3B2EE@dsl-only.net> Date: Sat, 6 Jan 2018 15:55:34 -0800 Cc: Freebsd-arm , Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <0BD8991D-8425-44CD-88AF-E0BF9C10213C@dsl-only.net> References: <20180105133154.GC31064@lonesome.com> <34E00728-3FC0-4B56-A420-5171FD224008@dsl-only.net> <20180105144541.GA32430@lonesome.com> <6168e37ebf0210ddc49947030db83e9f@megadrive.org> <41bcf0afe2a94d80909837b43d25022c@megadrive.org> <9FDFF16A-02D4-4EC3-BB66-AF9C0FA3B2EE@dsl-only.net> To: Emmanuel Vadot , Mark Linimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 23:55:38 -0000 [Based on Ian's observation report, I decided to try the FT232R: It seems to be working great. Thanks Ian.] On 2018-Jan-6, at 1:23 PM, Mark Millard wrote: > On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot = wrote: >=20 >> On 2018-01-06 17:43, Emmanuel Vadot wrote: >>> On 2018-01-05 15:45, Mark Linimon wrote: >>>> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote: >>>>> the early boot baudrate for the console is apparently 1.5Mbit/s >>>> I've had to use minicom. That's the only thing that I'm sure = supports it. >>>> mcl >>> Works fine with tip(1) here using an FDTI usb<->serial, using a >>> PL2303XA doesn't work (but should based on the datasheet), and my >>> CP2108 should work but I haven't tested yet. >>=20 >> Also my PL2303XA adapter works on linux using minicom but only for = RX, that might be a driver issue. >=20 > I've been using Serial on an old MacOS X laptop. > I've done more experiments. Here is what I've > observed. . . >=20 > For a CH340G, Serial did not allow 1500000 > (built-in driver for USB ID 1a86:7523:0254) > but Serial is being updated to allow it. (I > have a preliminary release now, so I have > 1500000 support now.) >=20 > However, there was extensive dropped text from > sustained output in my limited testing of this > combination. >=20 > [The CH340G is from the type of serial console > for the ROCK64 that is sold at pine64.org .] >=20 > I got access to a CP2102 and tried it with Serial > (again a built-in driver, but for USB ID > 10c4:ea60:0100). There is far less dropped text, > although it does happen on occasion for sustained > serial output. >=20 > I've not tried a FT232R with Serial (AppleUSBFTDI > driver for USB ID 0403:6001:0600) but could have > access to do so. I've gotten access to a FT232R for use with Serial against the ROCK64. It seems a highly reliable combination. For example, I've yet to see a 70-line top display that was corrupted. [Of course this also introduced Apple's driver, instead of a built-in one for Serial.] > I've not tried a LP2303X/HX/TA with Serial > (built-in driver for USB ID 067b:2303:0300) but > could have access to do so. >=20 > (The device identifications are as reported by > Serial, both USB ID and "Chip" name.) >=20 >=20 >=20 > As stands for ubuntu 16.04's top on the ROCK64, > running via a 70 line window in Serial, I've > yet to see a screen update that looked completely > good. >=20 > But most lines for the CP2102 and Serial > combination look good for each update so far. >=20 > By contrast, the CH340G with Serial had text > all over the place with few lines ever looking > good. The bad lines were hard to interpret. =3D=3D=3D Mark Millard markmi at dsl-only.net