From nobody Mon May 24 11:00:01 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7415A7AF6C for ; Mon, 24 May 2021 11:00:06 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpZ460Ldpz3jLj for ; Mon, 24 May 2021 11:00:05 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4E54C178F for ; Mon, 24 May 2021 07:00:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 24 May 2021 07:00:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm2; bh=U8oLahNJmW/VOVepD1rxdWjS2y6XKdFZXrD2K1MibuQ=; b=VnPvyTuy B3J+V+piZV57xprnBPas7XUTsgX4bBwaETwqrC77TMcUzvsVjIHe4NzhQjbB9GxJ XEkXXP45pqxoYyi51EanOmdkdpYgFNqCyn9p06hVIZ6ASNm7tuLguqK7aCIADGfv 17TfLjHX6C9zsC3qSAX+U3UBAGJQJum95aphMErvO4WOCT4hTNSueTFxTVnMqL9q GnF6rbM+a8QLWmvQquiUWqIxsqAB15N/M0XXEHmRt+9ueycTHtBSJFdVvO6xxpQg cAhxRBWtlOp0y4FJcZKmqwkov9fVpCWhsiAnJW2erOnvsjGRV6noKdJxkDeOZgxV HIejsATSnJkM5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=U8oLahNJmW/VOVepD1rxdWjS2y6XK dFZXrD2K1MibuQ=; b=D72wxjQRXGQUtLsiBY11d8RwOF9Et7MbOuUmQ0MhEvh1c o4/E6hhblihfHixMDv+dGFRaUvLIwkFdbhCvLcEgLemGeNs/DHJ3TQ6HczPYfWxi RTNbsOPmq3hol5hXtt8sx3S2jGnCRPdQcSB7sAzqcXSt3v08eEufQFa22a5plLIK 5Rfyzp+hXDHO1r7fgu91gzDAJQ1phAvx7r7/Df7W0Yr11/45pUDOTWW8CdtNrObM Z1SZSVbPjFut4xGYOW3caUtN60Hr9gzjH5B2U3f3C1+6xqGO5DD9V4nvyD817jlm /pp+x3w8jvI//TsQn9/P5+4vDKSRe5wclzlxYl+Zw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeiffffteevvddthffhhfffhefhgeegvd euveegteetgeetfeejfeefuefhvddtleenucffohhmrghinheprghmrgiiohhnrdgtohdr uhhknecukfhppeekvddrjedtrdeluddruddttdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgv th X-ME-Proxy: Received: from ceres.zyxst.net (ceres.zyxst.net [82.70.91.100]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 24 May 2021 07:00:03 -0400 (EDT) Date: Mon, 24 May 2021 12:00:01 +0100 From: tech-lists To: freebsd-arm@freebsd.org Subject: usb3 to ethernet adapter on rpi4 Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3frHSRv/yJ6Up+lr" Content-Disposition: inline X-Rspamd-Queue-Id: 4FpZ460Ldpz3jLj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=VnPvyTuy; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=D72wxjQR; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.24 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[64.147.123.24:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[zyxst.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] --3frHSRv/yJ6Up+lr Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello freebsd-arm@ Does anyone here use a usb3 <> ethernet adapter on rpi3 or 4? Something like https://www.amazon.co.uk/ATOLLA-Ethernet-Adapter-Compatible-Nintendo/dp/B08= 86B1S5J If so, what version of freebsd? What does the interface come up as? thanks, --=20 J. --3frHSRv/yJ6Up+lr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmCrhygACgkQs8o7QhFz NAUu9BAAhq7rXJ+RpVFG4hQ90Yk/obQdLntyWnT62b2skb4cD8Zr5ClY4SXRuMtG gKBRE3WWsAjJaaI9SsaZI3ufJWeThnLhd2YnmRo4MQ1rDQRZ/lAYM6topb1IoEgX skPJPI9ccY+OSqCUtS8sHSqRK9t/sx4CzPWlId0lrODX+BPX6LL0qdkBsTx/feV+ cNnmtomLVj2aYGJj0NXj97HRHmtA29kvJ8sT+SjQ3EzFPsYE3oGEVRmLjQG13prF Hmz9fmMlmrnD1UV0BcJ62rihtGvEKfYTs1iYB22oq3bSobTKk/jRBZOqYw+DiQN3 P+iIv1WAMUGWYxZaN3KHwJFOQkZlX+vPpbMMZls/EsjmqRc8Pc0M6OWdSTEKQj+E oFVRnlNn8yMWa+9l6ExrsTVym2dMoBvRrdAztxhu16LylDrkSp9fGLtIRT7L0Lq7 fsXkcVnjmo3AIHIN8+UGC9MLAXYUwyObUg6EMHPTzjiUCIi4USUAu5gNk5MibXpP IAbLZZA3QtPa0i8lcsz7r8+C+2ufjjWHkGv5wB0rX+wQUFa6j83hKFGTF4aNqDlF n49ZrDdxatQp7aL37qErqP8Su3TIXDfmigY2HzTWXBqTnuAAuA/Mx/qSRDSh7Ii3 4oRU3dPcM4CDgFcokDnJ5gbYyD6/fbNOj+t/ddn6S3qzdQ3tZGY= =JMZG -----END PGP SIGNATURE----- --3frHSRv/yJ6Up+lr-- From nobody Mon May 24 16:01:29 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D0D39FA7AF for ; Mon, 24 May 2021 16:01:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fphlw2mfbz3k75 for ; Mon, 24 May 2021 16:01:32 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B31035C00F2 for ; Mon, 24 May 2021 12:01:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 24 May 2021 12:01:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=N1c5ZC/ZhcmWjIzJMyRD/0ZFLA/ rQ/Gfip3El3RIteU=; b=cw37EspAP7sRzxNGxvefpM7CJOCUp3ARP/hLI1jZxMy egyPd7hGXY4ErLkRo7W8EfyNVv41gvbaGEieEXPvwjKXBQkk/AaiZSPGJ2JfdjBb yuK3ppF8rZfoYNhGeDL5kXnTFOujYek9UrTSwTdrZoRt9SKzK45nOvrN5Obeb7bn SfJeqJeqQvdM6qOx+5PXrEAAs9lfMp+J19jyNRKaQ2i2uJHpHseDeYedcFf9QYZm zMObpqWdQ5pJn39E8AqlNTQzxtUpIneYATmfL9AyDYkIyDpjnbrevwVC6V0od/mg Yst49mic8pDxYi0ILWAsKeFCJd9QBe9+mp6QgevNK4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=N1c5ZC /ZhcmWjIzJMyRD/0ZFLA/rQ/Gfip3El3RIteU=; b=p8hsC/SARzt9vdQez66EDb 2NM95OoHmI2GXwIHl/CRxA71frjRUOGjQaxfQE4+kmyxMjYrKBMOFmeuBKG8Df9y HBvxy+FxySbhaocfuzKHPl3Vch6TVYeXYpizJBL1Zw3I/wnEMKG8wQJ9onwJ+GLw iZ2m8hF+elMcLPaZ3VZa5+pQIRYTDRuUszzkOq/l56W3hD6vV6Ull39/TmGVuvqC 4PO3hKivZvI/L3LqHcnQQXFaVYWuY19l7nXrCkQCkx32yFHtKP0JF9suxDZGv4eg +lTMtzAY2LWVLvEbML+1Xbe1BvrE4XkngZwkxV+1e/YcU6lqZYn26uzDYknl+Jbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejledgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucfkphepkedvrdejtddrledurddutddt necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthgvtg hhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: from ceres.zyxst.net (ceres.zyxst.net [82.70.91.100]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 24 May 2021 12:01:31 -0400 (EDT) Date: Mon, 24 May 2021 17:01:29 +0100 From: tech-lists To: freebsd-arm Subject: Re: FYI: Example USB3 boot failure on RPi4B ZFS-on-root system booting main: uhub_reattach_port notices involved Message-ID: Mail-Followup-To: freebsd-arm References: <681FD1BA-2796-45E2-897A-28C749E80261.ref@yahoo.com> <681FD1BA-2796-45E2-897A-28C749E80261@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E8Fw27v8usJzZL+z" Content-Disposition: inline In-Reply-To: <681FD1BA-2796-45E2-897A-28C749E80261@yahoo.com> X-Rspamd-Queue-Id: 4Fphlw2mfbz3k75 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm2 header.b=cw37EspA; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=p8hsC/SA; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.111.4.26:from]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm2,messagingengine.com:s=fm2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.111.4.26:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; MAILMAN_DEST(0.00)[freebsd-arm] --E8Fw27v8usJzZL+z Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, May 22, 2021 at 08:19:28PM -0700, Mark Millard via freebsd-arm wrot= e: >. . . >mountroot> ? > >List of GEOM managed disk devices: > > >mountroot> > >The USB3 SSD was the only storage media present. >Port 3 apparently had the USB3 SSD boot media (the >same media that the FreeBSD loader got the kernel >from before the above). This happened with my experimental rpi4-boot-to-zfs-only system too, a couple of days ago. Unfortunately I didn't note what it was made from in git. Maybe a week ago? >Cutting power and starting over did not get the >problem again (so far). If by "starting over" you mean cold booting, then yeah same thing happened here. A buildworld/buildkernel/install has happened since then; it's now on n246839, and the problem hasn't so far re-occurred. --=20 J. --E8Fw27v8usJzZL+z Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmCrzdAACgkQs8o7QhFz NAXCSw/+JpnQHJMgSYCosplBl/R7l0qcNrxjHnqv/EAOXAaucutypDXcZf4x7e00 lKs7wr6ZM72A2Nup+PVJCR9iCPewXU2cSAKKTBajgGHAqeWCBW0e/8veIzDRrCgU ojLolea6MF1UsrG5nMcbuOAwb1PBQbfIHgVEyVGbpNJJGvAtA8omIPEICE7YCNLn dXrk0tD08vgC5nWUiJbuwYF9w54NlvdmoqlD69wCEPYOFCg2JAJuIQULW8DImKUL MTHYggUZxIymYptZK5k4kHB9PefJv//9gxQbJqJ7tHdPkL4Ea1OVJk6ijeIoOV2+ v/eGYXAVM4gIYM8ueHMGNKj6TqALaGZ0MeHC/6LfOUs3g/ZS4/7xCJFe/t0FOIp6 orwTfBwY0xMUogVBT2ZXTM1pmLofet+Tsaxgr6jJ29Y3a2NLHIhLleBc8f1ZsSxD aEc0gZmkCErqTRPaUjcCI19b7JrbDYZQVSmMCalu699xcqMYG9/+n75OjDkZEVF2 ecU5ACSM/E9FMPf+0dJKAO2yOboyOkNZz1BChnhRDvQlDdDjI+O+QqgMkq2ggdlE /o7yRux5R4cLwNI/htVLoWB9rbS+86qzlQunng3ZuoyZBgzha8bKB/AGJDRhmL6+ q2DMLpmtaTZKYkJrSGigavJ9zR2Eiu72Jw1/kgIfpJEgND+zQLI= =aGqk -----END PGP SIGNATURE----- --E8Fw27v8usJzZL+z-- From nobody Mon May 24 18:06:46 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B09F59E5122 for ; Mon, 24 May 2021 18:06:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FplXX2x95z3M9Y for ; Mon, 24 May 2021 18:06:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621879610; bh=HcA0JGJoljTd00QTVTZ92rDoRrkY8qXpBJtmTd8dMoQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AN9sh5u1LH410QZJodmrRkHBSRl2Xn4uwXDVrDIUQX8mwgTbdXM9Y+0yRmGZHhcdVl3MkY/xNIV0zNXsGLB8FBEjRBgt/gdaPFnkmy40tAkOFz0n9a3J9qwGJAH05WvcWagT4ZFFUQAHPvsA/mnHB+rQeMYn37cOTQo/xrbLwZHWZd1o9wNjGYcpuw/WJ87/eyz5i6w1AZHsUn59Omvuivmh69gIdX+CuW+dvG8nRYS0aMopQafH+fUh2g8ygO2z9W9eFDgMPLoZ5hJCKIiC+eYBk0uj5oX1JmsEnbfs3tuf70Jj2fMifKcHBjUDgHDQaY1SQdLTWzY4umO32dXzOg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621879610; bh=qmaHtvQ8l2f2vlaS7fGzpQRDjnfhPNlA1wP301U36fh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F8+W5+57K5XRTofAwDZ+BIUDommJ3clM873LtYR5mlpJEE4s8g1kHEqYDdu0hjj2Ar7b8vYB0Jn952r668OI3FD2eYE7LiQLuySVOGLW79f8hLdwleFrbqfQ4xrITp/+XAENCbD+IgP97krbH+iAnqXmYxFa6euW0rrSMFlc+USYQS05frFuwGLyVVi+ptVzqCfY2AGFaPaHm6RWieZNx5onePPhfv5jrZSan4hZMZJfIgIa3hGXx0ibOxjNFfzk2B92Ct94S6kJyVeoItjjyEMiZuEOCPvjfIBLLec3tGkUtmc6HJ1gHleiP0hTYGVdLqdyalrGroHqxTzikHsFeA== X-YMail-OSG: 9v2W4uYVM1mJH7Wc1CgwDikIi_ZDNak8h9H5_U9hvtkdTlVkYb29WAQDzyXeRnN rJHQKxZJGYHB2kdzFzMLnTEcZuTJALbWlig_OL01dTNkgSZYPZ8OhTifCbWxgFOlNs5J7Px8n.4s _WXEdRMVDYWK86wyB6Q9LzfY_y9Eft4ELE.N_FpcCT9PFIat8dcc7QA4hEeFMH_AKqLiesr1hiz2 S7HTPcDutvK6o2XQAefUSdlVmSa3Fo8MTR1XxAzv9FzFiCtqZSOn454SxtXppDhLz343oUAcEyrs UOK07RE_3eRILL3GmdooNv5JwXD2IQsbz3B8AZmkIVMMk5AewfWZaIXI8YkvOyOSf6WrCOW3i3LW GblcOh9ljNBw8HjCiWfqe255wcplZuXw0easfGE.lr8xMP9wERbVnmgjmAqqBrsS_K48sMPOmCj1 urL3THNMQ5soRI7gNOtgipYIdKEH9S_CSQAWVBdzWDFwVOBTniOdST48S41DyHCF85dzCUHaLFbq rs924xDb5DWlx3o1UVaZyLOEVf3FrtUgk0DZMj52DMytQxbb6gerurcoq1Lcib_xvVgFlLClpznP JOexg9WQle2xhSd5b5zLzj7_V1JW945npFrplEoqsZAMBspPySbZ6MWJRQvrrJH48UFdYAz92bjC TnH2B6fw069gqQlCiT9QT6ZLhed8q0OKf_VKd1DhMkkBPZ9AUWgfVBpPvDiaGgS5NiZrIgBFX9Ui a_.UtRxJAZZWJWQ1eeH4v3aJizx2VeyWa3uz35.mZBnpyeLfCddgR.nAB.R65P_CyBHD2QB0TYQ_ vqRsZUzPA47angbBceNhCxYGy.B80KMC1E3.90Ckoji7jmGLOCH_wS7KTDhW88cMm3PCuEWkUB.k fjFcxxvNOWumDPCUl1vV4X9i69EGt7gQ6V8YFc22BvxMc.Ch6ZzStJW_gsSGYnc1Q8Gm9SF8YlEL VE1bVTH3Hj9MotM98WFRGCncyNs0QJFxVOmOf3gfJxUpRc73Gs_4NZwNWCMuiv3HN0mEyOHgXosd DkEYdhBsiZ4hPplG.gPMsi0Zya0wVgrWuxZjWQQTXhELx3gpPlS6ibDDw_PXGlEM8z3eNjLvOzo7 lHA_gvKPcx_V_OpFgN1QLL_0xx_p1zzD9TKwjk62HRFWI0763tcutZgRv_GXPorwQwy67KqxgxpM a83imnhVosMJqEspKptRq.nSkTnp6PhJjbwg1dzc4mLsbuPx.1YNe3DaYj68YJjodpItb8tyaumU yoGRHSo8vZciXvNCoSfRQNNmUzJ1tgHE9jHah2QNo.s6j1LOzj8G1i.1CuTuKHwIHrjDEkOq95pF MG4mPcAuXwfTot9wVc4weQ7KJalxbOdj5Pvd1BgIX7.LU0fmLeJzt7uUEf7ZltLtrntl_ZheDgH. drSiKA9Oy4BiYE_quZkREd89gEI31U7.Bw3NVW_aJwqy.peiYn2ERkBXrBZIZyG_nqK7ie47Bokx 4FjK14MLn2mnB_W4AjuBuCg2WvMFeoDODTRIw5lD.z4oxcasNfa8AmTXsXQSmMDeDENH6iPcVdJg ED1MoXD.9ZkEgbXzfIqFyhRprLB.fAOc2n_jObFBYZKxLORP_fwfkg9TMbkxaEkMtr1Zf389IpX0 uvmzOWhRcB4ucylovv99m6XKk27cJ2XgiFrSlMxcsBNu4eMRmBts3AXbRCbxue1JTSIN_c.rG7iV RRARYUsfbnWz2xxSfAkHfvUK_WV2Qi3FV4WGgK0zyswIrByeEA54I3706k8FyCTw8ALHsNxQZ0rD tkeeG9qgYrXemA9y8peg1GY0Ql0BxWnCwArGR_pmL0ToabQBee0eC82.v5Hyd0SaSlsGvrTAB9aS oZlUO4rjBtqJ.9k7nzbIY.ctWBxUzliv8y4jfcqE3l4r6DXONswucCfaEcRazUGz6A9wCV.XCN_U .hiqSDFxavAfgYESWRTVhrQ.k409swyiqVrvlk8cwwfbESSpbM5UCJRFyh_7B0mwb7x9ZFz3ubN1 awWhhwVDOIdcSS74pwjjokc_zL9qX7D5V6zLWvP6liH6Nrnq5OqLKeCtMLgD0GZhdKdgerHTk.wd suXg4y1q6q9msDkUm_GFQ1mumdx9lzPBGZJ9bZBra3uhWGYD5ygkoADCzN0sZ2QjvYQSkspH.xln 5Wz3qgeWxf67YBddjPBsJSuxqymMIIoPQ4isb.sB9Y2d3d9sp5.ILrC4eSEfoExhpEuvT634uXE4 8PkbkeB4enodkPJ2JK78FvtGQBBi1sFLIJO.nqCAG3FuL_xZpA1MHhXzdIMp9LzfVaI_FP0pat_G AZ4yDV3UC_C4iiTbOiJAjSMxIOp3tA6VE3aWGvwvhSrxru2TyuLl4blVQ7C19bSGWapWY5CXmaeA _sJleOdENHVTZ4JrMlZmq3W83fj7cARHA._utB95NgjI5veZt11f7uwPUEvA.t.2lquHSb1J1gBm qqgmvdXJCVlhw59zcyrLMtwDXwXNWKCo_HmWRjuM217YdjOQcan5EqNs5EeS69tb5pKNu1CnMmct znxWtDmgpTVwBOoxnH0IdTawYy5hhduF0NCPvIvDpXtbL2HoMEukdkNHupK60fOmzXy22ytJEzp3 2kKpTkgcRUfwHRTUy1LC3PRWDvKHFOg807NBp6RvFmQYe31JavKXdWx4i0fV5RQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 May 2021 18:06:50 +0000 Received: by kubenode563.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 245049b7752e7f9f51b57f4fce1d17b2; Mon, 24 May 2021 18:06:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: FYI: Example USB3 boot failure on RPi4B ZFS-on-root system booting main: uhub_reattach_port notices involved In-Reply-To: Date: Mon, 24 May 2021 11:06:46 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <681FD1BA-2796-45E2-897A-28C749E80261.ref@yahoo.com> <681FD1BA-2796-45E2-897A-28C749E80261@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FplXX2x95z3M9Y X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard On 2021-May-24, at 09:01, tech-lists wrote: > On Sat, May 22, 2021 at 08:19:28PM -0700, Mark Millard via freebsd-arm = wrote: >> . . . >> mountroot> ? >>=20 >> List of GEOM managed disk devices: >>=20 >>=20 >> mountroot> >>=20 >> The USB3 SSD was the only storage media present. >> Port 3 apparently had the USB3 SSD boot media (the >> same media that the FreeBSD loader got the kernel >> from before the above). >=20 > This happened with my experimental rpi4-boot-to-zfs-only system too, a > couple of days ago. Unfortunately I didn't note what it was made from = in > git. Maybe a week ago? >=20 >> Cutting power and starting over did not get the >> problem again (so far). >=20 > If by "starting over" you mean cold booting, Sorry for the horribly ambiguous wording. Yes: just turning on the power again. > then yeah same thing > happened here. A buildworld/buildkernel/install has happened since = then; > it's now on n246839, and the problem hasn't so far re-occurred. Side note: I'll note that using the likes of just "n246839" to identify a specific commit is messy so far as I know (even given the branch is known). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon May 24 19:16:07 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D4479E74A0 for ; Mon, 24 May 2021 19:16:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fpn4c1NDFz4Z18 for ; Mon, 24 May 2021 19:16:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621883774; bh=yurVWCsdJDaodrTjKs0N8q/d+hJgIfhTJiymQxAellg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LjCxkqfwZBJNBJIqhr2Ob9JL4ovcZaKgQBjFaebZyqkltvCdtQ15ylEjqH5oD47tgNx094N2gGSoESR1N6G87HM+e/fIC0++8RULZJGApxER4JdPl6DQqry9VnSiJDTI6AIzmZeaD89S1XCLsL1IQjne2MXs7GHxsqCzSUO9H4M79+A6mFn+N3xW+b9uAL6uDAfwjeAGSsBv5AUSOg3PDNGNHTnZK44T4OSXEF/X+ikXK4TQJ5JLIV8hPFORDEbm0orgdmRgFIrvAQxmNKfYYNL25dbAI5mXS4jGICQdEF9fWyO7TYBGgGZiu83/I5wzg5t2ryjjBr6ADOZCu4kwIw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621883774; bh=EcZ/bv6ELleXYVLkDAJ3d5QSed4On5MH6HqB78u4JlG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=llqEc3bozfEfQhmOIpNw2d/luSYntfZBqfVPqBad+1y0bu6sObw2JrCH30fWrDxiXnTzkXzCRGwo2zpsLM7WRBPDNzcCbmAajdOIRSrW6h4dGqHqcMm6ZlM74KqLwTnBcbnH87dwbivWvjXL+NK3BBJPCaAxDJHgo+/pBt1h1rN4UpUKKL/KMnd87xv3o6AMhcx6h2J9a2hbhs4PnPWd/WWXROa/KsMNY/Uw2u8Oc5FiohkbJQVrcn9dCq9KEYSfzw5r6qjzFCLsIE3zyL+e/eQSpL0w8xfSnhHOsvn3XOUc1O9bMAmgRoekNyk1nhv5HfbjmTfAQILwAnt0NIqjTw== X-YMail-OSG: Aktw7DgVM1naYDTR3ZAeuSjy3OqpwwgcU4qpWgIu95BrGnx3M_bBdabuTnzbNJG Nr.PG8oMMC8BR5zAWSfOdTjQnzOmDRAj_TTzt8DpNn4LePBgUtES5mxF7LnS51RvuEy4oKpDRzor o8JZa4pqsOVnnfwuBqE5lyDZGVAerAeS_mrRn66U0ofeQSLBmT96nnF6.pHV68vuepwMJJmqp68f dbU2DJKsT27MvmEOj6mnuxNGju7MFj6Uvgj1OSWLJyo7b67PpmnVRWWi9DL2OVVSVLsWZwY9pbHF TLs0xxRX.tkxFMrWfFss5loIwtJlKSX1nkzy2M8YR2gSSLJd98DLiWvKYUSwd1kus5aMQ0kr8AQ6 G_03DjQK2R7bM33AfYuJpnIAnRst_cxC7sxfQLobM1T7S0eJzdZqfz_1ULNGFaCc1BiTPYR.G9AY 8B1e.GDVMLLSqlgHW4zgui.iTUpfSI7veKw6RnCgfASW9ZrLv7aOHTzoDQiIoIQmaCcCJ272a5LM oZ5IFCBPWWPcHrEsR.BkTEixGoidHPXQLDMywspS2PgDpnwh.2XovDZO300vunMKpIxgqm3dTguh uDyFc11Rb34EoRbRvUJYl4IIGyvuXrIHMSK74.idxGbHyGdhE4NHRGgIxSClQCIGDplKOhrZcHt8 clzJdvDc3MgXr_scDVjeexPSoMKWTYjZQOvOr20tfXd.mQ79f2LePz81IJaw6FFwfL67CdbC4Gzw UDSFkkXN6si.LbJx.AHoD300XfA0Ed3U7HOOgTPhtdQ4Q1bcU4ajqZWMhc5U3y_mCbxt52MWzqfq I5yl3VLlZbu8ACj3X8T1jdBjE1FBIhv4YFXeMwzjMOzscEd_pZVq0v74SpPUUKsf7oJ5Mw1piiYM Ovmw2QgL9xR1u6Au5vWhBUmjFC30bHKCYT9HBkvx1rWfBwz264M2zev158XCHpxaAeD247QxCXVL .bfFxAZpOpvSgzYW.VjyL8a6TA0RqJpJ_GE_eRkGUUDlUq52IPN.vAAz9gx8UHnsmtAJxfK5Z_O0 svzNTZfrSQ8SILxbRLraP3liaFphGCy8xUnvf6nAEviu0UontQ_DeGNeoDV7F19rWVAlCwoVEH.T BboFfouTyn_X64.IPSBg_K.aCBWZaDvDR6w9NWNYRQoYDj14u3J34R4UaB6atHKgsHYT8vGum9qK F8NNtbBscOJ5ai2uT6dpHpIr.XTR7S0N6P6XLpgUxRT68cKylMnnlw08J1yMbFQdKP6xBNU3x1LP WFZkR1wGYpHo9lzwiMM_LLRJb5gpJH45It3nRmXS.6pZ1GU8ZxxYemR4XktD6schdwD1kKl_P2Jv pOkPX3t8Egef9HnfVx.Hr5Rbcy3FUTx5vLI78fyWQoCN7p8eK4dkrKf2s2uV1oJBn4LYQPGjFa84 IkcU9JnHUtKstnlO7q.vOkHVwvQIh0sDpN4RZFUud3hW9o4d2VlL9u1M81LThWHSws3pnjh8dzSS DR9QPL8tR9iuRPTLP1LjITibu8..UwUojIYfe0jk9NDMVnzE.HWgRjlHoJYIjFmreMVdqLUuPODE EBIZdjKMy..LrjFNGR26YlTlsaTaGvKC5SrZOfeziLvRbKj.Q.K7xwWG75gFKh1N867UbUTloC7k vSq9qYWns2d8kDxtyzUFf3t2HNZ2ZyQ3wms3TrxHf9sxeeVM6fahPuaqU2yTYeL.veWDls.6WDvl I0xdWqO.LktiNvFGh3E4OxqQmRaTlDkbdvdH_e6T7qNERxHKw2w69dT3p_JaY8FTDDjgl2LiBUOz cgAGinDwbfO8NPOtEIQw7kUCmGFfUyxc1MtzSYjL.eVP9NqQXwiitHlmspzIebbt91MYv6Q16r_3 LEtdJcFMG1CYT16dpSy8px2rZeVZk_3QuOzldl7cXIeTexPx409QOphDnrrBEC0Fr8A2HBdXMsrw S6qGJTuQAIv.HJ59554AD4EG1TJJQbZ1fJmSgsPwa6d792breBaMc5Oxf.0WgdHia5Rm2aQWDDcS gaZO56cU5VRbTPyVpDFP8M60sKbUK3AX5jSD5G7uI.3gljx9gqHbdyX3ZmUnorwVesyJKKKO5GMH HiDn0OZ3Py7J7L3SRgJtIzcRzhOwhRFb9m694Kfc4nBPuP5wxzTZsR8N3br0NMk2TLN1kMFw7RSf 8WP3Ccp62dBZqOWiXQ7QaUvJ_OSqeSl_ZgTKTDQSNQ0umAOWin51iLmyVnrK.kmM2k3eZlKuT8MW R0PN6GxQGbP0dNdHVyJXCRDH7Xs2HLTkXq747MDSOlF.Y9nV9WygnPJESddex16cnq5hEnx8vyoW XTcpXDvlC8ewgBbvFLZLyXbqdUzl.bnIlQ9Sgpmc9QXJMTufRCrNtHD1jL2g5TZfN992xu8oO.vd 1RcTkRy9hDqy17vdPCL0f6G7vTLMpEXK2PacCI0tJlanojilA9McebjQegCjE3hXxm2ZFyegVhIQ q9OpTdB7J8Q9g1tgFZJIxCANW8m52DfKWVUHb2N6FQwLarQOfRcXfMFvfF56bqF3lZevrYadUkv_ Sa3BKke_HOR8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 May 2021 19:16:14 +0000 Received: by kubenode549.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ab4635dd9c2896f95b7a7513cd3dfc15; Mon, 24 May 2021 19:16:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: usb3 to ethernet adapter on rpi4 In-Reply-To: Date: Mon, 24 May 2021 12:16:07 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tech-lists X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4Fpn4c1NDFz4Z18 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard On 2021-May-24, at 04:00, tech-lists wrote: > Does anyone here use a usb3 <> ethernet adapter on rpi3 or 4? = Something > like > = https://www.amazon.co.uk/ATOLLA-Ethernet-Adapter-Compatible-Nintendo/dp/B0= 886B1S5J >=20 > If so, what version of freebsd? What does the interface come up as? I've used the below over the time frame of using a RPi4B: Genet was not initially supported in a context I was experimenting with. Other than some testing, no other RPi3 use. The RPi3 has fundamental USB2 speed limitations as I remember (even for USB2). Part of the issue being that all USB shares one internal hub with limitations shared, if I remember right: ultimately single channel. Several "CableCreation(tm)" "Gigabit" devices (no model number on outside, separate materials if I remember right): ugen2.2: at usbus2 ure0 on uhub1 ure0: = on usbus2 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto These are generally the fastest of the few types that I have used. I helped test when the speedup was done for a range of Realtek's that spanned these. I could look up when that was if desired. The update got to more like NetBSD speeds. (I did some compare/contrast activity during testing.) I've shown that genet0 has problems for non-debug FreeBSD builds in my context, problems that have not repeated with the use of these instead. I also use one of these on a MACCHIATObin Double Shot. (FreeBSD does not support any of the built-in Ethernet hardware, last I knew.) Sometimes used via the USB3 port, sometimes via a USB2 port (via a USB2 header). I also use one of these on an old PowerMac G5 that has a problematical built-in Ethernet. In that context, they are not as fast but were somewhat faster than the others that I later list. It has been a while since I've used the others in any system. As I remember they all seemed to work. I still have them all around and so testing is possible. A "j5create" "USB 3.0 Gigabit Ethernet" Model No. JUE130 : ugen2.2: at usbus2 axge0 on uhub1 axge0: on usbus2 miibus0: on axge0 rgephy0: PHY 3 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow A "plugable" "USB3.0 Gigabit Ethernet Adapter" Model USB3-E1000 : ugen2.2: at usbus2 axge0 on uhub1 axge0: on usbus2 miibus0: on axge0 rgephy0: PHY 3 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow (Yep: essentially the same as the j5create, other than "Corp.".) If I remember right, the NetBSD speeds were faster for these than the FreeBSD speeds for them. There are probably notes about such in the old messages from when I was testing. I hope this helps. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon May 24 19:29:45 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C0C519EC6A9 for ; Mon, 24 May 2021 19:29:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpnN94ycNz4dgK for ; Mon, 24 May 2021 19:29:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 931237F8F for ; Mon, 24 May 2021 19:29:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14OJTj9x018761 for ; Mon, 24 May 2021 19:29:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14OJTjmQ018760 for freebsd-arm@FreeBSD.org; Mon, 24 May 2021 19:29:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256132] arm64 kernels with aarch32 support should claim support for armv6 in addition to armv7 Date: Mon, 24 May 2021 19:29:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fuz@fuz.su X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256132 Bug ID: 256132 Summary: arm64 kernels with aarch32 support should claim support for armv6 in addition to armv7 Product: Base System Version: 13.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fuz@fuz.su If I read the value of the sysctl kern.supported_archs on an arm64 FreeBSD 13.0-RELEASE system, I get the output kern.supported_archs: aarch64 armv7 However, this list is incomplete. Clearly, the kernel is also capable of executing armv6 binaries. This unfortunately means that Poudriere refuses = to install an armv6 jail on the system, making it difficult for me to test arm= v6 ports. It seems like this is the consequence of unfortunate programming.=20 sys/kern/kern_mib.c defines the sysctl like such: --- #ifdef COMPAT_FREEBSD32 #define MACHINE_ARCHES MACHINE_ARCH " " MACHINE_ARCH32 #else #define MACHINE_ARCHES MACHINE_ARCH #endif #endif SYSCTL_STRING(_kern, OID_AUTO, supported_archs, CTLFLAG_RD | CTLFLAG_MPSAFE, MACHINE_ARCHES, 0, "Supported architectures for binaries"); --- so if COMPAT_FREEBSD32 is enabled, the kernel claims support for exactly one additional 32 bit architecture, which is clearly insufficient: (a) there ca= n be multiple supported 32 bit architectures and (b) support for 32 bit programs= may depend on processor features. For example, on arm64 not all cores support executing 32 bit binaries, but the way the sysctl is set up, the kernel just wrongly claims it can, probably failing only when execution is tried (I hav= e no such system to test this, but e.g. the Apple M1 chip is like this). This s= eems quite unexpected. Please fix the way kern.supported_archs is set up such that the list reflec= ts both armv6 and armv7 for arm64 cores and that only if the AArch32 execution state is supported at all. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon May 24 22:53:17 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 995839EA673 for ; Mon, 24 May 2021 22:53:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpsvB0RdDz4n3L for ; Mon, 24 May 2021 22:53:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621896804; bh=iFmhyjxOe8NIi+BAqcMFHPkU+DCGa7Mb6fAH7AH0b2g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EVQI9BifPFC6N1UgQWGjKGfyCMLotgGxNWyOHcNRBsrszksWMoi4Z1Qa4x7XZmMdTDfg7kWyxO5bGXwWycJ+0H9N1aF6qDyaqFulBFyJ2Bwku7M1HnvDRrV2WGOdcuNU0lY1XqgfFeIewVrJ836F/LqBfJvX9bggZWBXH9s5T0i7aVH1lwCau3NecRtpWw5ChzxbVs3CbKAyPKiriMkmm2ruroqk+44SA04r3NQOrk4IDs9fnpOiTOROBe9YyVa6htWjSwQ0XRhPCLB4TrUAa4RxW1VdxLUuiRc3ke+mKPCgIk0O50WhdEmdShE0ozfH5BNPRBff2MdNqIbwazqj9Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621896804; bh=TFM/xr2iGMOMdEERa6X1m3ZCNhCxorxubkjNhHx/+Wt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VoTrUqv0M3yezWW0f/n6oA5sxqX6vt1w6vKSzF72+IqwCoff6c1bElLzPb75aj/CK5dtI9iBjWS7yoWP4eDaGOPfz/xRzz4Swc4KD+Gw6lNZ071B7xeKQx5XOnXOfBurWH3kvGRVZM1o5ubhHJBcAig7N2+BcpVGpSCbtZabJie6arqykrju4C5du6pyf3v4DNesb4BrFOn4v/GL67GzRwvbHmOq2DhloUkdYLeNC3LSzNkOFngkC2Goz/S1+hv64wDCszr7CTy+MEo0K076cyakvoloCBJlgchAXhnBPn73FfP5q3+HFjwm+zNd0IC1a1o05qAWzlo7jGX73Eah8g== X-YMail-OSG: UEeMHV4VM1lU8HYC2Uww97vcV26SO3oSnLo5AoZLI2Fpy_OGg_9c9MJJXixZELG RPAEOLe3NFaAUMiRnJ96C_6zfy_8a0hXB_nwmsT42_YRm8u9V5CohMh2ufHgcqcOJgT3c2hqWP9g e5y5PFp4A3SEklQJEMWSQ.G2dh8iyLngXYUufV4VO7NzG9HC3K9E3_FG6ZGg6g6_SwHfAdkIyK2h TPWbYvykAP55i136qEtENDIlJuk.CJff8tDFVwZ6mi5PmqKUgL6ACz.iblkmd2gHs8fncs3X5l8f KKzhiAmdN0y_4SLtMdiR_FJw22slQ.Y93SSj_XpWG8r76Yiw7TXwNO_3zqXjDVB_p_YbW_N7js5R J_ZsyiKrtXbd7c1qSq8YFSaON2k.IHXsYPaJluIqvT6qM_eJO4zkQl0cr8a9V5vb5Gii2k7SzrFG wTXSCTWnqma1zaZdI5oDNYi57uPgjDqJDovof8_2ulwaoNt5P9ubvxRMxoE.ftZ_YWZwqanKxfFI GN9iO5pcIPGJ35eOXi8L99UoTeErLf8aNAZtxqFpJ7XldJthY2f9DM8rYLS3NDGBMqZASVcgaiYQ .ZKtKrgrDtxBfZG68l3k9HSK.tRc7fvDMYeVO8U4mEoC23zZJqH67GFEHDNm902BddhzmH.2Mhb1 wSeIW5DgUHUy7DOtI09nEXie79ZFFDTa7z1fJoJ9ZAw3w28NZ7gbYkOYxEZDcnj.TEeXAThNnNYq HIWUZyMEnlf6_4ZfqRSBufDXgVRmM9UbVGbnlbv2F_EYg7aXqeE_xMWDCgcgn1uHWIXpQihWhbuM anqFy94dukOoD.T1MhlK.4Ixz.jHKOt_eAVgvBxNT6MEdmY9IeQg94d3Vd.DoXy35K2__bHsQLsx BsXzAZ3rA7BcM59dZS8K2T9Fvi9ilYykuyyN9LYy7qOviCneM_6C62wY8l8ZDasWuZs2eT.cFOIX yMZrqRUocysDbuW7xKdzOBTd9xw7XogFJSu0o.TC_5mS91KLdxlMZU9eVYzXUgr09lnfs54Muy_5 .V7Lis0TVPOK3rb1L7uZLtmr9TwkXDAzx76afqMvvL8uE4kLitvZ4uwq2V83u.oMH7.l4E10q4hr CZEnli12RGU9GfCr8of9DavFvzpSdGAYa_Wt3q9MW_.qoeOV2QpHS85yNooSqf1_BtvE55KLsqwa ytSahckOeIj1GIcjktCEY7KcQTsptImoibS9VXjpmoCtmBFf3xKMq1i0rLgJfeIDBghUX_DcWYR4 GuiHnlIMsh6L_cdk01s30v8QB0h3vBh7_QRE4kcUv7F4nnOw2NrHsH6FrJzOTRjxPhyEpVXHlqOk F40iksa_nSGQiSXImkxya_ziuG46vvCvUSOWXYklGHd81E.mdSfdHP2rLML8I0njFZw9bID_ggi6 maH4ZbMFK05CoSmSwIZ9DXwnlT_JpttuFK5IWj.UWOeE28B6D5.2n9AZ44WVIHmVvLPohw8c70xp 0v4w9GmntACL_yBrYQo7XW_v9tPV8aLmRhurVdQzbF9sFoPYAiqFQCFUIyZbv3kV5YgH_KRFh.Y9 3kf5dz2Gsm7uQ940uYqNL86Hb.1umGBTZaIfEU1H0uZ.2pn71BgYhfPjDGZ9AQHVQGLLzbRx79Xs rWlTVqPAlZFz3jQpiZNGtRHgP93CFjXhAqphBCBaVpcfNgExqFPTJGTst0rHf6K9QAIcZ6Tdmx__ 41YNLxGEjUEdgNGckOaZTW5YCPVYTNEIcdCDVwVUck8EjD6F8RyzCxNhTr3d2zgViFKWTrMcEVEU V5nwkCi0NeEo6ZpN68uu79qo9DdL2Pe1wbSthU_zUN1kQeg5M9CyYwjUQ8iuXxDsyhy55cIJSXpt T7he1VksIZqqkNEIUScovdJSu1bhyJm3I9bHiYpy7fKlDWuzGCe1_W8c97pPa8FpiEG7JxWGy70O l7jK3Cgeo_VUWvAm.3Dp3fuvGUagefnDIeLoPhCQfk1DSCgL5rjBg.enFqEtCnWGB0GqlnKC4EQ8 3d_Hu2VBoJUPJJarlNDCwuv2WrpBytInOKPKCYNcYYOR0Zfrqe87ed7siCinsCPMtwJcN0cEKo8y f6TQu6Eky1ZS.sjuyxGhi.8koZ2pH31AKbiK2XL.zNmV8DeoSKo8hkYr1BMOcEgkKi.vuC4bR0cH rUyufArcie78IjmiyAjWZW0IZsluLk1FhO5VJi52qSeRB7aFHkZxlx7TXKaJF48eJ0Ay3tvCqsi8 E9Y0NHGoYUb4PXJJHt_E1jcnSQqEhf6Jzkd9FqcIVfjL5on2S4HiTgma9QankKedqUhTpwBBz8Y_ 9siwsQ0rMapkWLAt1Tga_0O0BogHVKrOAuDxjDXm_Ril1dH6HTN3wV8COXrq1ihjtczQOvGvMAnP 2bUeuCdxTrnz91lLtPEoPtO8DEUnD8jQOEApVtLb1K93nf7yGwMRDAgugEwCfz4yD06ilhCP8gcZ zEfpioEpEU1Hx.cpM2TJp1RSXEx2plFV0F6QGec4uHViCkt0oG4QfUcjco2bkx1yjdE7eHtzLyDu KE6vksX2BU_uuhdwJW9P8FJG9iYWP10PvvTXoOL2jKUO3paYaxodO6Nk_cs9KHukKgYO8qJJeTj2 cLN74J8u99au0M3aaN5UwwLE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 May 2021 22:53:24 +0000 Received: by kubenode544.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a66875723774167ce52b9820b94ba4ab; Mon, 24 May 2021 22:53:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" In-Reply-To: <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> Date: Mon, 24 May 2021 15:53:17 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FpsvB0RdDz4n3L X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EVQI9Bif; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.83:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard On 2021-May-13, at 12:03, Mark Millard wrote: > On 2021-May-13, at 10:53, Mark Millard wrote: >=20 >> On 2021-May-13, at 04:08, Mark Millard wrote: >>=20 >>> On 2021-May-13, at 03:40, Emmanuel Vadot = wrote: >>>>=20 >>>> On Thu, 13 May 2021 02:57:21 -0700 >>>> Mark Millard wrote: >>>>=20 >>>>>> On 2021-May-13, at 02:15, Emmanuel Vadot wrote: >>>>>>=20 >>>>>> On Thu, 13 May 2021 01:52:08 -0700 >>>>>> Mark Millard via freebsd-arm wrote: >>>>>>=20 >>>>>>> The updated armv7 U-Boot ports now install the likes of: >>>>>>>=20 >>>>>>> # ls -Tldt /usr/local/share/u-boot/u-boot-orangepi-plus-2e/* >>>>>>> -rw-r--r-- 1 root wheel 504 May 12 07:01:10 2021 = /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README >>>>>>> -rw-r--r-- 1 root wheel 66 May 12 07:01:10 2021 = /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata >>>>>>> -rw-r--r-- 1 root wheel 490924 May 12 07:01:10 2021 = /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin >>>>>>>=20 >>>>>>> # ls -Tldt /usr/local/share/u-boot/u-boot-rpi2/* >>>>>>> -rw-r--r-- 1 root wheel 767 May 12 06:39:07 2021 = /usr/local/share/u-boot/u-boot-rpi2/README >>>>>>> -rw-r--r-- 1 root wheel 44 May 12 06:39:07 2021 = /usr/local/share/u-boot/u-boot-rpi2/metadata >>>>>>> -rw-r--r-- 1 root wheel 475420 May 12 06:39:07 2021 = /usr/local/share/u-boot/u-boot-rpi2/u-boot.bin >>>>>>>=20 >>>>>>> So, for example, no boot.scr files ro go with ubldr.bin >>>>>>> any more. >>>>>>>=20 >>>>>>> But the u-boot-orangepi-plus-2e/README says . . . >>>>>>>=20 >>>>>>> QUOTE >>>>>>> This version is patched so that: >>>>>>> * API features are enabled. >>>>>>> * A boot.scr (U-Boot script) that loads ubldr.bin and execute it = is included >>>>>>> END QUOTE >>>>>>>=20 >>>>>>> The u-boot-rpi2/README says . . . >>>>>>>=20 >>>>>>> QUOTE >>>>>>> This version is patched so that: >>>>>>> * ELF and API features are enabled. >>>>>>> * The distroboot command knows how to load FreeBSD loader(8) >>>>>>> * By default, it loads ubldr.bin (PIE) from file ubldr.bin on = the FAT >>>>>>> partition to address ${kernel_addr_r}, and launches it. If = ubldr.bin is >>>>>>> not found, it falls back on ubldr >>>>>>> END QUOTE >>>>>>>=20 >>>>>>=20 >>>>>> Oups, I'll update the README, thanks for noticing this. >>>>>=20 >>>>> FYI: I only looked at examples for which I've access >>>>> to operational hardware. >>>>>=20 >>>>>>> But for the orangepi-plus-2e that I have access to I >>>>>>> now get: >>>>>>>=20 >>>>>>> . . . >>>>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>>>> Booting [/boot/kernel/kernel]... =20 >>>>>>> Using DTB provided by EFI at 0x47eea000. >>>>>>> Kernel entry at 0xb2e00200... >>>>>>> Kernel args: (null) >>>>>>=20 >>>>>> This is the symptoms when caches are not flushed. >>>>>> U-Boot distroboot first scans for extlinux.conf, then uboot = script and >>>>>> then EFI. So this probably means that you still have a boot.scr = on the >>>>>> ESP, try removing that and make sure that you have the efi loader = too >>>>>> in efi/boot/bootarm.efi. >>>>>=20 >>>>> That is not the issue . . . showing more context >>>>> from the same recorded boot attempts (blank lines >>>>> and a huge number of escape sequences removed, and >>>>> using ". . ." for other omitted text): >>>>>=20 >>>>> U-Boot 2021.04 (Apr 09 2021 - 19:24:51 +0000) Allwinner Technology >>>>> CPU: Allwinner H3 (SUN8I 1680) >>>>> Model: Xunlong Orange Pi Plus 2E >>>>> DRAM: 2 GiB >>>>> . . . >>>>> =08FreeBSD/arm EFI loader, Revision 1.1 >>>>> Command line arguments: l >>>>> Image base: 0xb8dd5000 >>>>> EFI version: 2.80 >>>>> EFI Firmware: Das U-Boot (rev 8225.1024) >>>>> Console: comconsole (0) >>>>> Load Path: /efi\boot\bootarm.efi >>>>> . . . >>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>> 1396100 bytes read in 36 ms (37 MiB/s) >>>>> Booting /efi\boot\bootarm.efi >>>>> Consoles: EFI console =20 >>>>> |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08|=08= /=08-=08\=08|=08/=08-=08\=08|=08/=08-=08\=08 Reading loader env vars = from /efi/freebsd/loader.env >>>>> . . . >>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>> Booting [/boot/kernel/kernel]... =20 >>>>> Using DTB provided by EFI at 0x47eea000. >>>>> Kernel entry at 0xb2e00200... >>>>> Kernel args: (null) >>>>=20 >>>> I cannot reproduce this here. Either by creating an image on the >>>> sdcard by hand (I usually only netboot my boards so the sdcard have >>>> only u-boot and a fat partition so u-boot can save its env) or by >>>> taking FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img and adding >>>> u-boot on it. >>>> This was tested on an orangepi-one board (so same SoC, Allwinner = H3) >>>> and on a BeagleBoneBlack. >>>> I suggest to try with a clean install from >>>> FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img just to be sure. >>>=20 >>> In my context: >>>=20 >>> The RPi2 v1.1 has a microsd card with just bootcode.bin . >>> The rest is from the USB3 SSD media. (Such worked before >>> the U-Boot update, for example.) >>>=20 >>> The orangepi-plus-2e has a microsd card with just its >>> (now updated) U-Boot and empty file systems. The rest >>> is from the USB3 SSD media. >>>=20 >>> It is the same USB3 SSD boot media used for both. >>>=20 >>> It is the same media I've been using right along, >>> just updated to remove the old U-Boot related >>> extra materials and to copy over the new U-Boot >>> for the RPi2 V1.1. >>>=20 >>> The media has a non-debug head [so: 14] build, based >>> on: >>>=20 >>> merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 >>> merge-base: CommitDate: 2021-03-12 20:29:42 +0000 >>> 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run = all XPT_ASYNC ccbs in a dedicated thread >>> n245444 (--first-parent --count for merge-base) >>>=20 >>> It has been working the whole time since then until >>> this change. It is a build with code generation >>> tuned for cortex-A7, as is my normal for my own >>> builds for armv7. >>>=20 >>> I need to get some sleep. So it will be some time >>> before I try any other forms of experiments. >>=20 >> Mixed results for starting with a modified >> FreeBSD-13.0-RELEASE-arm-armv7-GENERICSD.img microsd >> card: >>=20 >> orangepi-plus-2e booted from the microsd card. >=20 > I took the microsd card and put it in a USB media > reader and plugged it into the USB port and used the=20 > microsd card with only U-Boot on it in the microsd > card slot. So, in essence, a test of USB booting > from as close to the same media content as I can > get. >=20 > It failed in the same way as I previously reported > for the orangepi-plus-2e (which was also a form of > USB booting --but with my historical USB SSD media > that has a main [so: 14] non-debug build). >=20 > The only software that I had built was the U-Boots > themselves that I either dd'd or cp'd as appropriate. > EFI/BOOT/* was unchanged, as was FreeBSD's kernel > and world. >=20 > Somehow the type of the device matters (despite the > kernel being loaded from the device without > complaints). Apparently the RPi2 v1.1 microsd card > is a problematical type of device, like USB is for > the orangepi-plus-2e. A definite regression overall. >=20 >> rpi2 v1.1 failed the same way as before, including: >>=20 >> Found EFI removable media binary efi/boot/bootarm.efi >> 1403700 bytes read in 139 ms (9.6 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> Booting /efi\boot\bootarm.efi >> Consoles: EFI console =20 >>=20 >> FYI, FreeBSD-13.0-RELEASE-arm64-aarch64-ROCK64.img includes >> ubldr.bin : >>=20 >> # ls -Tld /mnt/* >> drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:26 2021 /mnt/EFI >> -rwxr-xr-x 1 root wheel 103488 Apr 8 20:59:46 2021 /mnt/MLO >> -rwxr-xr-x 1 root wheel 26745 Mar 3 05:29:56 2021 = /mnt/bcm2709-rpi-2-b.dtb >> -rwxr-xr-x 1 root wheel 52456 Mar 3 05:29:56 2021 = /mnt/bootcode.bin >> -rwxr-xr-x 1 root wheel 89 Apr 8 21:10:14 2021 = /mnt/config.txt >> drwxr-xr-x 1 root wheel 8192 Apr 9 00:05:26 2021 /mnt/dtb >> -rwxr-xr-x 1 root wheel 7314 Mar 3 05:29:56 2021 = /mnt/fixup.dat >> -rwxr-xr-x 1 root wheel 3187 Mar 3 05:29:56 2021 = /mnt/fixup_cd.dat >> -rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 = /mnt/fixup_db.dat >> -rwxr-xr-x 1 root wheel 10298 Mar 3 05:29:56 2021 = /mnt/fixup_x.dat >> drwxr-xr-x 1 root wheel 4096 Apr 9 00:05:32 2021 /mnt/overlays >> -rwxr-xr-x 1 root wheel 2952960 Mar 3 05:29:56 2021 = /mnt/start.elf >> -rwxr-xr-x 1 root wheel 793116 Mar 3 05:29:56 2021 = /mnt/start_cd.elf >> -rwxr-xr-x 1 root wheel 4794472 Mar 3 05:29:56 2021 = /mnt/start_db.elf >> -rwxr-xr-x 1 root wheel 3704808 Mar 3 05:29:56 2021 = /mnt/start_x.elf >> -rwxr-xr-x 1 root wheel 467824 Apr 8 21:09:28 2021 = /mnt/u-boot.bin >> -rwxr-xr-x 1 root wheel 716804 Apr 8 20:59:46 2021 = /mnt/u-boot.img >> -r-xr-xr-x 1 root wheel 462412 Apr 9 00:00:00 2021 = /mnt/ubldr.bin >>=20 >> so I removed that and u-boot.img, and replaced u-boot.bin . >>=20 >>>>> and: >>>>>=20 >>>>> U-Boot 2021.04 (May 12 2021 - 13:36:42 +0000) >>>>> DRAM: 948 MiB >>>>> RPI 2 Model B (0xa21041) >>>>> . . . >>>>> =08FreeBSD/arm EFI loader, Revision 1.1 >>>>> Command line arguments: l >>>>> Image base: 0x39df8000 >>>>> EFI version: 2.80 >>>>> EFI Firmware: Das U-Boot (rev 8225.1024) >>>>> Console: comconsole (0) >>>>> Load Path: /efi\boot\bootarm.efi >>>>> . . . >>>>> Found EFI removable media binary efi/boot/bootarm.efi >>>>> 1396100 bytes read in 38 ms (35 MiB/s) >>>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>>>=20 >>>> This line doesn't looks good. >>>=20 >>> Yea, I noticed it but have done no investigation >>> as yet. (Only the RPi2 v1.1 that message. It is >>> the one notable difference.) >>>=20 >>>>> Booting /efi\boot\bootarm.efi >>>>> Consoles: EFI console =20 >>>>> |=08/=08-=08\=08|=08/=08-=08\=08|=08/=08 Reading loader env = vars from /efi/freebsd/loader.env >>>>> . . . >>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>> Booting [/boot/kernel/kernel]... =20 >>>>> Using DTB provided by EFI at 0x7ef6000. >>>>> Kernel entry at 0x33e00200... >>>>> Kernel args: (null) >>>>>=20 >>>>> No *.scr files, no ubldr* files. Showing >>>>> from the efi partition mounted on a Rock64: >>>>>=20 >>>>> # find /mnt/dtb/ -print >>>>> /mnt/dtb/ >>>>> /mnt/dtb/sun8i-h3-orangepi-plus2e.dtb >>>>> /mnt/dtb/overlays >>>>> /mnt/dtb/overlays/sun8i-h3-i2c0.dtbo >>>>> /mnt/dtb/overlays/spigen-rpi2.dtbo >>>>>=20 >>>>> # find /mnt/efi/ -print >>>>> /mnt/efi/ >>>>> /mnt/efi/boot >>>>> /mnt/efi/boot/bootarm.efi >>>>>=20 >>>>> # ls -Tld /mnt/u* >>>>> -rwxr-xr-x 1 root wheel 475420 May 12 06:39:06 2021 = /mnt/u-boot.bin >>>>>=20 >>>>> # ls -Tld /mnt/*.scr >>>>> ls: /mnt/*.scr: Invalid argument >>>>>=20 >>>>> I'll not list the files from the RPi* firmware. >>>>>=20 >>>>>=20 >>>>>>> and that is the last of the output. >>>>>>>=20 >>>>>>> The RPi2 v1.1 is similar: >>>>>>>=20 >>>>>>> Hit [Enter] to boot immediately, or any other key for command = prompt. >>>>>>> Booting [/boot/kernel/kernel]... =20 >>>>>>> Using DTB provided by EFI at 0x7ef6000. >>>>>>> Kernel entry at 0x33e00200... >>>>>>> Kernel args: (null) >>>>>>>=20 >>>>>>> and that is the last of the output. >>>>=20 I do not know if the FreeBSD kernel has been depending on some U-Boot initialization for root-on-USB and the two no longer match or what. But I've used a release/13.0.0.0 microsd card based boot to get older U-Boot materials (Quarterly as it turns out). Installing such got me back to having a root-on-USB boot of the OPi+2e (other than the mircosd card having the older U-Boot (2020.10 as it turns out). Of course there is also the matching boot.scr involved --but it also is on the USB SSD. (Similarly reverted RPi2 U-Boot, other than needing to switch boot.scr to match.) After booting with the reverted U-Boot related material: # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt # mount -onoatime /dev/mmcsd1s2a /media # ls -Tla /mnt/ total 20 drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. # ls -Tla /media/ total 60 drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin The media is also set up for booting an RPi2 via root-in-USB ( other than bootcode.bin ). If FreeBSD and the more modern U-Boot were well matched for USB support, I'd expect that this sort of thing would work (no boot.scr needed). For reference: # ~/fbsd-based-on-what-freebsd-main.sh=20 FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in = git context. merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 merge-base: CommitDate: 2021-03-12 20:29:42 +0000 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all = XPT_ASYNC ccbs in a dedicated thread n245444 (--first-parent --count for merge-base) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue May 25 03:10:50 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB24F9FBCEF for ; Tue, 25 May 2021 03:10:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FpzcL3KJ1z3h5P for ; Tue, 25 May 2021 03:10:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621912256; bh=AtNrGnzGGH8yAHW8MZbIwufkMYut/347284b6WKr6ec=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JTeqj6i9ylXl3bVG1QRt7mqSlTWCRjEJ8A7OQXAlEknXLboR1SXLhitgPNlUhVeiVD8A5Lm05TE8sPayeDBaGMzr19fQQm/wfJpE475zomh8uGyVUUvy90hYPbnnb76WZNnSk87wuN/6W9maqfOI+68mGyiYi2yOFPr3FxyAB95fI33P+adRON0qXUYHjKiS2OJMUnU6zAvkyTjK6Ej6Fj+WMsMefl8yCaazRdDejOS4MyjS1VB4pn0uMe8vu7EWAPnHVOXdpyvdbqS5HRfxCiILz0feTlBd4s/NodWnFkZfFJf0U/D4Im0n3OLbczvz6l8zoo0ZPtQdU9k3CiUXQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1621912256; bh=PE4aZw8ouPLStMawuJf2JlMRpFH7qEhSLlrGeaqUkQ/=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=SjuqrcSBSmafIyWjylkQ5AGVXaymNkSTTlh3JEgBSrKNrlWX/f2rZ01rW0TRkHruN19xUawyI7gvnqQjOzz+Ps8b++DaZVvMJw1uToTNwjdozlgIZ+tpixiIKs9IDkHf2upWPpxnde2ELgHk0Udb3XZSF6D0FHZVLLxkFswdh8t85X8llNiFE9mRrOwroh2ScOOw3jUOHAscByfiU7KLC31KIVbSNC/y3PmKd0KgGG/rlCu206zkMyvqsu4zgzU3gsmXwjkHACaeTr5hPEFUrr7P7kjwQ6GoOdsc3tWCliXhA1KCvjvpX3Xi//Q0JPLz7q/6EvHq2fsEa8auhs8J9g== X-YMail-OSG: 79HUDfgVM1k3iSkrtFHh3tPutD2Hpub4C2_ttSgOEbma30FEL.yIh6IKUOmspIf bBAwWdWhZu_rzyMnbPgbnIpMkoKNCXgv1wMa.Squm07NeMO.SUzJLvPS4FFP.B4pqZ925Sd7z2os w.fogrHe7jj.1LQTFY2ICDDWXBoaFQ7AfzbKYXMsSTcAyTiO6WseYN3dmzVdyxMbiNC7tZDO7vGO UW8KZxA_LvY2JB7eV9Us2b2TRUthbAFsaJolfRcTeOeF3oVzb1nOX9TbseJBYI9AHWRxjH7vJjvJ mTt6H7vQmi78suJnVPkS46Gh8yJTYatmLIGeFdIMScdA6l6E4QihZZa.kg.FCGs.l8PHp9gy80GT waCVxKJOMdxlJ1kOwih7DO38XdKy0zmbUxFSLSWFKhVpMz1nVk2B27mCk8kWKPl5J2Lt5jIuulQA ePWGtW9S_GnJElgnnwTmqobV0tNilguj6bAcpsN_q1RMEFmwXUt8lUCAmb6JVVWkVt3JWSJPozx7 J3gwLvO.npHZoWA06P4JQMTmKzCLFS.52gWDAwHaYlYyEIrTayz1gUJ4MbR8xre79roHZjZRtAkq TGyY8nVc7jA9m178s3PRZ_jq6xlwH7aIngWaoX37mab8EqqL369rJ_rVxFMTfhPj3XXozeyeTsaj fSIxScHuAwHRwQkt9sWo74OOugc6cFRZdUEfq7eqy1O.LKPw5WgfxZJXnQrqnkMdM9VNIGvIDhz6 wuz.GZ9FZjIsq.oGzMLFKDnRvIPuMeVoWgM5v_cG3Gyv1di8Hh1Dd83aF3PdUf9SIJaGuddBo9xB YrDdqf71xQNzY8uUhA3p1RRKe9piBiSpfJrmgw8kLNrDTxOfPzhWIw.T6E9ekAKa1kEbkw_.Er76 UGFPIBjddGEuEQXOqhM5OA65fTkiOHpYrJ5RNLu.x2OayS9uGIUKU77q62kj0rUZyfJFqxlK1VnP YKGURB0Olzb3NuyfQjguz9fo1v_vciwYdPsXN9ZfzgxUjL0k_w2ePTxy6krPJgxZQbJoLnJrZ71y Z_JfDOTGXPaNJQjDxBxg8cf8biYiapVDMRgvtLTokuP1pGXpEhbWJ156fm4Lvw4q4DMW_8Md7jGY dPmxh6G3sfJcZ_nt3_nzUDWxgAZ8GE9m2geu2QJJBzjdojlhrz_n6LbAGkLoDcWXsJr2y1SXwa4c DX_b2LkZ9AHLakR1_w2SfOgR62oZf_qX5ExIus8Zy9E5vm.12F_zvoVKam5jXYUOAc9XetNObp5u u5JcEyEiUzSRkQP5GiSf8hMg_ye.c2B3J4nYj_oUE4D.xqAX3ghDRsPbsE08iFFIRzMa1OewslJJ 3yPDXsnmd0dy0pubI5Yp898TcJLLY1DZR0FjyslbGU3wf8YhJBzrveYns2SxW8n46ixzHce7Xpbl 7gRYmzAHINGM1Sqle5NAzbuGelIQ04eNfDWRvAIjsE.lZOkF5xF76ZTb1tAsiaHp2GTQuxLUBZOj h6dp9vGHyBtjjQBuXIKP6y.fGwmN90ySGHGsisEvrDnrOb0piPyJTAldPaRU35h2tuKIbJw6Dw8A YZNPdwlu3.DfT3NxA19vmZIazUizTQEH3f2dtKJRv7dQ42TBL08lLi9_VCKFrp4qqPVF_Op1YOdV polKt_AQBY6wf.irNAqGQIXSJHTKpRcVzChbPeLzhyxP.xg7xrPb1RxvaQ2I6tNq..15h.hRLC98 LUp0viMwzZeJgFUuvZZnV03BXPyHBOthdB..8WEWQRDeWlDgRXRymVVt6VY3qEx4Z7vbq0FE_3AO WXIEA6uk9qaW1LtoWoOryqtPhdhwHYzfSwJ1jFxNDbq1nGd1cVjwGJohb579PvUgJuD1fNM2rUsZ SD0VVQuXnT0XXp_TUJ0eJNXz38C.HIgtaYuwvjD_mAjBEv9bK3urLJp2uMazZn4XJuE909Sq8UIf FaWo5wuzIEoGxAcjAIxwtQbVns9M2qG5d6VKGmfXAHQ3Bj5YU_eZkG_ZksvL9P7AzkosN55ZLYwl Svn9ij86GCitP_SS9BJVZnurNU5v.PafpFKUYKof97Oe1UZJtPd6gmZlZeeZQRFnwAiEENN1VGAy BPLkogpUg7A5GKADW1VoURphxcKocrCdSYYuNnKUgiBmkFaY9zWyT_2r9ldlxZmiJAQlJJv0IOc2 _cKfYtIftivc1ydhgFwNlfmhN80oVNwZ58Vjj5hzPp1UmHxl8SsaJwz_IPR2jlkr0nmTnymcemGI dRGi67uDn2dqhzE5H9ItB2C1tHLxZmKABEJSrjTWvgud7U7qflvPo0UBHUjqZqg_Gyi36dhZN9ew KwLwPYoYOUhoBfZVmnzT4xLCImRkqbNtG0ehQJj8WK.UV9bzx0jwRbnKPsCRfW7eFub_uvHUulm_ JV5jS2WDNwuQkekS4gWnC00OsbBRqSzTh9_KtQ57e9pBxRbC79z518VEfowV0VJGEuTtp7DEy_uV nFd1FgsBI1q0VcFV9BhedFHjzl.sSnRsaihDczfg3r0etgfodIzfq.bSoIopVQcUDXoBt_eq4K0H 5BRgngP.QweARCEYFQ2hLp7JCagKGb.rzbW2VaI.qeTWQrYTrOIxGtyVmqPgGzNoHz0Srj83Bvj7 5Eklv4gY0rtZlkRJzWbt8Wo0uB5_CeuzxS8ZlKm6iI6TZZfcKAGEwiVbo5K0K.R_TmKkbQp57dWE - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 May 2021 03:10:56 +0000 Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID afeed6f7f1b2c1282ce77e9a91f0030d; Tue, 25 May 2021 03:10:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README out of date ; orangepi-plus-2e and RPi2 v1.1 get "Kernel args: (null)" In-Reply-To: <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> Date: Mon, 24 May 2021 20:10:50 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0482F239-B137-42F5-8802-8883D08D5868@yahoo.com> References: <40298C05-5F50-4437-B15B-7A02EA070EAE.ref@yahoo.com> <40298C05-5F50-4437-B15B-7A02EA070EAE@yahoo.com> <20210513111517.86336633bae9568d8599f229@bidouilliste.com> <20210513124050.47714a83f876d67a80e28080@bidouilliste.com> <3C04FB55-4A26-48C8-833F-E4AC84DC4F78@yahoo.com> <99906599-273E-4216-A41E-DE642F33E392@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FpzcL3KJ1z3h5P X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JTeqj6i9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [0.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[98.137.64.204:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.997]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[arm] Reply-To: marklmi@yahoo.com From: Mark Millard via arm X-Original-From: Mark Millard On 2021-May-24, at 15:53, Mark Millard wrote: > On 2021-May-13, at 12:03, Mark Millard wrote: >=20 >>>>> . . . >=20 > I do not know if the FreeBSD kernel has been depending > on some U-Boot initialization for root-on-USB and the > two no longer match or what. >=20 > But I've used a release/13.0.0.0 microsd card based > boot to get older U-Boot materials (Quarterly as it > turns out). Installing such got me back to having a > root-on-USB boot of the OPi+2e (other than the > mircosd card having the older U-Boot (2020.10 as it > turns out). Of course there is also the matching > boot.scr involved --but it also is on the USB SSD. > (Similarly reverted RPi2 U-Boot, other than needing > to switch boot.scr to match.) >=20 > After booting with the reverted U-Boot related > material: >=20 > # mount -onoatime -tmsdosfs /dev/mmcsd1s1 /mnt > # mount -onoatime /dev/mmcsd1s2a /media >=20 > # ls -Tla /mnt/ > total 20 > drwxr-xr-x 1 root wheel 16384 Dec 31 16:00:00 1979 . > drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. >=20 > # ls -Tla /media/ > total 60 > drwxr-xr-x 2 root wheel 512 May 24 15:43:19 2021 . > drwxr-xr-x 25 root wheel 512 Dec 31 16:00:40 2009 .. > -rwxr-xr-x 1 root wheel 52456 Apr 24 19:48:36 2021 bootcode.bin >=20 > The media is also set up for booting an RPi2 via > root-in-USB ( other than bootcode.bin ). >=20 > If FreeBSD and the more modern U-Boot were well matched > for USB support, I'd expect that this sort of thing would > work (no boot.scr needed). >=20 > For reference: >=20 > # ~/fbsd-based-on-what-freebsd-main.sh=20 > FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT = mm-src-n245445-def0058cc690 GENERIC-NODBG arm armv7 1400005 1400005 > def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build = in git context. > merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2 > merge-base: CommitDate: 2021-03-12 20:29:42 +0000 > 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all = XPT_ASYNC ccbs in a dedicated thread > n245444 (--first-parent --count for merge-base) Looks like 2021.04 (even before 2021.04_1) also has the problem for root-on-USB handling. I managed to find a 2021-Apr-09 u-boot-orangepi-plus-2e directory copy that was 2021.04 (and its boot.scr) but before the UEFI change. When I tried it for the root-on-USB context I still got the hangup after "Kernel args: (null)" in: . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x47eea000. Kernel entry at 0xb2e00200... Kernel args: (null) So it does not appear to be the UEFI change so much as 2021.04 in general for which the FreeBSD kernel and the U-Boot are apparently(?) mismatched for root-on-USB. Reverting again to 2020.10 U-Boot got back the root-on-USB status. For this the boot looks like: . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x47ef5000. Kernel entry at 0xb2e00200... Kernel args: (null) ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2021 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 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG arm FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Wed May 26 01:08:16 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 82FDFBF39D4 for ; Wed, 26 May 2021 01:08:20 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (1.212.52.36.ap.yournet.ne.jp [36.52.212.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp", Issuer "smtp" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FqXrM3ptnz3FLT for ; Wed, 26 May 2021 01:08:18 +0000 (UTC) (envelope-from kiri@truefc.org) Received: from kx.truefc.org (kx.truefc.org [36.52.212.1]) by kx.truefc.org (8.16.1/8.16.1) with ESMTP id 14Q18Gib000084; Wed, 26 May 2021 10:08:16 +0900 (JST) (envelope-from kiri@kx.truefc.org) Message-Id: <202105260108.14Q18Gib000084@kx.truefc.org> Date: Wed, 26 May 2021 10:08:16 +0900 From: KIRIYAMA Kazuhiko To: freebsd-arm Cc: kiri@truefc.org Subject: Could not boot with u-boot Levono Chroebook S330 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 MULE XEmacs/21.4 (patch 24) (Standard C) (amd64--freebsd) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4FqXrM3ptnz3FLT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kiri@truefc.org designates 36.52.212.1 as permitted sender) smtp.mailfrom=kiri@truefc.org X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[36.52.212.1:from]; FREEFALL_USER(0.00)[kiri]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:36.52.212.0/29:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[truefc.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[36.52.212.1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ONE(0.00)[1]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10013, ipnet:36.52.208.0/21, country:JP]; MAILMAN_DEST(0.00)[freebsd-arm]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N Hi, all I'm trying to boot Levono Chroebook S330 [1]. I've made FreeBSD USB image in accordance with [2] as follows : # gpart destroy -F /dev/da0 da0 destroyed # gpart create -s GPT da0 da0 created # gpart add -b 1m -s 15m -t \!fe3a2a5d-4f32-41a7-b725-accc3285a309 da0 da0p1 added # gpart add -b 17m -s 15m -t \!fe3a2a5d-4f32-41a7-b725-accc3285a309 da0 da0p2 added # gpart add -t freebsd-ufs da0 da0p3 added # dd if=nv_uboot-snow-simplefb.kpart of=/dev/da0p1 bs=1m 0+1 records in 0+1 records out 696320 bytes transferred in 0.297577 secs (2339966 bytes/sec) # newfs_msdos /dev/da0p2 /dev/da0p2: 30656 sectors in 3832 FAT12 clusters (4096 bytes/cluster) BytesPerSec=512 SecPerClust=8 ResSectors=1 FATs=2 RootDirEnts=512 Sectors=30720 Media=0xf0 FATsecs=12 SecPerTrack=63 Heads=255 HiddenSecs=0 # mdconfig -a -t vnode -f FreeBSD-14.0-CURRENT-arm64-aarch64-20210429-daa5350d0e0c-258262-memstick.img md0 # gpart show md0 => 3 1646232 md0 GPT (804M) 3 66584 1 efi (33M) 66587 1579648 2 freebsd-ufs (771M) # mount /dev/md0p2 /mnt # mount_msdosfs /dev/da0p2 /mnt1 # cp /mnt/boot/kernel/kernel.bin /mnt1 # umount /mnt1 # newfs -U /dev/da0p3 /dev/da0p3: 1880.0MB (3850200 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 470.00MB, 15040 blks, 60160 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 962752, 1925312, 2887872 # mount /dev/da0p3 /mnt1 # tar -cf - -C /mnt . | tar -xf - -C /mnt1 # umount /mnt # umount /mnt1 # mdconfig -d -u md0 # gpart show da0 => 40 7864240 da0 GPT (3.8G) 40 2008 - free - (1.0M) 2048 30720 1 chromeos-kernel (15M) 32768 2048 - free - (1.0M) 34816 30720 2 chromeos-kernel (15M) 65536 7798744 3 freebsd-ufs (3.7G) # and then mark the FreeBSD USB device bootable : # cgpt add -P 12 -T 5 -S 1 -i 1 /dev/sda # reboot confirmed partition 1 attributes changed to : # cgpt show /dev/sda ... Attr: priority=12 tries=5 successful=1 ... # shutdown -P now and insert USB device and power the machine on and press CTRL+U at the "OS verification is OFF" screen, but screen blackout and nothing has happened ;-( How the machine go forth to boot with u-boot ? Best regards [1] https://www.lenovo.com/jp/ja/kakaku/notebooks/lenovo/lenovo-n-series/Lenovo-Chromebook-S330/p/88LGCS31095?vc_lpp=MSY5ZWQ2NGNhNzc2JjYwYTIxZTdhJmRhJjYwZjEzODc5JllLSWVlUUFISUNja05OUUJ3S2hwQ2NDb2FTZTZodyY0CVlLSWVlUUFISUNja05OUUJ3S2hwQ2NDb2FTZTZodwkwODc4ODc5MDgwMDIwOTYwNjAyMTA1MTcwNzQyNDkJCQk&cid=jp%3Aaffiliate%3Ag2ospo [2] https://wiki.freebsd.org/action/show/arm/Chromebook?action=show&redirect=FreeBSD%2Farm%2FChromebook --- Kazuhiko Kiriyama From nobody Wed May 26 21:10:41 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 44888CFAC02 for ; Wed, 26 May 2021 21:10:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fr3Wj61vBz4mBp for ; Wed, 26 May 2021 21:10:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8BBB518082 for ; Wed, 26 May 2021 21:10:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14QLAf6r040096 for ; Wed, 26 May 2021 21:10:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14QLAfcY040095 for freebsd-arm@FreeBSD.org; Wed, 26 May 2021 21:10:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 244276] espressobin: kernel panic in 'geli attach' using AES-CBC and 'armv8crypto.ko' Date: Wed, 26 May 2021 21:10:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: crash, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244276 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org Resolution|--- |FIXED Status|Open |Closed --- Comment #3 from John Baldwin --- This was fixed in commit c03414326909ed7a740be3ba63fbbef01fe513a8. Note th= at this fix is only in 13 and is not likely to be merged to 12. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed May 26 22:42:40 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4F7A9CFFCD4 for ; Wed, 26 May 2021 22:42:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fr5Yz48ryz4vZT for ; Wed, 26 May 2021 22:42:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622068965; bh=8SJEblJwyDDIlBL5JBMzXgL2ZbcBJomvj9dP7OtqNyA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gbdM42NdHdOCSgZkA4G+XxmzCopB9AIooQP1ZXrtqO6iOhLvOJSy0rD0FxFiSEhCTz+DtkR0aFGiEEpuecKfXahM3i+Q/78mepmYQu1M68jAfOi+5kun0BV1eOC9H2fIMgq8lfuubJZIFAZSEGajSALoqPYuQ6VHbRQO47L4XMg5F5W1/lehz1v8z4vSaR88/WXzaknc6LZZIDatG2sBrLwRj07VJwyc2YsYaIv8F1vaCAa8/oN9vYv/4RKkL52cIUZazxJsUQZw1ONmIiegF6P8JoZew2pbClc557PMLpyTvPIJ9UPVjlfOnxNZcJkqmll/SAFAo9lR1qB3ecTkjg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622068965; bh=Ene4C4+c+/SPww+KG1IiynCjGWwt3ugWISwRssnjxCz=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oc2NOeWHe4xUKPhDMBu7KSIuPfl6M3WrWP8CGrsrIq1f4Zjmol5eXhXrvRm4K9RK6H6fEMxUGEMBXOwdJhtKSDAFIoI5mc6hsqTSE/Qtwgc49XxxijZdl5opWTOK0wTv1y3YMgNh4LUsp+9HcxVfySTWGwnG48ou4D6oRokTAiKxodVaPDSXGRUOvoPqceO8mawzcuL5oJ+VLBBRLDak+mAVNYCtKcZeSCb15k0z1c5s+ospzMXWJup+y8xLYFEiI/qhvF2FKEYXxMD3F4ZK/ZCPd2H6Ny1Z9Zq5WM83tWj1CZJ/oIk6RjfzVhXdlhcX7fqVahV2CtfwfTto24jpOA== X-YMail-OSG: ca_XpLQVM1msSwR4c_wra8BoBLpt06xKKadz8t3iziwlqXizg2xSmjYHsgwTEpl NVX.f_sxAK_vW0rBsgLTlzL79EPSO3pArD691GFfToHnULCuWGrx38gwgzKP9RLKaJOmBQFWYy6W 0AnpQwB6HBWWG0yIz1i6dA5O_fXB1yJcR72BqaBMS6u_seIaBotXPmu.16yWeBe8DqiBp3NucD9g SJklZ_4D0Ow46a0wEDuzb3tOYHIySCIFl6OjI4oN.cMTuUcaiZLfVqKGq80lfx_cvmjqU6.PgaxY 4hx9eLdb69pBQz0oKxTdpvUuxgA7wgemk8OTlIf8TeMtNwHCfga3yqhXTweZ2x2VpPl.w41u_hNq S2ugHTvnlAcPn.Kq14Mtqzd7nRaFeW86dVWImy95cRHfSeLszPdsDq9gt2iVERIcice.7a8.GMw7 ZTtrcM7OkBazO8QIGTPOwbOCYotUsgFGmqLeGBFLZVw5C_Zcci9T.7DBl8b25y2yBsQb8do0LLzU bdcC.grmIN3FTX3vodOSs.bg5tRnOu6gqfvvK9ZhdKNHhBr__0MNhxFo4eVi1ikSfLci4c624PMU 8Sf0afAB5nV6s4LQnZAWBUbDZ4nNPDKBPDVjEsObd9ZV1n9zeDbuWcevIxtqEnx97kvUQVBQe_4q KbgxpMZkrQ8HeOjXyPUnR4._mlqfYzX4ymh7As.HFB7tQoNHHy6c3gUq8IvQxfgr0hyK9dvs56w3 NRq6uJGqpjhjHkITEAsWpIHteYihH_FQkrO3BFDTVbcNcUGinWvNpKxU9lfGgtwJgmTDK_wqmScC 3Z6W_QVezhqtfLBz9AMtD1L3xaFOSwT_aAMLXco2jkNkoviDmmS3u0kgR3jjkHOKQ57l2MXJr4iy L9n3SF.NafYL2xCyGfbarTsfIUfOCLamYghXtPWDRDdeokD_w3hj8dsXhi6unGM6_quEgeClT0bk LKiDyfJNy6..4FF5xvcbbzgQv_mGWhynq.CZcu.W_v9TagzFgNzLDEP0GU0gbp3V0TJ_tlvMNMny wsyB9dvuB9LupUK9hmD9Jh7p7OrQbj7cBbr1P_XSlNcH60lXyIVDXuLhD3iVg8cIyM1Sx4tJTWdn T8Y67n6tR7a24keW5P6jXKBs3SMru9AnBVhPGnAp89nHnx5nWX8BnQc5AhLKtCQ3Ncn5QTgsDsSo 5Fu3uPg4XtDrehgj.l65js_NHfw40YB5qJaVrQW6kEdQCTGU2MYs_9rIgAt22z2sqHxVIGzWwILI gdvJfZVOzKSfNDtnbr0obOLhbUkbx2q2PIePg_VJHeuRwWv1TPWS1qcxhErL0yPJqpqHD7txYjDl PiX3JKneOROwc7lFoXFou7jlNT77SvtUAp_rrp9AKJuTzdp_Bat7pQFq2TREe21hzM1KEj5MTIZL qDAEaKtMytQ6hbQPSGN9U9ccnx2ke5slfndnh6ZDXvGEfno1gYqs2Z30EgYXDHjv6Ghfa9B3HU9t gScDXx53PLP8WwpGz0EwZIimG6aibKS2DEZVBF4eP0AXHGpM7F2fGMDKUSv10AJj07a4ul3SZJzN zDWh6MZEQeyz85BDaHQUM5KpnOasnZyGJbhlueNezBN3D7QSGQdds_EivXyHLubExBdifk_PbS5d iagLvVoOweQFctsprCtNNp6fyZbFB7tyum4jIKtLqIUcXyHekM1vo2ndh6Zx6s0EYYgJnMckpmsM j8hYev_q_yspkHmXe1Ap9McX95fHxaV12AxB0KbLORg_pLq6ITuJZQX3pPifKLuO2sPhXZhhUhHf ebjChVBjCGLEg3MmbpDLhDe.H8LU9aEla_YSfE9b4_cZ6KwyrBSS98MMTEjCrFD7_DDaixtzomuJ Om.oMmiU4Wpo2K2WtMlLI_OP8eQYuWfwru9KaOCr4k2vhy0TlkoMpfyxSTozKZPoWZ49jPCSLBur VeE66kvlXcIUAUxapfOecTDUb7b7q22VYQYTqPBm0.VEXt8IfiExoPWbj9LAsS7PplNoan5i03j0 wAXpkdkahKXf_OZr75ad_3P8.Vnzx_9.mDxw0S5Q9qIawVVmGxtJ2ziRyt8M3m2KEdxSP9MxFpUt YfX7ke7MXTx.WkAUCT81rLg1RySp3EXfXPGFYVcsNh.TRynHYXY3SJ6YKjLAGMPpSk1g.pJ4uHmX eHAJSwJM_HG8423E0gaN6A3vI3k.TiLDWJmwT0eRGT6av94_mJI8qmCW4vfgzAOwkzirlgttpe5g ln_wP1pCv6zgzgZaEjoFxO_twAVCp449Oe3blwYVRovpVAtb1hFRRCA2SyCmzTppvJQGHUiAydxV UvCVtvoXWZMgVf9hue2Oi0CJgLw2n8V8oolCCnVbqMmJLUImnnWYadnFvPU2LodSU63hGYMFvAW1 r1t4O_j2f.STWYLHUU_ucDjN5TucbewbQYWz0CsyVT.it3cCfrtXqBaunvgiGN8DfV3oQPbjcx2U XJW2g1dbuzU32qeNQJ9lD9PvX7.7AWwz3dtPmRHgT2qsb3B.FwGqsezVb9UDmj31ZDZWtqehayuF nH7xrz3Ph0kNC8MP7yiR1Yg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 26 May 2021 22:42:45 +0000 Received: by kubenode510.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID aa85b5d42b6eeb01f562d4af023312cb; Wed, 26 May 2021 22:42:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: RPi 4 build time [13.0-RELEASE -> 13.0-RELEASE-p1 META_MODE example] In-Reply-To: <508F89DF-5CA5-4608-91E7-B232708BDC7C@yahoo.com> Date: Wed, 26 May 2021 15:42:40 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <0299DFBF-5497-4A06-978D-13E4FBD8B5F0@yahoo.com> <9A949E36-FDF2-40B3-A126-5538E41964D3@yahoo.com> <508F89DF-5CA5-4608-91E7-B232708BDC7C@yahoo.com> To: tech-lists X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4Fr5Yz48ryz4vZT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gbdM42Nd; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-22, at 19:05, Mark Millard via freebsd-arm wrote: > On 2021-May-22, at 18:36, Mark Millard via freebsd-arm wrote: >=20 >> On 2021-May-22, at 18:23, tech-lists wrote: >>=20 >>> On Sat, May 22, 2021 at 04:51:31PM -0700, Mark Millard via = freebsd-arm wrote: >>>=20 >>>> In general these figures are approximations of the low >>>> bound on a buildworld that is a (near) no-op but is >>>> not frequently approached in my normal activity. But >>>> it is rare for me to update the source tree again >>>> and rebuild after only a few source commits after >>>> what was originally rebuilt. For such, sub-half hour >>>> rebuilds can certainly occur via META_MODE use. >>>>=20 >>>> The context happened to be the ZFS based one in all >>>> cases. Still no ccache use. >>>=20 >>> That's wild. I have to look at meta mode.=20 >>> My use case though mostly involves building/updating ports with >>> poudriere, and I'm happy it can use ccache. >>>=20 >>> Am I right in thinking meta mode is a buildworld/kernel thing only? = I've >>> only heard of it; I know nothing about it. >>=20 >> Yep: buildworld buildkernel only. >>=20 >> META_MODE does not help for after a "rm -rf /usr/obj/*" >> sort of clean-out. It just attempts to avoid rebuilding >> materials already present that are sufficient. (It still >> builds more than is strictly necessary: Some of the >> dependency tracking tracks things that do not actually >> imply needing a file rebuild. This is why installworld >> to the live system ends up leading to a larger rebuild >> later.) >>=20 >=20 > I should have also mentioned the other side of > META_MODE: It is there to also be sure to rebuild > things that do need to be rebuilt. Its rebuilding > more than necessary generally avoids ending up with > insufficient/inaccurate rebuilds. Between ending > up with false positives vs. false negatives, it > has a definite bias. An example use of META_MODE: The buildworld buildkernel to be used for updating 13.0-RELEASE based to to 13.0-RELEASE-p1 based (old build still around to start from): World build completed on Wed May 26 14:52:43 PDT 2021 World built in 612 seconds, ncpu: 4, make -j4 Kernel build for GENERIC-NODBG-CA72 completed on Wed May 26 15:20:36 PDT = 2021 Kernel(s) GENERIC-NODBG-CA72 built in 1673 seconds, ncpu: 4, make -j4 It shows a mix: buildworld did not have much to rebuild but buildkernel did have a lot to build. Overall: somewhat under 40 minutes for buildworld buildkernel to complete. After installing and rebooting, my 13_0R-CA72-nodbg boot environment is at: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #1 = releng/13.0-n244744-8023e729a521-dirty: Wed May 26 15:20:08 PDT 2021 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 # ~/fbsd-based-on-what-commit.sh=20 branch: releng/13.0 merge-base: 8023e729a52192f89e539de760df194a70a91fda merge-base: CommitDate: 2021-05-26 20:36:52 +0000 8023e729a521 (HEAD -> releng/13.0, freebsd/releng/13.0) Add UPDATING = entries and bump version n244744 (--first-parent --count for merge-base) (buildworld buildkernel was via a ssh session. In some contexts using the serial console causes more time to be taken, just to display all the output text during the activity. installworld is an example for my contexts.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Thu May 27 02:42:21 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C2A5BBF4B17 for ; Thu, 27 May 2021 02:42:33 +0000 (UTC) (envelope-from qroxana@protonmail.com) Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FrBtb6pLMz3M6X for ; Thu, 27 May 2021 02:42:30 +0000 (UTC) (envelope-from qroxana@protonmail.com) Date: Thu, 27 May 2021 02:42:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1622083347; bh=M/H29M3h4QxMdpqt9Qklkd8pg0YNThq5aYyOp+UaWuw=; h=Date:To:From:Reply-To:Subject:From; b=blebYa3Bf2VILrvzWjwowmthhjOXOT/By+zhfxF4bn5EXQZ6XhFc16coGyZ48CIvZ eg7n950PWLOD3Pn6zD4lNY4wr4vZVVPltogcpzVsMgz97nUOTW866S/aaxIod+vlpi DsxXkR4f+R59OjIv3NWUtMA4qmrM5CyBi0gIhPZA= To: "freebsd-arm@freebsd.org" Reply-To: qroxana Subject: High interrupts of generic_timer0 on PINE64-LTS Message-ID: <52qt5LEz7KbfTbaCezLI7BbkJ_aRDDF0XrUDzS5VEa3pwB7T_M5MS5CCiNLOOQ6ePOCVw4bUltz4PSwNwqycioSmmmeZ8LRTAo_q4fEsdGI=@protonmail.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_XKhVnaQNeTJ0Zx6OzkDaS16yRNgSJFS5KkV5PY" X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4FrBtb6pLMz3M6X X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail header.b=blebYa3B; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of qroxana@protonmail.com designates 185.70.40.140 as permitted sender) smtp.mailfrom=qroxana@protonmail.com X-Spamd-Result: default: False [-1.68 / 15.00]; HAS_REPLYTO(0.00)[qroxana@protonmail.com]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.140:from]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_BASE64_TEXT_BOGUS(1.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.140:from]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; HAS_PHPMAILER_SIG(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[185.70.40.140:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.22)[0.218]; RCVD_IN_DNSWL_NONE(0.00)[185.70.40.140:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: qroxana@protonmail.com From: qroxana via freebsd-arm X-Original-From: qroxana X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --b1_XKhVnaQNeTJ0Zx6OzkDaS16yRNgSJFS5KkV5PY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SXQncyBydW5uaW5nIEZyZWVCU0QgMTQuMC1DVVJSRU5UIG1haW4tbjI0NjQ3Ni0xNWMwYWFmNTE3 MAphbmQgdGhlIGF3ZzAgZXRoZXJuZXQgaXMgZmxha3kgd2hlbiB0aGUgZ2VuZXJpY190aW1lcjAg Z2V0cyBoaWdoIGludGVycnVwdHMsIGFueSBpZGVhcz8KCiMgdXB0aW1lCjU6NTFBTSB1cCAxIGRh eSwgMTQ6MTgsIDEgdXNlcnMsIGxvYWQgYXZlcmFnZXM6IDIuMDgsIDIuMDYsIDIuMDUKCiMgdm1z dGF0IC1pCmludGVycnVwdCB0b3RhbCByYXRlCmdpYzAscDExOi1pY190aW1lcjAgMjU1NDUzMDc2 MTEgMTg0OTU2CmdpYzAsczA6IHVhcnQwIDg3MDEgMApnaWMwLHMzMjogYXdfbm1pMCAyIDAKZ2lj MCxzNjA6IGF3X21tYzAgMTI2IDAKZ2ljMCxzNjI6IGF3X21tYzEgMTQgMApnaWMwLHM4MjogYXdn MCA4Njc4ODc1IDYzCmF3X25taTAsMDotOHh4X3BtdTAgMiAwCmNwdTA6YXN0IDE1MyAwCmNwdTE6 YXN0IDIxNCAwCmNwdTI6YXN0IDIyOSAwCmNwdTM6YXN0IDIyNCAwCmNwdTA6cHJlZW1wdCAxODk5 MjMzIDE0CmNwdTE6cHJlZW1wdCAyMTc5MzAxIDE2CmNwdTI6cHJlZW1wdCAxNTQzODU2IDExCmNw dTM6cHJlZW1wdCAyMjQxNzQxIDE2CmNwdTA6cmVuZGV6dm91cyA0NyAwCmNwdTE6cmVuZGV6dm91 cyA0NSAwCmNwdTI6cmVuZGV6dm91cyA0NyAwCmNwdTM6cmVuZGV6dm91cyAzNiAwCmNwdTA6aGFy ZGNsb2NrIDcwNzE1IDEKVG90YWwgMjU1NjE5MzExNzIgMTg1MDc2 --b1_XKhVnaQNeTJ0Zx6OzkDaS16yRNgSJFS5KkV5PY-- From nobody Thu May 27 05:44:06 2021 X-Original-To: freebsd-arm@freebsd.org Received: from mlmmj.nyi.freebsd.org (unknown [127.0.1.24]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F22FBFD55E for ; Thu, 27 May 2021 05:44:06 +0000 (UTC) (envelope-from freebsd-arm+bounces-help@FreeBSD.org) Subject: =?utf-8?q?Unable_to_unsubscribe_from_freebsd-arm=40FreeBSD.org?= From: freebsd-arm+help@FreeBSD.org To: freebsd-arm@freebsd.org Message-ID: <1622094246-79344-mlmmj-7862dd3a@FreeBSD.org> Date: Thu, 27 May 2021 05:44:06 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N Hi, this is the Mlmmj program managing the mailing list. You were unable to be unsubscribed from the list because you are not subscribed. If you are receiving messages, perhaps a different email address is subscribed. To find out which address you are subscribed with, refer to the message welcoming you to the list, or look at the envelope "Return-Path" header of a message you receive from the list. From nobody Thu May 27 14:20:42 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C6DDBF7952 for ; Thu, 27 May 2021 14:20:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FrVNB0550z3lrm for ; Thu, 27 May 2021 14:20:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DFF5E258C8 for ; Thu, 27 May 2021 14:20:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14REKf3n092746 for ; Thu, 27 May 2021 14:20:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14REKf9R092745 for freebsd-arm@FreeBSD.org; Thu, 27 May 2021 14:20:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256197] Bad END label in arm64/bus_space_asm.S Date: Thu, 27 May 2021 14:20:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: nreilly@blackberry.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256197 Bug ID: 256197 Summary: Bad END label in arm64/bus_space_asm.S Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: nreilly@blackberry.com The END() for generic_bs_fault is incorrect, it is "bus_fault" rather than "generic_bs_fault". https://cgit.freebsd.org/src/tree/sys/arm64/arm64/bus_space_asm.S#n400 ENTRY(generic_bs_fault) mov x0, #-1 ret END(bus_fault) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu May 27 14:25:09 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 157C2BF833F for ; Thu, 27 May 2021 14:25:19 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FrVTV0lwRz3mdx for ; Thu, 27 May 2021 14:25:17 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 14REP53F012618 for ; Thu, 27 May 2021 10:25:16 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 27 May 2021 10:24:12 -0400 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by oc11expo29.exchange.mit.edu (18.9.4.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 May 2021 10:25:10 -0400 Received: from OC11EXPO29.exchange.mit.edu ([18.9.4.102]) by oc11expo29.exchange.mit.edu ([18.9.4.102]) with mapi id 15.00.1497.015; Thu, 27 May 2021 10:25:10 -0400 From: John F Carr To: freebsd-arm Subject: Orange Pi support Thread-Topic: Orange Pi support Thread-Index: AQHXUwQZkOBmcH5KBE6zeslMLPk34Q== Date: Thu, 27 May 2021 14:25:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [108.7.221.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E304A627A630E4AA3B9F2636980AA50@exchange.mit.edu> Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4FrVTV0lwRz3mdx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jfc@mit.edu designates 18.9.28.58 as permitted sender) smtp.mailfrom=jfc@mit.edu X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[mit.edu]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.58:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N It would be nice to have a support matrix showing Orange Pi models. I made= a list of models from the web site showing which SoC they use. There are = four model lines: AllWinner, Rockchip, RDA, and MediaTek. I see there are = u-boot packages for some AllWinner-based models. I assume those work. I s= ee no support for MediaTek processors in the kernel so I assume they do not= work. I assume the RockChip-based models don't work but could be made to = work because CPU support is already in there for Pine. The RDA8810 seems t= o be an ancient single-core chip and maybe nobody cares. Can anybody fill = in the question marks in the list below? Model Works? SoC Zero Y AllWinner H2 Zero+ Y AllWinner H5 Zero+2 ? AllWinner H3 or H5 Zero2 N? AllWinner H616 ZeroLTS ? AllWinner H2 One Y AllWinner H3 One+ ? AllWinner H6 3 ? AllWinner H6 R1 ? AllWinner H5 Prime ? AllWinner H5 Win+ ? AllWinner A64 +2E Y AllWinner H3 PC Y AllWinner H3 PC+ Y AllWinner H3 PC 2 Y AllWinner H5 Lite Y? AllWinner H3 Lite 2 ? AllWinner H6 R1+ ? Rockchip RK3328 4 ? Rockchip RK3399 4B ? Rockchip RK3399 RK3399 ? Rockchip RK3399 2G IoT N RDA8810 i96 N RDA8810 3G IoT N MediaTek MT6572 4G IoT N MediaTek MT6737 From nobody Thu May 27 22:23:28 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 42441BF15F7 for ; Thu, 27 May 2021 22:23:40 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.xs4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Frj5S06jWz3ClB for ; Thu, 27 May 2021 22:23:39 +0000 (UTC) (envelope-from adridg@freebsd.org) Received: from cust-d4a83f22 ([IPv6:fc0c:c11d:cecc:f58a:eaa1:c0:9d8f:c143]) by smtp-cloud8.xs4all.net with ESMTPA id mOPdlvbjqIpGymOPflFSkU; Fri, 28 May 2021 00:23:36 +0200 From: Adriaan de Groot To: freebsd-arm Cc: John F Carr Subject: Re: Orange Pi support Date: Fri, 28 May 2021 00:23:28 +0200 Message-ID: <1903034.XqBsHcZNj9@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10116122.pefvNM6J8o"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-CMAE-Envelope: MS4xfKgdqApRexjAC8e7Gc2Ap0bUENhpAvp4A3DT3W+ohL1Jc9TAQBLkpnCaEXdTIg/X4fBlCjAeyRx2fgHg7PcIPm+Yd8gN1mINqxxIbLkYgr8uS23WnZuE 3qkgSTIZQ3xhO5pfCzqvxhfvLUu3vHbpsxTHnQxSWm/1ukrzGyw1juCA1/DB6s5giCgnh3GEXRdni1+M4SMGaDBA3QZOOCiuMI7shhROdZ8oY53sIP48SY8Z xHF/d53O2s/4GZaNAu9QHz+kq23fTgcGusyJ+lgp32l4Zwx5xXy7XBc3FO0JRWaY X-Rspamd-Queue-Id: 4Frj5S06jWz3ClB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --nextPart10116122.pefvNM6J8o Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Adriaan de Groot To: freebsd-arm Cc: John F Carr Subject: Re: Orange Pi support Date: Fri, 28 May 2021 00:23:28 +0200 Message-ID: <1903034.XqBsHcZNj9@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: On Thursday, 27 May 2021 16:25:09 CEST John F Carr wrote: > It would be nice to have a support matrix showing Orange Pi models. I made > a list of models from the web site showing which SoC they use. This is good content for the FreeBSD wiki, https://wiki.freebsd.org/arm .. there are sub-pages there for e.g. AllWinner SoC and RockChip SoC, but also per board brand (e.g. Pine, Beagle) so there's precedent for having the tables two-ways. > There are > four model lines: AllWinner, Rockchip, RDA, and MediaTek. I see there are > u-boot packages for some AllWinner-based models. I assume those work. Prrobably? I only added the H6 page recently, after checking one Pine board. > I > see no support for MediaTek processors in the kernel so I assume they do > not work. I assume the RockChip-based models don't work but could be made > to work because CPU support is already in there for Pine. There's a Rock64 U-Boot (I think that;s the 3328) at least. [ade] (who does not rise above the "hm, does this image boot at all" level of skill here) --nextPart10116122.pefvNM6J8o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGyBAABCAAdFiEEhrjttu2OP5apuuy1z93JbxKxkVwFAmCwG+AACgkQz93JbxKx kVyBTwv3QeE1atelm5mOhZkSQXXFeNCB+xeINMzXwCeNFSeov2Bjfi08vXlCIN7W NLco+qREulRQqIFdx9iMBDpER7VhgEZwVI30X7wQPdJvh26wf+1RQdC/drWSMWez XFNfvo05Y1X6x04WjyV67UscImxStOdpYy5rTXGugzskexAu8yXhHydAx6ybONOk HrDxC5roIR99mhIxDYBiuzqe0ciOTs4urUKWkLzVjWq5cN9m9Fv5FDlsJBVBl/LW MJbCF0u5RnxldcGR28/72o/VRy+6ScFGElGy5vBvFlnJcK279xAPa1MjyffmnggM l+Mf+A/PTehXkH7tcXKQ+uDO3R/fCU/ZcDgFg//YZeJ0EBeM4Pr09igJluUHwVwZ FNsLA09GInVPwYggo2+OM/psUj9MxabN8m+Z8g7sm5uOl5Z8gF/VgMtfResi4tet ISZtksCJ1ZkEQkAUthCSE1aEP0+szR9diJHRBOyWupdK2yVYwfOM3TSlLZEwsh6t D0HC+cE= =2bXY -----END PGP SIGNATURE----- --nextPart10116122.pefvNM6J8o-- From nobody Fri May 28 18:40:08 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3AADDC7EF01 for ; Fri, 28 May 2021 18:40:17 +0000 (UTC) (envelope-from linimon@portsmon.org) Received: from MTA-14-4.privateemail.com (mta-14-4.privateemail.com [198.54.118.206]) (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 4FsD5D3ZYlz4W4T for ; Fri, 28 May 2021 18:40:16 +0000 (UTC) (envelope-from linimon@portsmon.org) Received: from mta-14.privateemail.com (localhost [127.0.0.1]) by mta-14.privateemail.com (Postfix) with ESMTP id 62067800C8; Fri, 28 May 2021 14:40:09 -0400 (EDT) Received: from APP-02 (unknown [10.50.14.152]) by mta-14.privateemail.com (Postfix) with ESMTPA id 409A1800C3; Fri, 28 May 2021 14:40:09 -0400 (EDT) Date: Fri, 28 May 2021 13:40:08 -0500 (CDT) From: "linimon@portsmon.org linimon@portsmon.org" To: John F Carr , freebsd-arm Message-ID: <819327797.341492.1622227209210@privateemail.com> In-Reply-To: References: Subject: Re: Orange Pi support List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev23 X-Originating-Client: open-xchange-appsuite X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4FsD5D3ZYlz4W4T X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of linimon@portsmon.org designates 198.54.118.206 as permitted sender) smtp.mailfrom=linimon@portsmon.org X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[linimon]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[198.54.118.206:from]; R_SPF_ALLOW(-0.20)[+ip4:198.54.118.192/27:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[portsmon.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[198.54.118.206:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22612, ipnet:198.54.118.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[198.54.118.206:from] X-ThisMailContainsUnwantedMimeParts: N > On 05/27/2021 9:25 AM John F Carr wrote: > It would be nice to have a support matrix showing Orange Pi models. Please contact wiki-admin@FreeBSD.org and we can set you up with access. I have not powered up either my Orange Pi 1 or Orange Pi +2E for a while but they were working via both serial port and ethernet the last time I tried them. mcl From nobody Fri May 28 19:13:10 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE626D7A154 for ; Fri, 28 May 2021 19:13:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FsDqN2Fz3z4bYv for ; Fri, 28 May 2021 19:13:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622229196; bh=nzddhZGrcXi9bGC6WfuRV/z6cpovIA1Rl1a35ajZPUA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=aXXWonWgvsR+20GsR0kQxiJ78/gpo4dJ1o/Kx6s3vWqcO/nECHUlrY0rVmYKnE+LNv7Q1Yd0mgNIXd1n7Zr2dJP5WXvVvMym+v8DkbViAoFcBjSLbZHYqWcq4BfP5GVSs8K6PUqOh3+rdWhzKRsd2llvp8N5swnc35JPn1OM8DbDOaLfWrlY4+s4w6FYq60IpxKE+OwA+mL8JMBf59J5Ch2hrvNaHAHdgxnIIj72KLE6UesKJef/2lkU4UhYXtgkzreLPC0nhLc3D55WRhcsf3HS4h1+HrGuIEP3VqurEnMkbG0hhk+TGjoNQfPDGfyMcARkF3cjqaC0h3KZcPeBbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622229196; bh=8LiAI0rFAxLwnnMJ40KP7UXYeMT782L1PyFvqK40dbt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ICTIFCqsfwEKNOEFe6r6fHmvzmajYPJBYuo2xXt8IO5zypytOy0OfcYrpOIjeWMkDyxKGsAZeCfyxycjgEL1cW5aOGMoWvKTXsmUOf8XUmcuvzXWKRRTT68bGY5+my6k+V7qcGxYf0yOu2Z1Ra0sE2DtzOQt+NCsAp6a/ly/0sBRRS9dK/ejC6xVTni0e3WLW7YvrUJqjpgwMO+gD62ikhusJw81rUv6zpwst2/16udVmmt2wZqJXXqEWl2k763l0uZEGN/JpEGyD3F0KBNviLBzNb1mGM4V/z5dPx4S9qien8rOfQTwyrcC41rMQb620kfPt9+4o0ZacCBeZEeuQg== X-YMail-OSG: CBgUFpQVM1mkdErRbnQvoJeYse0P4PMwaYh6fr9OxkM0LyyZ3VZc3sKqf_5vHgD 5YRgsf.1nqUIuMGFii06Gaz9SwDMMUNM1WE6QZeMjKpvsM.Rm6vRhjOB3wn4ykJyXUlSudG6pK4y UJ1aPB_DxTz6SV0MhZJX9.742rcHJKHmPLKaIcPnlyEZV8SXugU9V1llFBE14iIERtdzoPqH4Dep wIt7Tm0uq4dlI.FR2I2dCgPyBciCyfpwLm069mbm_KafNjWl.0lNNUdrYDuwj17OZqZH2dSjSpey OYkTvUeryNEaQrlXwdw_jGvxXSqrVwH_Qh3teGgNEg2S3asKPFZTZVhhptrdr7BIl4Ph3MP46.LS Z8yXI1agCd2_8nsAhytooH5q.vCTo7bGy.mXEzvYKmprugwVoT1S0lDwZk04rXlda5YlhpGsIgNh ena4A99KOu5kjdb6MUW_v3xCDmxmTWOD2yKKmMoQZapCa8cNVM0V8FZrXhY5WSpR939PuYeLDEka wrEAwnJfxJU0._D86b_mAhsKqiLYm0ft.yscsZB1ptTqyFmUAQrS4YMmt1pcTm5uTWPfVhBTDDVg eXRxldxhEEIg3nAyXJg741FHlw46135.UTIeGKa2b9PBtZW9Q63ZjilCgs4BJ7Ulhazbfik1bL.K h7NEDnHgAExQdwxxF5v74r7g94QaqbPcE4Y1zCySdJVMiHf.WnkDJjCiJJY9WF2QEvs1o64D3nGl WTAfW4iSEb1mZys71PBUAuqi.IefGNAwe51_E3rZP19kU8zWiuH9AVUy1wnZyyH5vmj0SY2d.Kk5 3njZlGFP4GpnP0qKgF7fbvpyj6UY8cw7J7ydFL_Wcd_23VsjBqZiZiBTMdjM6jF.MdxpKtwior0o ZNLoaNCRHkzzBAGFHtuEekPZIHzp6UogqUF1R5sPH7Tw9sakGqUNG7gLbeQWyxwUrzwQzDb9LPJD Wv6y8Kb3FKPQLCZYTKe3.JbaKTQPmbcMb2a3psgkZjHJ.545eSXJp_lzje5Owi1BcMwrJwwpiXeE .p43smonwMc4QQ0j3Hmb.Mzp7xYfM_wUJDJnKwB8M.ePg8uFzVJzvwL3vEeuQn0JQeEA9KD_nIl_ V6X_cyuSQecAdjCBweNpDXPuGLrrzFA2Ce2BXBD9gsNb_jCqyTQXTcOaSPOWyYb2y_SXJEvKm3tp SrES4_FXWvqnXMdMcK8Bzu3RWWSPg8bXfoI8Xo_FcHPnd_KRcFCJ7ENUpqqcVRlGGWHmX8nFzutG rvCAteyEGZDm7HREHRgaPboonTjaupk1e1nlYKgUq_SglZKvcahJpBcRWMEViJYQWxTZr0tUrTC9 XT4UGTivUpsAj_y_J_YD8zSC9eN9UftE39sQqJiX2iyDBSQagKggb7R75xYhPkRIjr.phPsftO7u kJ8Ekr35yXr2YeyFtl1QmgthYjVrO0PHzncppAjrr1_CkFTHKnvfIxF_r9paqB9NqK464X04sTfI 8m1fStJDIGzYTtNtUne4QSBO1w9msmQK1LyVZYhywLaUtey3xef1.3TQqXBkl2H9XsicrZ__.2yr 691T4yttkO2PkNi6Gu6rukco1flUxa9.nBD0i.4emenYEzcI4PiGSJV42naPdvE8LvQdiZrzRe2G qQDmeT6XMCENfVdyxYZGTzu7IEIeFy6yaRUlxc79feH72OqVDPN2ldmm.qhb8nlG85VHSbdpFmeN WhNGqgyMBxDTt.fYW3kwRy.rjtnjIomM0qxAiH_hsjXYGFCkErIhsFzKdS9T_TBF4Amkek7FrvhR USkUctr.LHu7_LM54vkwdf7Srt4UlNceSMcZmHOwZFREfcZSu2eLL93c7zGl_z1aJ3u2tvY1s6K7 Z13Vi2r3M4TKwCiVnyKag8pX7mhe0mo9p.df0beRfj2RGt0zMNkTL2BGmaUEFJd9znDVYNesDdd5 Wpcota.fFjTsD9_EGETG9.bdM48IdCPFMaykb514MonqUIuEN7hvLOPPn8FDRlV8cBjuiCv__WxY AODOXFnJktgHQsI.fWDAo6.L2iN0cEdY2AokFbOHMXtaTPlC241.AzCeMRwTURy17a6_hm8FBLLh S_37KHt2XhHDvAoYC_TaAA0T91xIbdJKVpkJSKP2j1yK7VJWC36kL.qJ2XtcBFcpHrbPJxKqOaRc hKApOcsaHzuvUD.w.LgTy7s9dMXs33HaU7gaSRXMqCaIveeOiJ23lqqPn7LuFQi1RWRXJ1WGJdGj qauHTGBbhQXyHXeWDHdjG5kjAETNxxkQH8DwifNyREoeGIr9qaqL5ek3s6Mj5ABgwCew.TqOkPzC ioFH2ZRzKLeSk9Q85FiojMvxOciAczag8gjfOncSEXbM0RdIMAgXpjDsUHw.cAlgo27Vl2C8NXUZ sPiKeLfUY1s0tepP3uJzKRlHwlh11z7AThLbd6NTiMEr3BNlcZqAzaZ_RD6kqGL78KGnny9U_3KP U4cy2rYgaxsZiZ6rH6uAzjlsSEcD_O27XnoSqF.bXqG8kXBnOGnsHN5fyBErglwJa18cIuxVx3XE 0oH1.HrisXdMrPta. X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Fri, 28 May 2021 19:13:16 +0000 Received: by kubenode527.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65db715f160cb373ab9d0a6c5bf407d4; Fri, 28 May 2021 19:13:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Orange Pi support X-Priority: 3 In-Reply-To: <819327797.341492.1622227209210@privateemail.com> Date: Fri, 28 May 2021 12:13:10 -0700 Cc: John F Carr , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <819327797.341492.1622227209210@privateemail.com> To: "linimon@portsmon.org linimon@portsmon.org" X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FsDqN2Fz3z4bYv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-28, at 11:40, linimon at portsmon.org wrote: >> On 05/27/2021 9:25 AM John F Carr wrote: >> It would be nice to have a support matrix showing Orange Pi models. >=20 > Please contact wiki-admin@FreeBSD.org and we can set you up with = access. >=20 > I have not powered up either my Orange Pi 1 or Orange Pi +2E for a = while but they > were working via both serial port and ethernet the last time I tried = them. Too keep my "root on USB" configuration going on the OPi+2e I reverted to the older 2020.10 based U-Boot that is still in quarterly. The 2021.04 vintages (before and after the change to UEFI) get through the loader and kernel startup but fails at the transition to world (so attempting usb access). (The only thing used on the microsd card is the U-Boot that was dd'd in all cases.) I'm guessing the kernel is dependent on some initialization by U-Boot that has changed in some way that is incompatible --but have no actual clue what is going on. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat May 29 08:15:34 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A3954C7ABF6 for ; Sat, 29 May 2021 08:15:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FsZB72SRKz4R7Y for ; Sat, 29 May 2021 08:15:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622276141; bh=a1G8Y2IXEM3EUYx2C8xz26hmHmUhUCoOlnvfxzWeCA0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qkL68s7NximAoNF0qPuYFGp2nGIKLYIvaTn2zpE4SIvoFojRvyv1fwa9cOqP25W3e6D93Wpwe64F+Qx83wNLI07nkzJiRRYnR7WQfjRebCBw4zQuovFpZ3avahtQsC4/7Qi52Dvg6rONjeaMi4b3qk/dhV5zOe9kfQ7R3mza148JsEc3DtxlAqIrzUguftZrxTmewldykCEiYj1lucbHlaqLMpEAL8NFp3eQ3/XDQZg/BVivnGuDGwZihX6oG9AoOkH1/Z1p0faGQOBTNz49iRwbSErxpkSMinLG9loi49mEmmDsHYTH75gGLYKr1R6clMT/eTHTGQi9wi/gf/9L8Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622276141; bh=TcY+mGX/lvhW22avQ0zXzYqm0UKG22QpmroXZUuX9e0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=blCkcIW9vJjU35myTqIsv0BXuy3lEOflBuGMn6x6AJR+mL7uY/q39FGM4wGyN0BNKiNRDtolTqyKfeQ/REOatGid6lEbcnBmvMEQFgmbUl8rsRBRFaC3qH0tIfLOnrcM4FL94JMDlXYcds9pxxX+h65JttEFTXM2Bu2tLGwjOGNhBLtr7V6SEekCW76NOgK2YGgeeEeV3annGHIL7HZRhgnu07LIR/beaJifmTWMVY+IhfhT8+fGZ6EmqA8fcYKpyBYJLsA2Nov+1AV7EtCxjQOHXgdFmAsCT+qdZmRY0TAvYUsLQaAf+TnQ3+O5Vt1zOd/KlE4vWJVg7YolH6EutA== X-YMail-OSG: jEJOUgwVM1mSOad78CFG5xxGNRHHiuYA3HAh2M2Iap3UYK0kOhCTWHE59YiU0S5 TAZU9YB53MJG6S0gFgtUbP1z5HrqO1y4A_TvX.NpjZU4goPMX0L2HRk736Kq.n0sVF5HUCtKMAhF IZNPaRGQVtRi9aLIsgsqOJYSPQI_nyeZsRO4Wtoab0GUkXLBjCogw.hFuWcEnskP802IFkYHHv15 kCmLsK2qXGWxm3SGP18bZlJ0eWGjlTob2u6DpIRkzIJJKl60wFJ6X.uNPsNmmvrvHTOA1cOwdn94 JqEvPg5Pq6DMPw6NMwbBgNUckFasrRPIHPdlzuLBtWnw2FftLetRcwRXv4.QxCq8vIoLPklWBOo4 UGKS31d_lceBnnK9VQtELYBrIozdlY0ufHD1Z2y.w5nCPnoxhXnZEXk9DzWNy9gXdhb8X47mwoRe EOPTy2_2543BOz0HKrrrumpnU9q26SlF9RJaeB25ZSWRuF5s0QWgUWXV3y5yECVW4lYabqVyvUHA I5oEXYGI9SpX3UBcGqEy7xJMwUWYucSqbONhheP2pszhl2xSimsX33XN7Lge1DHGhkbtWFD6dnSE .p1n81AqBGaJaJLkLDOHQHuD77YvOzv2CEk6CuzxfVsbFEktKeYtwA912RDeEHs3griFBZcCaDcv YgV4hQkT.JqxpZSbMWGKpOEv7RM1PE_n0s7xScnLghAcJjoIu7jtWj0Al5yQ_kmCto9rHuHbidqR IiUiHNs0GLTEgq6NURi9.NF7YQkXoJa.BWFArrsNyZoqVZ8F6fiZghPFaMFJKJm8_idcsgFKoqlL ygC5BSYavUr_MZt5pI1B2FMMqWru4R5Ou_Fu5UPQ.oumyxSC_OYVfplR34lrEeL7aUz3FDSiEgKt bak0a79879cduUX.3HwYGEGSqdMkkE5toRUzVU28PEHOjZweE8ijDDNmsPpOL8EbwOJZjtp4z66V LUN.0s8LJ4BOcJhREiVDnRc3nM_Ktfe4F4duNuNyhYPWKeAKUOMZj97V7fdCFpv3wj057KgdLqgN AIus7Rs7a7ePgeoHg8pVbDluhjUz8lD3T0iF5kk5ew8UY9vrLxL_Zw2BFOdBpyJRbYvTFOe0GHj. 3J60PQhePe8I5UgZ5WwyfMV.ny5QIKRsvaQUGU3EQjooLPNX9ocm8uOd_aD4d7nAiu6BJdziyOY0 vQWcxh8HeQrWMMUXECOM7nWmnhUvp0Yt6tyGuWqLrYLgwV126KuUHx80MpPdp_zvKsaJ8aLNq6I5 kMAoSbnSu0uq6zxGCClteZXYwizmSW_hvHS_AmEf8cYibMNQLN6fjj6rgEyfl4uEIvjpDevtn1lo 1aksLbfUBXKGfbo9sdA5r.6yBqWE0zhpFDzMFY2KvvW61v5ZUpHwAqA3rUQ4Ze6SsQyysMJviXIe aeaxyt72xNAEMKA7FigEVll2kI0ejT0Ue1QYnc5JXQZhaZIXnEvjJK9UWDJyFJU8o_xeknnwL8V6 U1qZAhBzhAGqOac5Xjh6n8tA_lrwEUMla9TEOy6GTRpKE8kvo9Ze3kowsF.dL_Z2Dbh6Qffr5Xk5 K6BC5KRdGzwJ5M4fRNO0bkpfk3EonmIPTKkUoDGt7d2r8g4FmR3OLlV36SemfjWXwQfmdNpWu7cU FmUb_.QmiimaVe9SOgKKDJy.lH_dhRqPWG.sNiNk1gEGU8BWjBoNaghB6ITejrmCrKfrfGrmH7Sv HbTpQQN9z8iR20KSTEEr_Y6Jmxs.NETkEiMwn.qw2oS26Zf5aqb0cz.f0Skjcezh4Z_Ot.VuLR_7 JT3epXHJhRZa4CZyTE3rEXEPQH4d2z9.vXGVZQSDm07mI.TrsESDo3YWsjcX.wmo0VAsi5Xwxw3x 2iHz4uv_QmQItF3gVe4XfYsd6Sm.AK3dNvp9V3fYAsYPJhO0akfBXe1hdyDf2rTg0kLRG3sfjY5o JQnuOtGISdj2f7X2Q2gOLl.4ab2KvOT_Ej.0ohuN5cRssD_tBY3o7VlgwW517hornfdH6clnPmy. a._HQ3tRvZIoTyPEQpSIEML8Z38LfnRtctLtDrJutYHPzjbHKTwAeo8Lj6KSgdJ9InH5iXEheM22 7.burGLXzKRpbDKnx2IT_NTbyvGwNdS6VTyP01K9rvSgUD_gU6fTIRUd_vcDun7x15K185jUakRv fLoKVmsmetiwE50s.e8h7q6rWAsYhL3stv9krvpIP.kWNrL0wEGCf9oB22rTZrKUbwRe4p5SVqLz POvij4Sfq6OQ1ByiTQ.dhlh1BsEvigO.S7q5GPo9.KYk4Pzu_76L0_hoDc69rN193wJnJ5AKf2A7 QtP_3cA6.V5Vy49UpZf7wPnwJliUaPrvfMjLoxBS3U._Kw03S8PDxIcNbuMegfrqlceNXOkZyNq6 7WcdrNBVwSPxCc._dN2QaTItTsgeIKP5kigmmtnsKlKYRPqB69IK0zo4n4anYtxwKqxAt_iBbCDG Tak5CzrorbS7D0mc.LCw9ffPqL27d7acpgrXkoXVDm2RbHSeDcDbslKQe6Iul7pwraOYgBjfUh9U rdnEKmkvv48oxjCi7JwRR0c6ldJFGXlqzzABuren.fS51uexVF85YMZF0yzW1J16a5YSrOMWp6vR SJo8jR7cry7zkJOkfsk5PIG.gT6KLbLFEcmYhg22acG51R1kJ9A.39_.GQf_DetUtRazGtX4- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 May 2021 08:15:41 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6cc552a86c5688d6360502b8cdeeca05; Sat, 29 May 2021 08:15:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: I got a panic for "nvme0: cpl does not map to outstanding cmd" on a MACHIATObin Double Shot In-Reply-To: <90A23579-61B7-4619-AFD7-68439FCC16F3@yahoo.com> Date: Sat, 29 May 2021 01:15:34 -0700 Cc: freebsd-current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <063D5E36-126F-497C-97AF-827BADC1ED2F.ref@yahoo.com> <063D5E36-126F-497C-97AF-827BADC1ED2F@yahoo.com> <90A23579-61B7-4619-AFD7-68439FCC16F3@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FsZB72SRKz4R7Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qkL68s7N; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.204:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.204:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-23, at 00:46, Mark Millard via freebsd-current = wrote: > On 2021-May-23, at 00:08, Mark Millard via freebsd-current = wrote: >=20 >> On 2021-May-22, at 22:16, Warner Losh wrote: >>=20 >>> On Sat, May 22, 2021 at 10:44 PM Mark Millard via freebsd-arm = wrote: >>> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/ >>> # diff -r /usr/ports/ /mnt/ | more >>> nvme0: cpl does not map to outstanding cmd >>> cdw0:00000000 sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 dnr:0 >>> panic: received completion for unknown cmd >>>=20 >>> cid 0x7e has no currently active command. The cid is used by the = driver >>> to map completions back to requests. >>>=20 >>> So, there's usually 3 possibilities that I've seen this with. >>>=20 >>> (1) There's a missing cache flush so you get a bogus cpl back = because something stale >>> was read. It's unlikely to be this one because the rest of this look = like a successful >>> command completed: sc =3D 0 is successful completion and sct is a = generic command queued. >>>=20 >>> (2) We're looking at the completion record twice because we failed = to properly update the >>> head pointer and we've already completed the command. I've only ever = seen this in a >>> panic situation where we interrupt the completion routine because = something else >>> paniced. >>>=20 >>> (3) There's something that's corrupting the act_tr array in the = qpair. I've not seen this, >>> but if something else smashes that area (zeroing it in this case), = then that could cause >>> an error like this. >>=20 >> Of note may be that I buildworld and buildkernel with extra >> tuning enabled, targeting the cortex-a72. In one past example >> this lead to finding a missing synchronization related to XHCI >> handling that was fixed. (The fix was not aarch64 specific at >> all.) For that: A cortex-a53 did not show the problem with or >> without that tuning. A cortex-a72 showed the problem only with >> the cortex-a72 tuning, not with targeting a cortex-a53 tuning >> or generic armv7, for example. >>=20 >> Not that I've any evidence specifically suggesting such would >> be involved here. But it might be good to keep in mind as a >> possaibility. >>=20 >>> Or it could be something new I've not seen nor thought about before. >>>=20 >>> cpuid =3D 3 >>> time =3D 1621743752 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> vpanic() at vpanic+0x188 >>> panic() at panic+0x44 >>> nvme_qpair_process_completions() at = nvme_qpair_process_completions+0x1fc >>> nvme_timeout() at nvme_timeout+0x3c >>> softclock_call_cc() at softclock_call_cc+0x124 >>> softclock() at softclock+0x60 >>> ithread_loop() at ithread_loop+0x2a8 >>> fork_exit() at fork_exit+0x74 >>> fork_trampoline() at fork_trampoline+0x14 >>> KDB: enter: panic >>> [ thread pid 12 tid 100028 ] >>> Stopped at kdb_enter+0x48: undefined f904411f >>> db>=20 >>>=20 >>> Based on the "nvme" references, I expect this is tied to >>> handling the Optane 480 GiByte that is in the PCIe slot >>> and is the boot/only media for the machine doing the diff. >>>=20 >>> "db> dump" seems to have worked. >>>=20 >>> After the reboot, zpool scrub found no errors. >>>=20 >>> For reference: >>>=20 >>> # uname -apKU >>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.= aarch64/sys/GENERIC-DBG-CA72 arm64 aarch64 1400013 1400013 >>>=20 >>> If you have the dump, I suggest starting to make sure that the = act_tr array looks sane. Make >>> sure all the live pointers point to a sane looking tr. Make sure = that tr is on the active list, etc >>>=20 >>> It will take a fair amount of driver reading, though, to see how we = got here. I'd also check to >>> make sure that qpair->num_enttries > cpl.cid (0x3e in this case). >>>=20 >>=20 >> Okay. I got this while trying to test an odd diff -r over NFS >> issue with the more recent software. So the two will potentially >> compete for time. >>=20 >> As investigation will be exploratory for me, not familiar, I'll >> probably publish periodic notes on things as I go along looking >> at stuff. >>=20 >> My first is that the /var/crash/core.txt.0 has a gdb backtrace: >>=20 >> . . . >> #10 0xffff00000047900c in panic ( >> fmt=3D0x12 ) >> at /usr/main-src/sys/kern/kern_shutdown.c:843 >> #11 0xffff0000002226b4 in nvme_qpair_process_completions ( >> qpair=3Dqpair@entry=3D0xffffa00008724300) >> at /usr/main-src/sys/dev/nvme/nvme_qpair.c:617 >> #12 0xffff000000223354 in nvme_timeout = (arg=3Darg@entry=3D0xffffa0000b053980) >> at /usr/main-src/sys/dev/nvme/nvme_qpair.c:938 >> #13 0xffff000000495bf8 in softclock_call_cc (c=3D0xffffa0000b0539a0,=20= >> cc=3Dcc@entry=3D0xffff000000de3500 , direct=3D0) >> at /usr/main-src/sys/kern/kern_timeout.c:696 >> #14 0xffff000000495fb0 in softclock (arg=3D0xffff000000de3500 = ) >> at /usr/main-src/sys/kern/kern_timeout.c:816 >> #15 0xffff0000004356dc in intr_event_execute_handlers (p=3D,=20 >> ie=3D0xffffa000058bc700) at /usr/main-src/sys/kern/kern_intr.c:1168 >> #16 ithread_execute_handlers (p=3D, = ie=3D0xffffa000058bc700) >> at /usr/main-src/sys/kern/kern_intr.c:1181 >> #17 ithread_loop (arg=3D, = arg@entry=3D0xffffa000058aef60) >> at /usr/main-src/sys/kern/kern_intr.c:1269 >> #18 0xffff000000431f6c in fork_exit ( >> callout=3D0xffff000000435430 , = arg=3D0xffffa000058aef60,=20 >> frame=3D0xffff0000eb7cc990) at = /usr/main-src/sys/kern/kern_fork.c:1083 >> #19 >>=20 >> So via kgdb . . . >>=20 >> (kgdb) up 11 >> #11 0xffff0000002226b4 in nvme_qpair_process_completions = (qpair=3Dqpair@entry=3D0xffffa00008724300) at = /usr/main-src/sys/dev/nvme/nvme_qpair.c:617 >> 617 KASSERT(0, ("received completion for = unknown cmd")); >>=20 >> (kgdb) print/x cpl.cid >> $4 =3D 0x7e >> (kgdb) print/x qpair->num_entries >> $5 =3D 0x100 >>=20 >> Based on also seeing the code: >>=20 >> qpair->act_tr =3D malloc_domainset(sizeof(struct nvme_tracker = *) * >> qpair->num_entries, M_NVME, DOMAINSET_PREF(qpair->domain), >> M_ZERO | M_WAITOK); >>=20 >> (kgdb) print qpair->act_tr >> $6 =3D (struct nvme_tracker **) 0xffffa00008725800 >> (kgdb) x/256g 0xffffa00008725800 >> 0xffffa00008725800: 0x0000000000000000 0x0000000000000000 >> 0xffffa00008725810: 0x0000000000000000 0x0000000000000000 >> . . . >> 0xffffa00008725fe0: 0x0000000000000000 0x0000000000000000 >> 0xffffa00008725ff0: 0x0000000000000000 0x0000000000000000 >>=20 >> It was all zeros (null pointers). No "live" pointers and, so, >> no tr's to inspect. >>=20 >> As none of this is familiar context beyond general programming >> concepts, it may be some time before I find anything else >> potentially of interest to report. If you have other specific >> things you would like me to look at, let me know. >>=20 >=20 > A fairly obvious thing I should have provided: >=20 > (kgdb) print/x *qpair > $15 =3D {ctrlr =3D 0xffff0000fe154000, id =3D 0x3, domain =3D 0x0, cpu = =3D 0x2, vector =3D 0x3, rid =3D 0x4, res =3D 0xffffa000086ded80, tag =3D = 0xffffa0000877b780, num_entries =3D 0x100, num_trackers =3D 0x80,=20 > sq_tdbl_off =3D 0x1018, cq_hdbl_off =3D 0x101c, phase =3D 0x1, = sq_head =3D 0x1f, sq_tail =3D 0x20, cq_head =3D 0x20, num_cmds =3D = 0x420, num_intr_handler_calls =3D 0xe66c, num_retries =3D 0x0, = num_failures =3D 0x0,=20 > cmd =3D 0xffff000100ebb000, cpl =3D 0xffff000100ebf000, dma_tag =3D = 0xffffa0000b093e00, dma_tag_payload =3D 0xffffa000059ef000, queuemem_map = =3D 0xffffa00005a07700, cmd_bus_addr =3D 0xacbb000,=20 > cpl_bus_addr =3D 0xacbf000, free_tr =3D {tqh_first =3D = 0xffffa0000b053a80, tqh_last =3D 0xffffa0000869da80}, outstanding_tr =3D = {tqh_first =3D 0xffffa0000b053980, tqh_last =3D 0xffffa0000b053980}, = queued_req =3D { > stqh_first =3D 0x0, stqh_last =3D 0xffffa000087243c8}, act_tr =3D = 0xffffa00008725800, is_enabled =3D 0x1, lock =3D {lock_object =3D = {lo_name =3D 0xffff00000090321f, lo_flags =3D 0x1030000, lo_data =3D = 0x0,=20 > lo_witness =3D 0xffffa0043fd96080}, mtx_lock =3D 0x0}} >=20 > Looks like I need to boot into the non-debug builds for the > other problem I'm testing for repeatability after a commit. I've no figured out anything interesting so far. But I've run into something that looks odd to me (not that I've any evidence it is related to the panic, more likely my ignorance): There is a use of atomic_store_rel_int(&qpair->cq_head, 0) for which I do not find any matching atomic_load_acq_int use (or other explicit _acq), so so there is no "synchronizes with" status in the code to establish an ordering across threads that involves the atomic_store_rel_int that I've found, just implicit/default relaxed-load-operations. A grep for "cq_head" under dev/nvme/ shows only: ./dev/nvme/nvme_private.h: uint32_t cq_head; ./dev/nvme/nvme_sysctl.c: SYSCTL_ADD_UINT(ctrlr_ctx, que_list, = OID_AUTO, "cq_head", ./dev/nvme/nvme_sysctl.c: CTLFLAG_RD, &qpair->cq_head, 0, ./dev/nvme/nvme_qpair.c: * below, but before we can reset = cq_head to zero at 2. Also cope with ./dev/nvme/nvme_qpair.c: if (qpair->cq_head =3D=3D = qpair->num_entries) { ./dev/nvme/nvme_qpair.c: * Here we know that we = need to zero cq_head and then negate ./dev/nvme/nvme_qpair.c: * the phase, which = hasn't been assigned if cq_head isn't ./dev/nvme/nvme_qpair.c: qpair->cq_head =3D 0; ./dev/nvme/nvme_qpair.c: } else if (qpair->cq_head =3D=3D = 0) { ./dev/nvme/nvme_qpair.c: cpl =3D = qpair->cpl[qpair->cq_head]; ./dev/nvme/nvme_qpair.c: * qpair->cq_head at 1 = below. Later, we re-enter this ./dev/nvme/nvme_qpair.c: * won't have updated = cq_head. Rather than panic again, ./dev/nvme/nvme_qpair.c: = nvme_dump_completion(&qpair->cpl[qpair->cq_head]); ./dev/nvme/nvme_qpair.c: if (++qpair->cq_head =3D=3D = qpair->num_entries) { /* 1 */ ./dev/nvme/nvme_qpair.c: = atomic_store_rel_int(&qpair->cq_head, 0); /* 2 */ ./dev/nvme/nvme_qpair.c: qpair->cq_hdbl_off, = qpair->cq_head); ./dev/nvme/nvme_qpair.c: qpair->sq_head =3D qpair->sq_tail =3D = qpair->cq_head =3D 0; (2 lines above the last has the atomic_store_rel_int use.) atomic_thread_fence_rel use would have "synchronizes with" based on ordinary loads reading something stored after the atomic_thread_fence_rel. Such is documented in "man atomic". But that is not what this code is doing. "man atomic" does not mention ordinary loads getting such a status by reading what an atomic_store_rel_int wrote. It does reference the atomic_thread_fence_rel related status for ordinary loads. So I'm clueless about what is intended to be going on relative to that "atomic_store_rel_int(&qpair->cq_head, 0)". Overall, the code does not appear to me to match up with the aarch64, powerpc64, or powerpc code generation requirements to have any matching "synchronizes with" relationships. (I'll not list machine instruction sequences here. I'd have to look up the detailed sequences. But, as I remember, more than a load is involved in the code sequences for the acquire side on these types of processors. Nothing in the source indicates to generate the additional code as far as I can tell.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sat May 29 20:25:04 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 71193EA80E1 for ; Sat, 29 May 2021 20:25:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FstMr6GlVz4YbW for ; Sat, 29 May 2021 20:25:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622319910; bh=p4aggnXXG4H/PoBO3Vypui1Uh04jeJJyUGWSIMbSzFo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iokO3iQsQv6cFWFiJxyvcVeBs9Ylyo0umsmvyJaG6PMeZGg48vvhrv9/prr2OiecO9ocOwjNDgPQF7lsFE41hpyMEiKaXYJRXccfT6Y4cKiJDtkA+bzrW4Jpy9p4XmWR6s5ejAZoo7Ws7W1qmWyaBm3/f7DpNZFYZyxSzRfbnmboJ/8vkJw/LCS1qo4qXCIY1g5jiiub0N3wISoBY5mjN/jFVmeapNsyTWumAfgGOtelNOTkN3dcnIH3QEwK0+EFoswx/Hu2QwGYFQVQuMOrGQM2nHgCFfDL0XFd2SQP0N2niaatYeHvVtxwxUIbFyrWf+lhGlWCglkv6njgAHlzmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622319910; bh=0Raub8PdcZJE+R2MLz/vl4bAhoxaYDIHtI0DnLYETV8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TDKQ7g11H22W71FGcwN69quHFR5uY8jorY5xEzdliaqrK9ge0/jt0qREtN4dsZbqfacKsfeIEtW9zXzJCGJgAt2QCX5AhunuXwvjscIUKG5rh4955VS6xnubnWila2cMjlRyalldbWaD4rQW0ivmHXm9eFVfbFYMLgr6b6lYKJHFqN4sjrU4Mp9+8d1jkhPGnuSk7GRzaq9/X9st3pe8E4XSBdBuy0dzhbsIEb40Uz3dge3VP0uyuVfCPUgNCeFYnQ8x9eyA2pk2oxZ9DnF+4AWrNs572N9vYkrCKg+8WlFQ+OukAs9XA0ntwG+qqFgaNJAykHCRjS8pHVnLbitQOA== X-YMail-OSG: 8EB6HQ8VM1nyiDP7gSQHbEOmAH00tmzIB4w3GNlgI36RnGGZZvp9lskV.tp9_FO uNTCXh9OGoZD553fH9UgxHpt2N49lJMf7G.g0S1Ur7Hdxr7.nsARVQtXw7PMUwHG5y2tkuAr6K9H 3BXQKMZRwJIfn8_89gFDwU6A4zcFD4_4lOx4G75DIjO0tAd4TG9Kz1SGTnNN0IsCtGaZF0GcMuK_ xMD_1bvZTebRCwJDNzOOe2TgHLh.63PUjbZyQdl_6trAnKBDNh6ofxnQ6GTGrq0JD6zLNO1K3NXX e73rFODU1O65ssLq2oci.UV6PBqFtQk4FAU1r_k76fNslDaWE1ifatlXHjZHQo6j7ZXLH5nnHI5m apm0WV7V8Xn0V6IYdqLKve2VnDqd01vUJAXe668ZIf7oJgbmOk9jOub5EI0mAiuMM9mzvspG5GGj 3Sz5XEVZl9sjPqpY7HkprA6oXG7q.3.FlrCOg8fgNvbQNL8VZ.JwMTpXiSCjoOpSzrdBG_SxwaRU up.aCwhybdUjEb4mSUBOKyhU9BoulWo1PVSb6rZvHcoffbIKtC.1OS1smDKNTfRSPjH0zMjzU6m1 B5DwmTtDTbVDMz59ONr2z1fZoNGy9GnEm4BOn_f.hyRe1rISH412EKC3l20Wltookbn11YON4sHz 1T9bKoCKtm2yPt.ZSMtcG44IU5FXZMw4B3X2HSrZsJZF.Q8y_4pBwujQyWmzYjRHCUbb_xVqVk1G HlixcovY49awQdHg2cL0paCnnZQTr68V5q41QNWOoNrXDAObL0O7zDh.gXn.5jYk2OVx9dovoLjR nYFW1qe27gqv2HQ40RKutK17xGxavDLkzqSkUzkUPIUoB_fX2cBAFAcJgVyhLwaiCP2dE1bA3Jj9 N9VxFjj8Kb.KxBDjiscshjx3hzKQK0zMPQZ0J0Y_renZBEyIb0m8XYtXmIYEf27p8cAM4G9SK3Xt 41IFycUd.A0lAAtFkOWly1CNGGZnxhdBwokO1XQfnFNIAiIC01q_pJDzJs1EUoEBog3wVu2X8CML 8OE9ZaVznmSaOL3j9hQ288AUj6B7AXDteFXc3kpEVTSCISBETY0MbIipW7bQWE9Jgl00oScKDnL6 vY2io_a5eisvY0ALQhrgWWwTu7_p4n82t8Efg2YI1In4XSzBAJWoGkaVP9AAGd7oMUUjhT5rzL92 s1sK36.Q.44S1CkK5WPK160wY8hUL1UPxz.vJX_7CaZWfkRn3b6P5f7AvXTNfZtCd_f4QtX3Bvhn Mn.zFpvH0Z5YQULquaCVR_Z0Ha634WQ6tMsjRr.SmKVqukXb_7oKiUVOEa6ZJex9Z2PwHnh4db6f Oyomoigkhc84L2OSaRKoxRjM84aFv9lh4HV34inTUcZqyzF1b.GeJXh15OeG_TI1ClApP7sYOpz0 .Sae_bJwYWxrOkk.Pl6vTveVtoz5PqV5UpYIrsw1m6u6dSousdIMQnam5R9FDC13pWSP3PIfjGZ4 92LObL01A8r0pjDrclUD0XQXFdznVWY4Td1Ji5i1_R77bCpv6Wu22qgfWtsZ1tGIMTraUVImqqnO iImJXOI7jiYnuQ0qvQ223JnpPZ3RGBs6SLSfSkm3JneoLPimRTCU_24wmzA4ZhJcTpyuItqY3uBJ 4Dsb1V0CP5YFRElHq_8H4XY11Hd4bS2um7cWEISFhe6SQbz8iRjLhn_O8gQVfsysH4in17owq1Vb KBF_cI97qyuuunier2npPf1FUWKGMVrm20XmGnABgIXOXv64uIrgz6yFu7VAHMiiMYzl3WsYQ6Bd U_vjps4p0N4bSawcw8C.y4oYFrkOPYfOiHzfJxKWmhj4o8YF6fSRgugjsNYSoTdfzVmYnUpNJNBO pJEEUv7X19kOVaJ.kOw6SlN7LbUXXuV8Pq7ZDVgaNmq.kq8xIx2VuHUBlsM5yxtnBgSLo83VWswx Y2dF8Aq0_f2BssR1CzU.RWyg7eN20qhTMLhz94lytpZaSWKMekvTRGZZKCX5YjIFOSH46DUZ5XiM n69cHGN.cGX66HQgMNiM4FFA5bxxx9BcdZ9oCx8Cmwjo75YEYixBVDsaVhSWF1AZOL4JiFVG3sbV FiX.vVSlHtvamyi0BLQVb6B8vramW16YSiNi1yDPw62KMkPuJvPc3RMItSdk.UGk7JFetTNMVPMN EoSYZhR_7npTWzoe0BmCxs7rYNfnMdmSYrwzljp7EFcPde3dHc_saA64H.h0MuoDO.2M5OwITO0J UKJCRZ5SRnHXbGYcKszaXFvTEAzuOwP2IdlR43oKqhsDqfuhniqGhLqmejr8aELPBNkwFjFmwSxz snzDKZ730SuHVmswRgtW9fK4vbHtclgy2YXxGg74Ha1kebLr2DkgZRfTuC5PbkAOLF1P4GVnvALU aEAyudGBu6BBaSrtXwKI5OFA8xTVXrMoKkH5GXOZW2QNFUbv4_Wwez2GtuLOgTWE9T67IdUfe8KJ g2ZC7TfWZ9lV2q9edendcE1bSmZfT4WcdNs7CHbCMbQh0OPpwZPy7GBDNqFkDd.o6zrAnAvgO25c LZzdj.CtWVoMzGjQDR98FBRtNBEXbUasNvaMlqHqKPCgAsAJE21GTY1kNSxfw1.yTZVP3T8O3HJn EuivBVFxQc7rvraVnWJXSUHb9hAIY9LYCAZw3Pj.0IUDRvE9BL4P9qtHG2kxQkSkPYHxv_9o- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 29 May 2021 20:25:10 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 6949223eab58cfe0afae3c20c4a03d16; Sat, 29 May 2021 20:25:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: I got a panic for "nvme0: cpl does not map to outstanding cmd" on a MACHIATObin Double Shot In-Reply-To: Date: Sat, 29 May 2021 13:25:04 -0700 Cc: freebsd-current , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4515C859-98C7-4FE2-AFBA-08CFF28D0774@yahoo.com> References: <063D5E36-126F-497C-97AF-827BADC1ED2F.ref@yahoo.com> <063D5E36-126F-497C-97AF-827BADC1ED2F@yahoo.com> <90A23579-61B7-4619-AFD7-68439FCC16F3@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FstMr6GlVz4YbW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=iokO3iQs; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.16 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.34)[0.340]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-29, at 01:15, Mark Millard wrote: > On 2021-May-23, at 00:46, Mark Millard via freebsd-current = wrote: >=20 >> On 2021-May-23, at 00:08, Mark Millard via freebsd-current = wrote: >>=20 >>> On 2021-May-22, at 22:16, Warner Losh wrote: >>>=20 >>>> On Sat, May 22, 2021 at 10:44 PM Mark Millard via freebsd-arm = wrote: >>>> # mount -onoatime 192.168.1.187:/usr/ports/ /mnt/ >>>> # diff -r /usr/ports/ /mnt/ | more >>>> nvme0: cpl does not map to outstanding cmd >>>> cdw0:00000000 sqhd:0020 sqid:0003 cid:007e p:1 sc:00 sct:0 m:0 = dnr:0 >>>> panic: received completion for unknown cmd >>>>=20 >>>> cid 0x7e has no currently active command. The cid is used by the = driver >>>> to map completions back to requests. >>>>=20 >>>> So, there's usually 3 possibilities that I've seen this with. >>>>=20 >>>> (1) There's a missing cache flush so you get a bogus cpl back = because something stale >>>> was read. It's unlikely to be this one because the rest of this = look like a successful >>>> command completed: sc =3D 0 is successful completion and sct is a = generic command queued. >>>>=20 >>>> (2) We're looking at the completion record twice because we failed = to properly update the >>>> head pointer and we've already completed the command. I've only = ever seen this in a >>>> panic situation where we interrupt the completion routine because = something else >>>> paniced. >>>>=20 >>>> (3) There's something that's corrupting the act_tr array in the = qpair. I've not seen this, >>>> but if something else smashes that area (zeroing it in this case), = then that could cause >>>> an error like this. >>>=20 >>> Of note may be that I buildworld and buildkernel with extra >>> tuning enabled, targeting the cortex-a72. In one past example >>> this lead to finding a missing synchronization related to XHCI >>> handling that was fixed. (The fix was not aarch64 specific at >>> all.) For that: A cortex-a53 did not show the problem with or >>> without that tuning. A cortex-a72 showed the problem only with >>> the cortex-a72 tuning, not with targeting a cortex-a53 tuning >>> or generic armv7, for example. >>>=20 >>> Not that I've any evidence specifically suggesting such would >>> be involved here. But it might be good to keep in mind as a >>> possaibility. >>>=20 >>>> Or it could be something new I've not seen nor thought about = before. >>>>=20 >>>> cpuid =3D 3 >>>> time =3D 1621743752 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>> vpanic() at vpanic+0x188 >>>> panic() at panic+0x44 >>>> nvme_qpair_process_completions() at = nvme_qpair_process_completions+0x1fc >>>> nvme_timeout() at nvme_timeout+0x3c >>>> softclock_call_cc() at softclock_call_cc+0x124 >>>> softclock() at softclock+0x60 >>>> ithread_loop() at ithread_loop+0x2a8 >>>> fork_exit() at fork_exit+0x74 >>>> fork_trampoline() at fork_trampoline+0x14 >>>> KDB: enter: panic >>>> [ thread pid 12 tid 100028 ] >>>> Stopped at kdb_enter+0x48: undefined f904411f >>>> db>=20 >>>>=20 >>>> Based on the "nvme" references, I expect this is tied to >>>> handling the Optane 480 GiByte that is in the PCIe slot >>>> and is the boot/only media for the machine doing the diff. >>>>=20 >>>> "db> dump" seems to have worked. >>>>=20 >>>> After the reboot, zpool scrub found no errors. >>>>=20 >>>> For reference: >>>>=20 >>>> # uname -apKU >>>> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #1 = main-n246854-03b0505b8fe8-dirty: Sat May 22 16:25:04 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.= aarch64/sys/GENERIC-DBG-CA72 arm64 aarch64 1400013 1400013 >>>>=20 >>>> If you have the dump, I suggest starting to make sure that the = act_tr array looks sane. Make >>>> sure all the live pointers point to a sane looking tr. Make sure = that tr is on the active list, etc >>>>=20 >>>> It will take a fair amount of driver reading, though, to see how we = got here. I'd also check to >>>> make sure that qpair->num_enttries > cpl.cid (0x3e in this case). >>>>=20 >>>=20 >>> Okay. I got this while trying to test an odd diff -r over NFS >>> issue with the more recent software. So the two will potentially >>> compete for time. >>>=20 >>> As investigation will be exploratory for me, not familiar, I'll >>> probably publish periodic notes on things as I go along looking >>> at stuff. >>>=20 >>> My first is that the /var/crash/core.txt.0 has a gdb backtrace: >>>=20 >>> . . . >>> #10 0xffff00000047900c in panic ( >>> fmt=3D0x12 ) >>> at /usr/main-src/sys/kern/kern_shutdown.c:843 >>> #11 0xffff0000002226b4 in nvme_qpair_process_completions ( >>> qpair=3Dqpair@entry=3D0xffffa00008724300) >>> at /usr/main-src/sys/dev/nvme/nvme_qpair.c:617 >>> #12 0xffff000000223354 in nvme_timeout = (arg=3Darg@entry=3D0xffffa0000b053980) >>> at /usr/main-src/sys/dev/nvme/nvme_qpair.c:938 >>> #13 0xffff000000495bf8 in softclock_call_cc (c=3D0xffffa0000b0539a0,=20= >>> cc=3Dcc@entry=3D0xffff000000de3500 , direct=3D0) >>> at /usr/main-src/sys/kern/kern_timeout.c:696 >>> #14 0xffff000000495fb0 in softclock (arg=3D0xffff000000de3500 = ) >>> at /usr/main-src/sys/kern/kern_timeout.c:816 >>> #15 0xffff0000004356dc in intr_event_execute_handlers (p=3D,=20 >>> ie=3D0xffffa000058bc700) at /usr/main-src/sys/kern/kern_intr.c:1168 >>> #16 ithread_execute_handlers (p=3D, = ie=3D0xffffa000058bc700) >>> at /usr/main-src/sys/kern/kern_intr.c:1181 >>> #17 ithread_loop (arg=3D, = arg@entry=3D0xffffa000058aef60) >>> at /usr/main-src/sys/kern/kern_intr.c:1269 >>> #18 0xffff000000431f6c in fork_exit ( >>> callout=3D0xffff000000435430 , = arg=3D0xffffa000058aef60,=20 >>> frame=3D0xffff0000eb7cc990) at = /usr/main-src/sys/kern/kern_fork.c:1083 >>> #19 >>>=20 >>> So via kgdb . . . >>>=20 >>> (kgdb) up 11 >>> #11 0xffff0000002226b4 in nvme_qpair_process_completions = (qpair=3Dqpair@entry=3D0xffffa00008724300) at = /usr/main-src/sys/dev/nvme/nvme_qpair.c:617 >>> 617 KASSERT(0, ("received completion for = unknown cmd")); >>>=20 >>> (kgdb) print/x cpl.cid >>> $4 =3D 0x7e >>> (kgdb) print/x qpair->num_entries >>> $5 =3D 0x100 >>>=20 >>> Based on also seeing the code: >>>=20 >>> qpair->act_tr =3D malloc_domainset(sizeof(struct nvme_tracker = *) * >>> qpair->num_entries, M_NVME, DOMAINSET_PREF(qpair->domain), >>> M_ZERO | M_WAITOK); >>>=20 >>> (kgdb) print qpair->act_tr >>> $6 =3D (struct nvme_tracker **) 0xffffa00008725800 >>> (kgdb) x/256g 0xffffa00008725800 >>> 0xffffa00008725800: 0x0000000000000000 0x0000000000000000 >>> 0xffffa00008725810: 0x0000000000000000 0x0000000000000000 >>> . . . >>> 0xffffa00008725fe0: 0x0000000000000000 0x0000000000000000 >>> 0xffffa00008725ff0: 0x0000000000000000 0x0000000000000000 >>>=20 >>> It was all zeros (null pointers). No "live" pointers and, so, >>> no tr's to inspect. >>>=20 >>> As none of this is familiar context beyond general programming >>> concepts, it may be some time before I find anything else >>> potentially of interest to report. If you have other specific >>> things you would like me to look at, let me know. >>>=20 >>=20 >> A fairly obvious thing I should have provided: >>=20 >> (kgdb) print/x *qpair >> $15 =3D {ctrlr =3D 0xffff0000fe154000, id =3D 0x3, domain =3D 0x0, = cpu =3D 0x2, vector =3D 0x3, rid =3D 0x4, res =3D 0xffffa000086ded80, = tag =3D 0xffffa0000877b780, num_entries =3D 0x100, num_trackers =3D = 0x80,=20 >> sq_tdbl_off =3D 0x1018, cq_hdbl_off =3D 0x101c, phase =3D 0x1, = sq_head =3D 0x1f, sq_tail =3D 0x20, cq_head =3D 0x20, num_cmds =3D = 0x420, num_intr_handler_calls =3D 0xe66c, num_retries =3D 0x0, = num_failures =3D 0x0,=20 >> cmd =3D 0xffff000100ebb000, cpl =3D 0xffff000100ebf000, dma_tag =3D = 0xffffa0000b093e00, dma_tag_payload =3D 0xffffa000059ef000, queuemem_map = =3D 0xffffa00005a07700, cmd_bus_addr =3D 0xacbb000,=20 >> cpl_bus_addr =3D 0xacbf000, free_tr =3D {tqh_first =3D = 0xffffa0000b053a80, tqh_last =3D 0xffffa0000869da80}, outstanding_tr =3D = {tqh_first =3D 0xffffa0000b053980, tqh_last =3D 0xffffa0000b053980}, = queued_req =3D { >> stqh_first =3D 0x0, stqh_last =3D 0xffffa000087243c8}, act_tr =3D = 0xffffa00008725800, is_enabled =3D 0x1, lock =3D {lock_object =3D = {lo_name =3D 0xffff00000090321f, lo_flags =3D 0x1030000, lo_data =3D = 0x0,=20 >> lo_witness =3D 0xffffa0043fd96080}, mtx_lock =3D 0x0}} >>=20 >> Looks like I need to boot into the non-debug builds for the >> other problem I'm testing for repeatability after a commit. >=20 >=20 > I've no figured out anything interesting so far. >=20 > But I've run into something that looks odd to me > (not that I've any evidence it is related to the > panic, more likely my ignorance): >=20 > There is a use of atomic_store_rel_int(&qpair->cq_head, 0) > for which I do not find any matching atomic_load_acq_int > use (or other explicit _acq), so so there is no "synchronizes > with" status in the code to establish an ordering across > threads that involves the atomic_store_rel_int that I've > found, just implicit/default relaxed-load-operations. A grep > for "cq_head" under dev/nvme/ shows only: >=20 > ./dev/nvme/nvme_private.h: uint32_t cq_head; > ./dev/nvme/nvme_sysctl.c: SYSCTL_ADD_UINT(ctrlr_ctx, que_list, = OID_AUTO, "cq_head", > ./dev/nvme/nvme_sysctl.c: CTLFLAG_RD, &qpair->cq_head, 0, > ./dev/nvme/nvme_qpair.c: * below, but before we can reset = cq_head to zero at 2. Also cope with > ./dev/nvme/nvme_qpair.c: if (qpair->cq_head =3D=3D = qpair->num_entries) { > ./dev/nvme/nvme_qpair.c: * Here we know that = we need to zero cq_head and then negate > ./dev/nvme/nvme_qpair.c: * the phase, which = hasn't been assigned if cq_head isn't > ./dev/nvme/nvme_qpair.c: qpair->cq_head =3D 0; > ./dev/nvme/nvme_qpair.c: } else if (qpair->cq_head =3D=3D= 0) { > ./dev/nvme/nvme_qpair.c: cpl =3D = qpair->cpl[qpair->cq_head]; > ./dev/nvme/nvme_qpair.c: * qpair->cq_head at 1 = below. Later, we re-enter this > ./dev/nvme/nvme_qpair.c: * won't have updated = cq_head. Rather than panic again, > ./dev/nvme/nvme_qpair.c: = nvme_dump_completion(&qpair->cpl[qpair->cq_head]); > ./dev/nvme/nvme_qpair.c: if (++qpair->cq_head =3D=3D = qpair->num_entries) { /* 1 */ > ./dev/nvme/nvme_qpair.c: = atomic_store_rel_int(&qpair->cq_head, 0); /* 2 */ > ./dev/nvme/nvme_qpair.c: qpair->cq_hdbl_off, = qpair->cq_head); > ./dev/nvme/nvme_qpair.c: qpair->sq_head =3D qpair->sq_tail =3D = qpair->cq_head =3D 0; >=20 > (2 lines above the last has the atomic_store_rel_int use.) >=20 > atomic_thread_fence_rel use would have "synchronizes > with" based on ordinary loads reading something stored > after the atomic_thread_fence_rel. Such is documented > in "man atomic". But that is not what this code is doing. > "man atomic" does not mention ordinary loads getting such > a status by reading what an atomic_store_rel_int wrote. > It does reference the atomic_thread_fence_rel related > status for ordinary loads. >=20 > So I'm clueless about what is intended to be going on > relative to that "atomic_store_rel_int(&qpair->cq_head, 0)". > Overall, the code does not appear to me to match up with the > aarch64, powerpc64, or powerpc code generation requirements > to have any matching "synchronizes with" relationships. > (I'll not list machine instruction sequences here. I'd have > to look up the detailed sequences. But, as I remember, more > than a load is involved in the code sequences for the > acquire side on these types of processors. Nothing in the > source indicates to generate the additional code as far as > I can tell.) Adding notes about the code generation, using fairly weak sequences (these are for C++/C11 semantics as I understand): (Picking prefix-form for powerpc:) powerpc Load Relaxed vs. Acquire: ld vs. ld;cmp;bc;isync powerpc Fence: Acquire: lwsync powerpc Store Relaxed vs. Release: st vs. "Fence: Release";st powerpc Fence: Release: lwsync Note: I am unsure how the above mixes with FreeBSD's plain-load vs. release-fence rules for atomic, for example. I've never seen a instruction level breakdowns of what implements FreeBSD's specific rules for powerpc64. aarch64 Load Relaxed vs. Acquire: LDR vs. LDAR aarch64 Fence: Acquire: DMB ISH LD aarch64 Store Relaxed vs. Release: STR vs. STLR aarch64 Fence: Release: DMB ISH Note: Again I am unsure of the pain-load vs. acquire-fence rule for FreeBSD. And, here, similarly for the plain-store vs. release-fence rule. I've never seen a instruction level breakdowns of what implements FreeBSD's specific rules for aarch64. armv7 Load Relaxed vs. Acquire: ldr vs. ldr;"Fence: Acquire" (or = ldr;teq;beq;isb) armv7 Fence: Acquire: dmb ish armv7 Store Relaxed vs. Release: str vs. "Fence: Release";str armv7 Fence: Release: dmb ish Note: The above fits with FreeBSD's plain-load vs. release-fence and plain-stores vs. acquire-fence rules because the fences are used to form Store-Release and Load-Acquire. (If I gather correctly FreeBSD does not support aarch32 for its distinctions from armv7, for example the aarch32's alternative SeqCst mapping that does not mix well with the armv7 mapping. Still I list aarch32 for reference.) aarch32 Load Relaxed vs. Acquire: LDR vs. LDA aarch32 Fence: Acquire: DMB ISH LD aarch32 Store Relaxed vs. Release: STR vs. STL aarch32 Fence: Release: DMB ISH Note: Again I would be unsure of the pain-load vs. acquire-fence rule for FreeBSD. Similarly for the plain-store vs. release-fence rule. I got these code sequences from: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html I was unable to use the code sequences to figure out the intended operation of the: atomic_store_rel_int(&qpair->cq_head, 0) absent any atomic_load_acq_int to match --and everything else being based on just plain load/store for cq_head . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 08:55:29 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EA273DF65FC for ; Sun, 30 May 2021 08:55:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtC1j6pSmz3w4K for ; Sun, 30 May 2021 08:55:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622364935; bh=KiGFADURygBdqPfFncQF81v3vuW7d6iyk7H7UP6nkvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AT2GitHBpFNnREesRMzxHacRX1WfrYAkSIydZ8ntBI4kiZzfEkeMkN4NifHPm8g98TbG38iciAq4X6HSJsOikWCTVZFlSOBZ8OP6cBca8kA2ji+y/iAkcK+NmBLu775GimEwyWZaRyueKrVLG9sYMQXIlM+2H7CReOF0vilkNvCov+DkrWHXipSP5Zcs7gbgm8qsum8G5T2HUvb5Id8TZIsn7dIoo0ybOKNGN35n2I742DDq+z7R2Gs/qNpoS4jaZw8zCtuMQIDEAW/19305elidCmMHiC4G6/mF/06Z1MfRRvLhho1EWzZKhWRxzuKj5qMNz4jpBFHLF1c8cLUV+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622364935; bh=r4xj6OAoF2NsKhklHFnlUuUwil8Fn9mbo1et/hC2DPh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZGOfaXswuR+IHGh+q0DCvniwdIUprPnntWwrcn8wWg60IMsKtlWEnGfOsPUNrTkrSkcRd6ZhvU+DKoJUFx5J1T1ESUKtf4DNRrOfXkVMKNj3H+/yrR6B0yKddcwX7gC3pocf8C+1h3tdEvCccG+AqESl4RzpED3GEeXc+upDro/cQAqFy1mf+BZh2V1smkkGhR0UQMjgcLcfdbCSfIZuaU/gy8wXHF1gGGbh9LAsTnqhnkoFQ7LuOLeR8iD6opv9Muv+L9a8eK1ntcQ4/hid2J/dtCcNKx37tTho6USTKOloG5Ik40XpxoUBin1lLEWnkzg0N0aHj9IdKFiwE3fYxw== X-YMail-OSG: oUPw7MwVM1kmo4..c3.WgZ5Qe3NAdF0p.8B7JHJt.3GhOG8nNfQ7s0MAwMWUWTe sogJhsnQLW1vwqUNWQ8_C4knN93uFPT.jBdSsLj1god7YxUaror9JM.X6wMl7HfhJew_cQ4_5FpN v.0LfE9XZWDm8nKvsD_Y.aDlgR.oVOoddBHmx4Tv7Mc_f7wQSwIv9VlYwtSgrabppmlW5wzJlICt sUyh0c9IV1hQnLkVmnJqgyE1XQsykCcJaJULo91kzRob.1rVZqCAcbrzw29BsEc9EoJyCApBJ1Ko c7HJWKQvx7seIoKtUFXtRSJ7.L6iklAL5WAUrUAR_d6dgNN0saRLBzJbRgVGhO4iXlVPtD0B2NSS vwCbTjikB7NfFuUrsBM6B_yJJFGbcEeYP_uBxcvP2HAJHu8N9W6MecAz1MD0ACdx1FBYIfgvIs90 6Mduq0cfs9_fj_RRU4VWG3XwI8B4AHA33fUMcbjb7Td1ch5rEI1ryUxRlvflZpVdevYz7IiL0DMZ GvzRaTEAmTU3FYesOI7.Uc6SkhcGShgHQfztZSzCHocvF4JU4wCOgraVwr_KrVtVx3NIRzyDFmgN iJ2uTZkx3uWSVUoMgvzWUW6wStmT0qdnySPc2P4XQBwnV_Vwh2LwQy_WbzJRS9SaEegYk3iR2YUJ xi8aM3NNP9Ojp91aNntCVrFn89Hm9jbE63sL1sVXapeRjBqbHiBd2IxDhdvKemipLMi3RYINC5UX lXSCcqfOKNCWOw6IcLu.hePwxIRkTcESdExHAqP29FgmRfC2EFXCLUoNZ0PdKnZIHEPgi9kP2IjR Xja0NeOhJYesiRIiZ9KtGqnimzPOm9DmxDkk8GZB5eVI8HDlqjqVOfJHmz_rZ6v7uD4Ap0TH.k8H AJUTiSLS1iwvxMZQ2Hp_sXTY.Qhfb8YIhb4qjre1giZH3YZ1AAUPfffnKFbdprKzTC7AHl29YMSV tthMdEg0bXeRJGv.dlvGDkMSE3AhhXold9KDKw5H7rDciVvqEAAoNaJw7bUtZgFCLbBeg8XDTbbP Mv6arwNZjQtRDFWdgk6MNq4lI2JqkZB4JuMNX3oQNfxsxbKb6H1QOgeEECy3dLrNXt8yHend9p8O lOV5xJDAl6krTyWOm_D3er5_SuL4StCqjUnAIxwI.Btw6oXsJnSsh73iYqpf7md4EERmWsJkQR_E 2FDHSomIqx6R6YxGKE.mBQ0lEm_DLn5nJZ1cXYFlKOuZqH.3hi2780LGl7yzHmTe5QAJohU0c_2M FLzzrxL40_FhCe6skzRsf39KpqEGEaVdsZtmvaJ7JZ1ACh9SUWC7E33ljSVaFPXDD4RNURlt9._n sCjlGJCxLBtkcouMUv5VYPvu_9Eqg82rIl5nLL7chbWUaEkOiEE7jmYXMH2YsVXgRMI9eL7W9cKf neuSHi9jwGsQNBfbl91n7IYIqbWPfImpsilQkhqv661rmPPLaVhTVk6B9FSN6NTf.32NtkJwFDQT PhirHLF2mVyKBlw9SdvoTsqSDHIFD.TdfjtI5g5v7QpIPjk77b1AA_7d3zgL4oOAWhxd6hwY9yd5 IYOA7pHiIxli2igvZpKobY7.oy90Nm.b_qvcYeUJEkkx0T9_6vVcpSvEcwcKTyu6wbNFQCE3_2gd 49XXzwpPKBwISVSgDjfUl.mfyQdGfjJouyy8G_xBTOAEz7ycxDXNCmt.Ajm_yqqNzywv6L5mB0Bv v8YXESVosVxss.XCxQ.PiQatHhF43HU.28xeDUeoLxGRwlArBJCMTDElDOUOig2sruAUnNLVoxlU BM5run.NWnqmUvUG0l9ZmluxUbF6_GuJga1_WpNK5MnEQIM56QbpJmNqJPepnSdP4QhNMOpqrZ2z 9N87u8AhCWlLS5jk080KVobQcr8R8GDkQ5nyBaQB2wDp8AzE4kBTcUuwxqp8lHXZIKkJRf06mA_d Fl58SZiyGLbHl.qXfnxFUw52gjIMKdLtFUq22ZZzHceS4GVm_RXTCIZtAQ.4KH2ubBgk.qSbSa9I tZUNAi3FsSCUm0JXOi4QwvXsP6XObGykVn8ZqcqAtRItuxihVDzZBBpzM3k6mU39zhIZ33Uy5H29 8S_a63heEWDf17TMhLkYUO8MhJCmXIHSGLt1Kg1B8Rvf4rJNLd2BjIULKloGtuGuVf3gI4AK3ZHd ercC1K5aSq_j2c3XIAOZqlX0XNsbhchwH1VbFCMkxASo4NzRRrJez5xvOnd2E.0U7.OmHryBrXVR fcuHnvSRmEl7oTUZtyj1s.BU7nvPIeuH8nN5HOHOZWpTkQ9F5lLd6RrmakY7OVYigtC2dOWwvEK1 NwiHYAULrQVIHhmZ0XE4MeHiImdN3WqniwIeK06l6YjtRDrODiDnUxsS1aMAInWTjpJd8VHXBNb0 mOOsqSdk7EKYst683vHR5RWAmcpXziHOT.JOyuq_44OU1cIevc8ZUqcMV_.vvw.2bM0jZqBhKjE7 FqHX5gEIwPNXWk7jDEjZFSJk4GsO1ZifdphKZ465W5qmfjjl9Kbk2wV_WVMhop5R8IcC9.o8ZenX CAGQnhlydkGhsDf7qXIhwYsX9B_ZVbxIa66qJlYXOCr99mCI6JQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 08:55:35 +0000 Received: by kubenode512.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1a0b6f3ec7b021ac3b421b2bf683043d; Sun, 30 May 2021 08:55:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> Date: Sun, 30 May 2021 01:55:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtC1j6pSmz3w4K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AT2GitHB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-29, at 22:17, William Carson wrote: > Hello Mark, sorry to unicast you but I keep getting rejected from = freebsd-arm@. I was hoping you could give me some guidance, as it seems = you've made quite a bit of progress in this area. >=20 > Is there any documentation or a howto in order to get FreeBSD to boot = from a USB3 disk on the RPi4 8GB? I dd'd the latest 13.0-RELEASE image = (FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img) to the USB3 SSD, but it = does not boot. (The same image works just fine when written to the = sdcard.) It looks like it's unable to locate the USB disk and then gets = stuck in a loop trying for network boot. When I get to U-Boot prompt, it = says there are no USB storage devices. If I issue "usb start", there are = still no devices. You report: > If I try "usb reset", it seems to find it, but then it displays an = error ("scanning bus xhci_pci for devices... Setup ERROR address device = command for slot 1. USB device not accepting new address = (error=3D80000000)" and then locks up. I checked that I have the latest = bootloader: (I assume no microsd card was in the microsd card slot.) I've not seen or heard of that U-Boot report before. But you made it to U-Boot so the RPi4B firmware worked for getting U-Boot from the USB3 drive. This suggests the U-Boot stage is having the problem. So I've no specific solutions, not having seen the kind of report before. I've just more generic notes and questions. [I'll note that I've had no problem with USB3 SSD booting the RPi4B's that I have access to (no microsd card involved).] One test is to use the microsd card that boots via the microsd card slot and instead put it in a USB3 microsd card reader, plug the reader into a USB3 port, and try to boot from just that. If that boots, then there would seem to be some device incompatibility with your specific USB3 "boot" drive. If, instead, booting via the reader fails, then things are rather odd. (See later notes about SOC vintages.) > # rpi-eeprom-update > BOOTLOADER: up to date > CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) > LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) > RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable) > Use raspi-config to change the release. >=20 > VL805_FW: Using bootloader EEPROM > VL805: up to date > CURRENT: 000138a1 > LATEST: 000138a1 Since you got to U-Boot the RPI4B's bootloader worked. The above is what I currently use in the RPi4B's, 8 GiBYte and 4 GiByte ones. > If I dd Raspberry Pi OS (2021-05-07-raspios-buster-armhf-lite.img) to = the same disk, it boots up no problem. I'm thinking this is a = U-Boot/rpi-firmware problem, but I don't really know where to begin. FYI: if you ever want to use both a 64-bit kernel and a 64-bit user space, there are BETA's of such (Debian Buster based): https://downloads.raspberrypi.org/raspios_lite_arm64/images/ https://downloads.raspberrypi.org/raspios_arm64/images/ (I'm not claiming any gain from such for the problem at hand.) > I tried building my own image using crochet, https://wiki.freebsd.org/arm/ reports about crochet: "Alternatively, images for many boards can be built by crochet = (deprecated) or using FreeBSD's release build infrastructure." There were no commits at https://github.com/freebsd/crochet between 2019-Oct-06 and 2021-Apr-23. But there are some on 2021-Apr-24. I do my own builds based on using make commands but I do not use the release scripts for building. I build for a variety of systems. > but that didn't work either. > I'm also not sure whether I should be using sysutils/u-boot-rpi4 (I = used this) or sysutils/u-boot-rpi-arm64? Either should generally work. (But see later notes about RPi4B SOC vintages.) FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img was based on sysutils/u-boot-rpi-arm64 . I've historically built and used a variant of sysutils/u-boot-rpi4 but my history goes back before sysutils/u-boot-rpi-arm64 existed. I do not do anything were the configuration variations involved matter so I'm not familiar with the distinctions. I've used both a previous 2020.10 based U-Boot and a more recent 2021.04 based U-Boot. > After installing sysutils/rpi-firmware (1.20210303.g20210303), should = I just copy /usr/local/share/rpi-firmware/* to the boot partition and = rename config_rpi4.txt to config.txt? I assume you mean the msdos file system partition when you reference "boot partition". The msdos file system needs to contain: A) copies of /usr/local/share/rpi-firmware/* materials, using config_rpi4.txt content as the config.txt content. The copy should be recursive, to pick up the likes of the overlay/ subdirectory tree. B) a copy of an appropriate u-boot.bin ( from /usr/local/share/u-boot/u-boot-rpi-arm64/ or /usr/local/share/u-boot/u-boot-rpi4/ ). (See later notes as well.) C) A copy of /boot/loader.efi (the FreeBSD loader) placed at/as efi/boot/bootaa64.efi in teh msdos file system. I use a USB3 SSD that has small enough power requirements to not require a powered hub. (I also use a 5.1V 3.5A power supply as part of that context.) I've never tried spinning rust or higher powered USB3 media. It is unclear what the dd command details were like for the transfer to the USB3 media. So I just assume that it was okay. You may want to have an empty file named timeout in the msdos file system. It allows for extra time. (I doubt it helps, since U-Boot did load and start.) What does: # rpi-eeprom-config=20 [all] BOOT_UART=3D0 WAKE_ON_GPIO=3D1 POWER_OFF_ON_HALT=3D0 DHCP_TIMEOUT=3D45000 DHCP_REQ_TIMEOUT=3D4000 TFTP_FILE_TIMEOUT=3D30000 ENABLE_SELF_UPDATE=3D1 DISABLE_HDMI=3D0 BOOT_ORDER=3D0xf41 report in your context? (An equivalent command is "vcgencmd bootloader_config". I show example output above.) Can you see the top of the SOC? Or is there a heatsink or some such on it? (There is something there to read if it can be seen.) One possibility is that you have newer hardware that the normal U-Boot vintages that FreeBSD has used do not handle. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255080 is about someone that instead of having only: QUOTE Old Pi has the following identifying marks on the SOC package: BROADCOM 2711ZPKFSB06BOT TE1919 045-23 B3 W END QUOTE the person also had an example of a 2 GiByte: QUOTE New Pi has the following identifying marks on the SOC package: BROADCOM 2711ZPKFSB06C0T TA2105 054-05 B3 W END QUOTE The: 2711ZPKFSB06BOT vs. 2711ZPKFSB06C0T is significant. If you have a 8GiByte "C0T" RPi4B it would be the first known example. In such a case, you might want to try the u-boot referenced in Comment 15 of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255080 . It got the 2 GiByte "C0T" to boot. (But that context could not even boot via the microsd card slot with the normal media content from 13.0-RELEASE .) I do not know if the 2021.04 U-Boot that the since updated port now provides would work for this context or not. I've no access to any "C0T" RPi4B's (or any Pi400's or CM4's). There is a category of USB device that U-Boot still does not support as far as I know: those where the one device has multiple storage LUNs (instead of just one Logical Unit Number identifying storage). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983 is about such a context, where we eventially figured out the "multiple storage LUN" issue. But the error messages from the U-Boot of the time was not what you report. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 17:59:52 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 132D6DF9B3D for ; Sun, 30 May 2021 17:59:57 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from mail.disillusion.net (mail.disillusion.net [96.126.127.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.disillusion.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtR5m6Ykbz3MXG for ; Sun, 30 May 2021 17:59:56 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from roast.disillusion.net (localhost [127.0.0.1]) by roast.disillusion.net (OpenSMTPD) with ESMTP id 2a7421e1; Sun, 30 May 2021 12:59:53 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dsllsn.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=drip; bh= egY5K+Q9VPh5mIVy4g1VuBJvzzQg5Vk5rgmshGvK7Qw=; b=Cf2JD+PaET/tt9Ks WRGMcIdd5lbiJ2GUxxs/s22zxA1IVA+ZzrDYOnJf6W4Ef7X4h31ic6Y6wFqiOSKz fopbU5HuUYGC/vT7IgZmhoC3iUJcCk0HQR9is6CzPQ+91U7UbMJyM4FeGJzfSNC+ FLx9lQnFZ0PePdYz+V0D8cyzRso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dsllsn.net; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= drip; b=SGXufvH5OKsmlHSiDm0dFsMjodlY1Xk0YeBiouaF870dXZMvtTZgIwar dm4SsY1y3qEXHjzWay0VYVgAOrZqD7IXNowLiHj6XLPEbzyINRJ0snA+Mo0xV9m3 LdanYytsUCgzJUx5AHIBI+ZQGAjOCPaAYWte0GUUzm49mswNiI8= Received: by mail.disillusion.net (OpenSMTPD) with ESMTPSA id 9e0f2f18 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Sun, 30 May 2021 12:59:53 -0500 (CDT) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> Date: Sun, 30 May 2021 12:59:52 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> To: marklmi@yahoo.com X-Mailer: Apple Mail (2.3608.120.23.2.6) X-Rspamd-Queue-Id: 4FtR5m6Ykbz3MXG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: freebsd@dsllsn.net From: William Carson via freebsd-arm X-Original-From: William Carson X-ThisMailContainsUnwantedMimeParts: N Thank you for the quick and thorough reply! > On May 30, 2021, at 3:55 AM, Mark Millard via freebsd-arm = wrote: >=20 > On 2021-May-29, at 22:17, William Carson wrote: >=20 >> Hello Mark, sorry to unicast you but I keep getting rejected from = freebsd-arm@. I was hoping you could give me some guidance, as it seems = you've made quite a bit of progress in this area. >>=20 >> Is there any documentation or a howto in order to get FreeBSD to boot = from a USB3 disk on the RPi4 8GB? I dd'd the latest 13.0-RELEASE image = (FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img) to the USB3 SSD, but it = does not boot. (The same image works just fine when written to the = sdcard.) It looks like it's unable to locate the USB disk and then gets = stuck in a loop trying for network boot. When I get to U-Boot prompt, it = says there are no USB storage devices. If I issue "usb start", there are = still no devices. >=20 > You report: >=20 >> If I try "usb reset", it seems to find it, but then it displays an = error ("scanning bus xhci_pci for devices... Setup ERROR address device = command for slot 1. USB device not accepting new address = (error=3D80000000)" and then locks up. I checked that I have the latest = bootloader: >=20 > (I assume no microsd card was in the microsd card slot.) Correct. > I've not seen or heard of that U-Boot report before. > But you made it to U-Boot so the RPi4B firmware > worked for getting U-Boot from the USB3 drive. >=20 > This suggests the U-Boot stage is having the problem. >=20 > So I've no specific solutions, not having seen the > kind of report before. I've just more generic notes > and questions. >=20 > [I'll note that I've had no problem with USB3 SSD > booting the RPi4B's that I have access to (no > microsd card involved).] I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 NVMe, = attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. > One test is to use the microsd card that boots > via the microsd card slot and instead put it in > a USB3 microsd card reader, plug the reader into > a USB3 port, and try to boot from just that. Hmm, this worked just fine. > If that boots, then there would seem to be some > device incompatibility with your specific USB3 > "boot" drive. If, instead, booting via the reader > fails, then things are rather odd. (See later > notes about SOC vintages.) >=20 >> # rpi-eeprom-update >> BOOTLOADER: up to date >> CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) >> LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) >> RELEASE: stable (/lib/firmware/raspberrypi/bootloader/stable) >> Use raspi-config to change the release. >>=20 >> VL805_FW: Using bootloader EEPROM >> VL805: up to date >> CURRENT: 000138a1 >> LATEST: 000138a1 >=20 > Since you got to U-Boot the RPI4B's bootloader worked. > The above is what I currently use in the RPi4B's, > 8 GiBYte and 4 GiByte ones. >=20 >> If I dd Raspberry Pi OS (2021-05-07-raspios-buster-armhf-lite.img) to = the same disk, it boots up no problem. I'm thinking this is a = U-Boot/rpi-firmware problem, but I don't really know where to begin. >=20 > FYI: if you ever want to use both a 64-bit kernel and > a 64-bit user space, there are BETA's of such (Debian > Buster based): >=20 > https://downloads.raspberrypi.org/raspios_lite_arm64/images/ > https://downloads.raspberrypi.org/raspios_arm64/images/ >=20 > (I'm not claiming any gain from such for the problem at hand.) >=20 >> I tried building my own image using crochet, >=20 > https://wiki.freebsd.org/arm/ reports about crochet: >=20 > "Alternatively, images for many boards can be built by crochet = (deprecated) or using FreeBSD's release build infrastructure." >=20 > There were no commits at https://github.com/freebsd/crochet > between 2019-Oct-06 and 2021-Apr-23. But there are some > on 2021-Apr-24. Yes, this is very disappointing, but I was able to copy the = board/RaspberryPi3 and modify it to use the appropriate ports/firmware = files. I used a similar process for my ROCKPRO64 and Khadas EDGE-V = boards and they both worked. I'm happy to confine my testing to an = official FreeBSD image if it makes things easier to troubleshoot :) > I do my own builds based on using make commands but I do > not use the release scripts for building. I build for a > variety of systems. >=20 >> but that didn't work either. >=20 >> I'm also not sure whether I should be using sysutils/u-boot-rpi4 (I = used this) or sysutils/u-boot-rpi-arm64? >=20 > Either should generally work. (But see later notes > about RPi4B SOC vintages.) >=20 > FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img was based on > sysutils/u-boot-rpi-arm64 . I've historically built and > used a variant of sysutils/u-boot-rpi4 but my history > goes back before sysutils/u-boot-rpi-arm64 existed. I > do not do anything were the configuration variations > involved matter so I'm not familiar with the distinctions. >=20 > I've used both a previous 2020.10 based U-Boot and a > more recent 2021.04 based U-Boot. >=20 >> After installing sysutils/rpi-firmware (1.20210303.g20210303), should = I just copy /usr/local/share/rpi-firmware/* to the boot partition and = rename config_rpi4.txt to config.txt? >=20 > I assume you mean the msdos file system partition when > you reference "boot partition". The msdos file system > needs to contain: >=20 > A) copies of /usr/local/share/rpi-firmware/* materials, > using config_rpi4.txt content as the config.txt > content. The copy should be recursive, to pick up > the likes of the overlay/ subdirectory tree. >=20 > B) a copy of an appropriate u-boot.bin ( from > /usr/local/share/u-boot/u-boot-rpi-arm64/ or > /usr/local/share/u-boot/u-boot-rpi4/ ). > (See later notes as well.) >=20 > C) A copy of /boot/loader.efi (the FreeBSD loader) > placed at/as efi/boot/bootaa64.efi in teh msdos > file system. >=20 > I use a USB3 SSD that has small enough power requirements > to not require a powered hub. (I also use a 5.1V 3.5A > power supply as part of that context.) I've never tried > spinning rust or higher powered USB3 media. I can confirm those are the steps I followed. I'm not sure what's = considered "high powered" but the Samsung tech specs say this particular = model uses 5.7 W on average and 10.0 W maximum. But it does seem curious = that the Raspberry PI OS will boot this disk without issue, so I don't = think it's the drive. I also tried a Samsung 950 PRO using a different = enclosure (QNINE NVME Enclosure, M.2 PCIe SSD (M Key) to USB 3.0 = External Case), but it behaved the same. > It is unclear what the dd command details were like for > the transfer to the USB3 media. So I just assume that > it was okay. >=20 > You may want to have an empty file named timeout in > the msdos file system. It allows for extra time. > (I doubt it helps, since U-Boot did load and start.) Correct - the empty timeout file did not help. However I was able to = capture the beginning of the boot process: "scanning bus xhci_pci for devices... Device NOT ready Request Sense returned 02 04 01 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 Device 0: unknown device ethernet@7d580000 Waiting for PHY auto negotiation to complete.." (This was with the USB3 disk attached and no sdcard in the slot; no = ethernet attached either.) > What does: >=20 > # rpi-eeprom-config=20 > [all] > BOOT_UART=3D0 > WAKE_ON_GPIO=3D1 > POWER_OFF_ON_HALT=3D0 > DHCP_TIMEOUT=3D45000 > DHCP_REQ_TIMEOUT=3D4000 > TFTP_FILE_TIMEOUT=3D30000 > ENABLE_SELF_UPDATE=3D1 > DISABLE_HDMI=3D0 > BOOT_ORDER=3D0xf41 >=20 > report in your context? (An equivalent command is > "vcgencmd bootloader_config". I show example output > above.) root@raspberrypi:~# rpi-eeprom-config [all] BOOT_UART=3D0 WAKE_ON_GPIO=3D1 POWER_OFF_ON_HALT=3D0 > Can you see the top of the SOC? Or is there a > heatsink or some such on it? (There is something > there to read if it can be seen.) >=20 > One possibility is that you have newer hardware that > the normal U-Boot vintages that FreeBSD has used do > not handle. >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255080 > is about someone that instead of having only: >=20 > QUOTE > Old Pi has the following identifying marks on the SOC package: > BROADCOM > 2711ZPKFSB06BOT > TE1919 > 045-23 B3 W > END QUOTE >=20 > the person also had an example of a 2 GiByte: >=20 > QUOTE > New Pi has the following identifying marks on the SOC package: > BROADCOM > 2711ZPKFSB06C0T > TA2105 > 054-05 B3 W > END QUOTE >=20 > The: >=20 > 2711ZPKFSB06BOT > vs. > 2711ZPKFSB06C0T Mine reads 2711ZPKFSB06B0T. > is significant. If you have a 8GiByte "C0T" RPi4B it > would be the first known example. In such a case, you > might want to try the u-boot referenced in Comment 15 of > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255080 . > It got the 2 GiByte "C0T" to boot. (But that context > could not even boot via the microsd card slot with the > normal media content from 13.0-RELEASE .) >=20 > I do not know if the 2021.04 U-Boot that the since > updated port now provides would work for this context > or not. I've no access to any "C0T" RPi4B's (or any > Pi400's or CM4's). >=20 > There is a category of USB device that U-Boot still does > not support as far as I know: those where the one device > has multiple storage LUNs (instead of just one Logical > Unit Number identifying storage). >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253983 > is about such a context, where we eventially figured out > the "multiple storage LUN" issue. >=20 > But the error messages from the U-Boot of the time was > not what you report. >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 From nobody Sun May 30 20:28:33 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ADA79E58845 for ; Sun, 30 May 2021 20:28:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtVPP2t0wz3r74 for ; Sun, 30 May 2021 20:28:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622406519; bh=9B6WuspKIQ7zhtRayED259lZlD7YiiyqDE0lV3wPMfo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=USaGfav194eL5+hfu8Nzx8ZY7fj7vNkxAJrtuP4qBgX0xRZ6ZEU9v4Oenn2yNJJilxU/SWxphiQU7ZJ5SL9OvnEYIOP2hriNxgxMTacMaXyudjIjim4lwHMdve6DFk2Dwxk9cGYD7UYqq8R04jhWAKNFubfB/hBsWeeSaofYIAELcq5LW/Sb1EluI3VxGnzy5MCFV/9J83YwoKBcqZeBSBNyHHiot7ZN+Wxe8uv5FlUg9Bz8hsdSeAZ1YxNKI5jA2RW6eCj0uS270jkinUehWwilKuiEliXxqgT0HpGZ0yB828/dR1TA3/Ha2iSglKfcSg2dIIlSL0iX5LqXslRc2g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622406519; bh=VfnwbxNFMDCmRenMj9KkIZIJv2jhiJ8ueBV+TZ2FLw6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PuOybQVgXjrNUfStlSXycdOkYIdaQDdeyaPMI4mVWmVHdpmA7t6WXFw0y34PvR+7KsTQGFxTpxAxCzgDd/Qawc3QvR5eIyM+gS/TOzmXLqcMYlx3IyFYku2sIzbbHQUbpVBBsYNQP4HJF7CZRIgnMyWYgdVm/uFT1CDSMd6xi06bFEBR1M7thpAvMv0jC0GHqU4yWaW3G9iJUZqLQz2zEdVcAJEbFVmuv6IzWfXHKpsYdimr10otJ+uI+M5GWOCTyQ3A0yNkDKkVMTSmrJwhzBeL9AdYIrMb1qtb7Tn7hEz93BZqBMWgIB5+4gw+OyLlfw6oz3P9uLxQ/4moWaEDzg== X-YMail-OSG: o_zGgoMVM1mhmLyDie_h3LHfYkU9EWmT8EX9micAjvlC5wzstVIkOv9JAYDNKMp rizFmFXGbvj4E8KKPekh9.ZBoGonbhXd5vjLhHcfv9NRxrMVO_Dwhxo9w64oiCWZ70zC0VSZbM_g 33HtL65A0PHMVSi_NccCo62mXE0I_5GuoS3srQ7yaSu88TLZf0Rk9t43r5MRxpx_bWQogzhoC_Xd XUIG_VZ.5gd_ICqNYrB3K5DL.RA.UDm4HgRWj4UtKAaYJsqVc81ki2uoknlitvos57zYG6YsJf8b bu.2gV.yw9Flgvxg8gcVj3yhoCJQCAjVQbgbxmj4.LWOJQG4uuDoEJeNTj0zRD75exXKJQNakJQV F_zwyFwBGFelwJgj.sO8n_BU9XWKtODluC5.NHc02MYYRbdBd99.gsyhPqWhDxTWWDg32unRSEkS Ln5pgRw1tWmW1YYjpT027yrr1NIcrqftA2FqIyR7IfDcoHahvJ6vjwypipQjh6Wj.kAKweOF_6PB .1FvqgdWtb7owaeC61D9btK4E7hBeGFnHT5z.JrpjOnPQrXnTu_t64n1yBydq3bA5jTs.g5mopsS epaAGHl46MtCJlDWxQxxAPDz5kfdIuY6w0fwMX0zA6Vq8muE946K0HcLikTyKCX.GxA0BPB4d2g_ ssGpP.eYth..UzqcsXpVL6IRIOGGFZXHtHhK_YuJ3voATm7yzg0cH4v0ibFYoukCtV746T_PMBdI 2hvIxmX2r3eYrZXiwBp3r31WFbQNpu7sEWc21phIO9NLjlNdhxMVerqspLc8F5e5kHfV3NLJhVHz XHEO8HDZ3Rqiun8tvoy6XP6B0USJV8t9Lo6JeHIN0ul1T_M83dG_mJPaO.Kpf971WXRMCforNO3I vKNR_oxMLnawnf15Fq.MJUuGFFyuvc99iUXrprJr4RWUQr5cNlRccv.Bq.Gz1PyzK7KToXT3Zf2. jU5r3sTzFY2tFraN5B55hdw5.ssMjK0eGucfYWqcHITEQwXlz6S2V6OFlj1Q5W6jQmQTw1ZAYgdw dHGomZBR8q6mj.bf1yuTFcPoCT289tzBEcMtd0lvybVrVb_GiWkAypng9vcBzbpmPAMNuQXZWfee 3UQiUZVSMrV4awyf4AWF8hb9jl0NUnr6rLqQDIicD3fRd_plrF43ml7gUCDut2y4Z_7o8qKmG1gk sn7e0K.GGQvtR7kEQ1ZTBCbNZKIho_1U4k5wVbcYc0rLW5WxhNzjIEG.NZ5QgUeUtpO0VlEIs5Bq DOTIxAEbBsJTTTEd.vMCJCuNap_bNzU9TgjyhmSayOPELm0DVEoP3SSJhJV8f9YgoWks4NzAplrR 9IWPaZshv9_NO8j8hArlx93fwQX0siGT403V1pij1cL50OsRTlbX4q3alAAuT3at7z7inKlcNVVc ygZJOSxqVniwDs5Hhbu0EyCA0LnthuMDHV1d61KyXmf6ThJHtXynH3Yob4FD5zUpbKH6mzyXPZX5 8UPPUyjGkLApr5dTnSgmiHiox67_YzsHGntPonThtLtTz_mo7J8aVDPcane.PXZClbBa1fJoOK3Z xWGAFixIqWF9kb6iHC3usa1EAS5Xdj1vplPVfJC2Dh4ZJZ3lqPL7nhsaqdkfhV12sxdejNj2GZgW I63HrqzejALLk3BiNe9e.bD0Tl8ylH1sxWPKV55_J9.woo08QB26_xRuLZrcmtA0taGKQVdaDOWc e4ZX5N94s8wmGY9_BAO.Tx9mL.oxo4vuZGULo3wbIuwt8xYFOA8l7zQp2y8VxRbBXqSUnOkeHyuU wIzKxtQg_P5DENsCnWHVue1E1BgCpJQ8w8gvmOZsZpV0s.ZHc8doSNYyDtHrPJq4eYmgh9_k6iyS T19X3Xfrez0IXW.hDa53PAyok4fa7m1CH8O3AO_nny33HsKZAfjvN3odQeiTdyK0otlk9VsEHYFs dGu4weJuh._GpwjYx59D6xmb1hrn7v4G49_7g_x8LYXA6C8ZdBT_5ltd92fV2LrcUqzrHpvQTHmQ SxI9NNcnJMF.VD7RyBgys3Yj1uvUxE2CxZ_dT_LBQsYlMGrbSnlsOaJOG4gtzPDXI9kKk0re2nH. 61.K.D40kwhuJCJrRoEq7MhXvOGt2FZD98oSJWdKHSFmSYUa_QQOCBjxKzl5juUN8y5LYDGtHTTB bxw6T.XR.pf9GM7iXaZDplVBWufB2oqDgm.VL8Wkv6nHsjYghp0SQjRijpwAeK2hd19xe9yCFF0d BIqau7z7byL5nj1PSdnAO8OjdvlQssRRRfb3B205cSFwPhLlkRWhAo4q8XTsAjkVrOMg_Z4wpi7_ I5Y3UrZzC9PmYBqeTZnMTfDGqQg4XXSbYkIobEVVBX8jNypZS3O8oghnAxNF6L8sdArMZ31xwEl. eJPItwbdt9JKF8AjDUvdpy7Sht2rVGIXLFc_Nbfv6QwT6dn7zVCTdQ4sH1gHBa3.1pBn5EIpFccH ySFiJmLWD0evnPnp7u35FYqbja5W34Ai8U9qGPr.hx5TCwLEQ0E0wbz__G2g2IgcDKqInLLviEs4 t3A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 20:28:39 +0000 Received: by kubenode513.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a67afbf4cc9904554a4de943db8dd2dd; Sun, 30 May 2021 20:28:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> Date: Sun, 30 May 2021 13:28:33 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <74691529-DD54-4E3E-B2FA-B504620E6F18@yahoo.com> References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtVPP2t0wz3r74 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 10:59, William Carson via freebsd-arm wrote: Thank you for the quick and thorough reply! >> . . . >=20 >> What does: >>=20 >> # rpi-eeprom-config=20 >> [all] >> BOOT_UART=3D0 >> WAKE_ON_GPIO=3D1 >> POWER_OFF_ON_HALT=3D0 >> DHCP_TIMEOUT=3D45000 >> DHCP_REQ_TIMEOUT=3D4000 >> TFTP_FILE_TIMEOUT=3D30000 >> ENABLE_SELF_UPDATE=3D1 >> DISABLE_HDMI=3D0 >> BOOT_ORDER=3D0xf41 >>=20 >> report in your context? (An equivalent command is >> "vcgencmd bootloader_config". I show example output >> above.) >=20 > root@raspberrypi:~# rpi-eeprom-config > [all] > BOOT_UART=3D0 > WAKE_ON_GPIO=3D1 > POWER_OFF_ON_HALT=3D0 >=20 That looks like an old default is still in place. What my output showed is the modern default they ship with as I understand. You may want to update. If you want more debug output from the RPi4B firmware, you could use: BOOT_UART=3D1 I normally do. I've just not gotten around to updating that specific device yet. That goes along with using: enable_uart=3D1 uart_2ndstage=3D1 dtdebug=3D1 in config.txt . I use dtoverlay=3Ddisable-bt in config.txt which causes the better UART to be used for the serial console. There is also the alternative: dtoverlay=3Dminiuart-bt The (or an) explicit BOOT_ORDER in rpi-eeprom-config might be appropriate as well. I saw no reason to change or eliminate the others and left them in place on the other RPi4B's. = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= lists the following for config.txt use: bootcode_delay (default 0, so 0 sec) boot_delay (default 1, so 1 sec) boot_delay_ms (default 0, so 0 msec) It also has notes about uart_2ndstage use and the like. I've never had to use these but if your device takes a while to become ready, thse might be able to help. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 20:50:16 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36998E598AF for ; Sun, 30 May 2021 20:50:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtVtT6C3nz3sd0 for ; Sun, 30 May 2021 20:50:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622407824; bh=M64HnTDvJnwBDgpzKlqy2YrbtzBoLOOm0/GM5rZEnxc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=W4MNTD0wCXBqc2S35UPOppvu82cKg8RFxdU24V85DYmY7MY+vzG56KUT6bRNU+o8D3gP1UChN5LdqG3IGWFI8HflAVNfx4/M7RsPnhItPC12yLmCRwEAVbyzmE9iIUC91Udf0cmHdHh9H2V3yYf+tD0mF8Ms236e+W1f7TuW3nyJHOUDRzXIynLhaFViQPO+p7PiImkrqapQOc1zf3laFkNypYs62Jy7xxto4OIp4fCa4WEUaOFJZXL4gioliRam/wT0tsgasFAScInTvB0cO97Hb9dN+M2mEiHsrpknxy5jmds8Dbm78GR1+EK5TOjQG5IXo1sKJNDCtIhadsKN0Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622407824; bh=652zX1iOJftI9HDmDg79GKSEo3r5WZiHbd4kDeuC33Q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=H6fXz4xSSQQSAOA/kLZgd8brXm5xib71Sn9GOc7r/+1QkJX2Bp0DgNUSh+reW4334pHx9iRECSiBgE5jv7WDs1FtzfKLlcCm/acDLbaaPqDf2+HmQKp/B+Ii2ikhuhJdSmoSunY9TSe5VzosN/lTyz5uoI3JsAJa4PP4y4iKKqy4qaHRrzIoiB8BpdP1NYYKeud2qPpCQ1yxsqwztHdO6kZaPOwb+obldboR0DjdpWp54DBNnEvrhASRdqoVwzW0lREoUi39qOHEoD+ZIv4Nub5xbJWUpJxV3m75x24iCO+b/6meHYurZjiSdxZ8dFUeumof8+JTjABgS6+NGT/y6g== X-YMail-OSG: 5fpnanwVM1mPrLxK0VbOi0.XxDKNmVF_AqBRplt6BfK9yPbCpVhHMwgXUyprPV8 teDQl9KFJKOYDkGnOvSREYDHcxVU4O96QoMm8Szw8E2pEoncjOYDwLhQixFjIOR7hXVsaW5A74tx _OgPkI7U.LGwQg3XxeHK.d.Qyh4DtPr.XxOz6Q0PNhz4COROB3ruAc5jMQ56PkrfprnDIm9Qn5Uu mTsiiTOBhNQcG6cur_ETc9YQAEUBE9nJoCpBT1pmOcvA6aVnOXpVq4bl96HDi6qQ2_0Cv7gBo7nR l.7Bi625ERHiW8jE.JuN43n2UWXPdvVsBvAkuoJXlt6ou74Pg0juAQgEfyo_WUXrT3KcLDlsGB.r dUjpN6zSjco1KuOGGhtN.T8t9EAqMWdK_vnNe.7DzoxuKS7WHe4b_1_D8NjCpitIj6lubut.rTn_ MJvoUVAFKioDLj.SIZN_6_nfoAHTOoI5577qZt0KWICR_3TCoP2nJRDv4MEwpsoIjULHqeL021fm wDVrzn6j_8XdORP7CTfuI1dJyqzP.xC8bAqs7sokajgxDXX3mfWVoIkqFWk.HGoSanuI6IbU_.Kp 45ZNs5F_g0x9z.6YqcHG6rzjVNAXBz9qH4BuXLVCf_QK2gAw16tXCsNYN.NjGoQVZiFPioQeq5kW B4o_DkNQ6.a3Hthjux2qCvFhqWrBIBK3cTwYr6rA3T5aIbcV035nyUYyfagwh.IUcZkcFaqcbsey 6AHXhSQqPUeRMsA.bkzrXwQXJwDrJGnCXS9eRV73nLz9bezwBBnhEFbHr.TkepjzUoVm58jCecVi wzZTUTUwxswJGhG2.3o.I_JraNbYonj8db4BV_qZTlrgzdUUVVlpDERvFOnHDOkr8HLUcFOwak5T GmTNr795YCXzCx8ZGTJhC7RNtd2jR5wccYdbQwlzoO.tXjgeOB.Y_mR6CF6iv3LsnSZHacqqgG5S uKW8nZDPnS6_EBrO8LoyhN8B8PfUlev3Ix.AQ8pbgt5OoiBzzg2gqK4obA5h52yYWqZ3M3nZEgU2 yIkAX0.eEzCDtZQ078AlpKnnJ4scxYKYlaMBlcKphR8BrYzS9TSFlMY1UwUSn9Em_yeezyUWmTrs GaU3QpdNOXSGXDUQjRrQY_eA1WWumRC6vF9p6ei4xOPcfekvdld0qi6OTZXGDpzLNWjOQFQ50Rk4 FSexvYQzFs2r.rVbvU6U0d9LBopOTxpI3R2I96gCBgGggQP8o4khUXth0Allfvbz_K4c9dnEKDM2 Pd6eqpkhSa5mui8DDi2j5vSVse8PMbOcE1D.4dBQ46gWKNHDwezFcdf_zMfya3uq89On90ti09J6 c7FVM.M_oOgt58w86uTarckvKygFLzeD5QiOgt.hZUOdHn._b8a_fgNtKO5rb2KCpKgCm2w8Dqr5 Pj9D1eFigENS3nEQK0_J0EGsCGz8slFCWBe.x_sudNyI3h0yIAQzcpkY2v231z_arDBaRIiOt4m1 6ZyrTPUCt3bGkuR0TvylfaufrVejMQQNI2V9VDpWekZyUs1zF8DNPwcbDJz9Rak2Rvv9BroSYAcn Zwg3SqSojJXwKrJ2KyIlrMGXorvPM4dsvmg6EqdAn15OWnRWN4rz.GUKeE.olKuZxIYTOPS5L0DX TWApEXNEwtlFCuVmtRPl0YADuCt6jDHUDZ5Qz1Cc9TviR5XMIHNx7beHSODhUOsrcovrFQcQaHsj ktES4wnhHqRpK5er35FZj_vmroYK_iIm7JnYkC2uOMNN.olkAyusM_968DbCF1oXY4F0V.s8e7g3 R_ptbO3EvC16La7tDQ..9MB5Z_W60GEiG7RujjpAMoPVosWDbIwQcrVGVfv7QHLnP1A.PITiebgF LARs.FQ6fVtdNjWaaDYJU4U.XXfwxZTmYojUCxtyceK_e6.xuZWnovmKupEWK46hJjZPuCwoZXbz Z3J6w6NlqqxmUFWqy1vHHpBXwC6wYPOjpX_5JzmB6HXgo3ZiS_ZhI9E1op8xae2pzBu.Meow5604 SX7GRdlbNp.IF_i_myZUXxUxMb7srNtyYg1DTpPtPDr8ZYbW0w_BfG09jz7SazYmqst4XSFj8aCt 7mTDvBxXG_LokobYWriI6W6y6bc2F5daT4iRqs6iuPMlQ0vMPqd7_UqvS9FfGSUCjY3yi6kiSkAs klYiyfTqJFIiMqHussUWannEIptpoFBXK.uGiJVzHbCsWnqTfJHehjdtJGbj60HM0bHp_JGUaLOE pUzBCeDvlYYYFd6EMDFeCPbuc97ObLMeEwLLxm4zzbaLdRI4qIOw3M3cJxXAGGRvS5HVGBmkspWL _2.NkESL3lnkBZas7KYBbw_zcdx7nL9kUX.QhM5VqwusB.zBn_.Qtp_clQWb56MZ.iC93WYwzO0y 6Pt0ugAGRaVG1QtqHoB_SC3dEe27AQgiW1zAKw0cwZwqgqPOmfqXMj0sI6Eaux8Ot_z8vk8FlrSS LmNM_NY_7tr25Ql2n2FxQX_A- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 20:50:24 +0000 Received: by kubenode566.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 73f791f2f5c18471f967fe4a0b47ba09; Sun, 30 May 2021 20:50:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> Date: Sun, 30 May 2021 13:50:16 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: freebsd@dsllsn.net X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtVtT6C3nz3sd0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 10:59, William Carson via freebsd-arm wrote: >> . . . >> I use a USB3 SSD that has small enough power requirements >> to not require a powered hub. (I also use a 5.1V 3.5A >> power supply as part of that context.) I've never tried >> spinning rust or higher powered USB3 media. I view the power supply that I use as just giving a little more margin, not as a way to increase what the devices total to. > . . . I'm not sure what's considered "high powered" but the Samsung = tech specs say this particular model uses 5.7 W on average and 10.0 W = maximum. But it does seem curious that the Raspberry PI OS will boot = this disk without issue, so I don't think it's the drive. I also tried a = Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 = PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same. . . . Then you need to use a powered hub for that device. = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md lists: "Maximum total USB peripheral current draw" as: 1.2A , which at 5.1V is 6W. That figure is the total for all USB devices attached that are not powered independently. That document also says that a 5.1V supply is required, not 5V. The power supply that the RPi folks supply is 5.1V @ 3A or 15.3W. Even the 5.1V 3.5A power supply that I use only multiplies out to 17.85W. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 21:00:23 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CFB5AE5AC0A for ; Sun, 30 May 2021 21:00:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtW5z5hJ0z3txC for ; Sun, 30 May 2021 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 92E9023B9E for ; Sun, 30 May 2021 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14UL0Nnx040217 for ; Sun, 30 May 2021 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14UL0NZO040216 for freebsd-arm@FreeBSD.org; Sun, 30 May 2021 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202105302100.14UL0NZO040216@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 30 May 2021 21:00:23 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16224084235.6e3B.39606" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16224084235.6e3B.39606 Date: Sun, 30 May 2021 21:00:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. --16224084235.6e3B.39606-- From nobody Sun May 30 21:08:20 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 18D5BE5E719 for ; Sun, 30 May 2021 21:08:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtWHM0d6Yz4Tv3 for ; Sun, 30 May 2021 21:08:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622408909; bh=ofuDGfKI9dV/EJcz2EySF/S0lQVdb5XRAH4sGydQBYY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PuhYlnRKFJanEF+6wmQYt938lpNXcvzK/J0rDYUuDAMFVyIGasQ0tOMP/TSQC0+YLfl2CXZRpH4D5q/c79i33kmwaRp7UGm31kfycm0AXJ+/+UR6/3bhpRfkC9dy7JlG4LPAIMsbZ2SFPMbMhgA5p+1FgnNvKiPgbSh68oLOt8u+uc52UtO5LWrO5/CHi0KhB4ynyzh8C1FGMvxfZFlulkT5TCP6TJbXMNC4PP5mFUwq2SUXszleMR6HAnn5nK/kWenlna8RKgJng6CsovmZ8b4d+Z2XrRS8kjJcSJavHblQUkvQa+sEipa5hP62BPlj0H2eI2BUdS/3cLZSBch/DQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622408909; bh=FbDKj1VR2FzFlN+wLQYvcbKs9v2AWi5659FDtqkgvjZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EjUyctrfDMh8R0Nn/ApqC8TERFkbNGhFqtm9hnE1DPS0RTcdtpjvHQOkXRSrh4KEW1bZlWT09bbhCgna7085TY4Hnn+XKqqpdy6NrF8nlTkYp65J+i6azE7SeJfl6afmoNVFODQRev+zCwe6r+ejUlqs569hXzldSTvDd8ErQexs0Fdjt12FREYZYXH0yBTxUeX24U2nhBRuEK9h9i2F3uwD6UbTBZJJ5RgdWvvggGWq2sPjbm89AYZHyP+LoQXXc7g/GQNyei5aG/i5AK9y0wDMe89Zl3973q/IUeehyrI0/SCKRz6XQjkKY5WLRu8fTQ3YLkXRVbt2vNoQlqvS2A== X-YMail-OSG: H_fzTu0VM1nEhakA_BIc1ywE3lSj8zEdX2zUZlJNRsK47QWOrWixzJUzq7zYO7P MC_.hWB_x9RUo1E._Yp.9iwjFBoKuSvBzZzGsAsnnL3HxHt3316S1fdCGnKm44xx9TwC9apuvCu8 pJp8tjIltL8naGAWMlSawHeitXu4WOuzqDR2qHEsTM3S1FFHd8LAbFRSk6otTkt_NHka0OENNDkK tVkKpbRAwG46iNH3abo3jYL6IfwSgpfdqh4AIFoXUvOCQpxrTzGWSelyzu3J_D78qlbnWsVqXp_9 2yM8kFJo9AuCmqi5MFAVeIY1Wo0EwjSF8eL8TTGrvNSvUpYA36RI3vb7sfndoSjOM.tzoAMEVjx1 oyZMCF21G5JAMTkns3EDCjb1qWH_SQVRB9_NmAkVfsX4tdbXaAv5h4XIPwdjDLZWxwtc48Ts99wD 9nJ7lLoRU0WTppQb1o9aq4ber3uJtUzdfZzvxQ_WUJs7bUTxkUKld8k4c.lQ68olJNk0NL_2Ks9u mrWL7kYm2opueXLFyx2rVkKEOYhSlIy4CNa2Zl7dlmbaTUaAerxi.6xxDHDVT87d3kodmY8RjD2j Yc1I34_T7Z3gj_xEc7kE_O0VspdZyeJpFF92OBOq_iNT1ei9iOccY4KA7FTgvnviSNvJXaoyW5R. 2PC0WhmNSrziTmU0cbFX4YQJSCQlXOXOq.bapnfua._vW2D1lCwPY.45Z_qmiM8DkQIZCqh8gBWP jy9olXArSVZ25TA2l9WpO0k1xMFcuciMmzviYZvTWMvJCDTOlqW97buBB2Lw8zvKicUX9MZna7oK Nr7U6LI4ZYp11rdISO80xYMd69Wc0t6CChNMp85o8rWrX0E7yG4Ly27Z0Y4ZmHxXYelI1eDRGA21 tjIkMiMTrGEljdK49CLuhPMiKQ9WWVTAdyqwtOm5eerd6ZfxI8PkPdeNLRuIoa57KYVxwioaHOlC 3.KK5H1j48lZOTbp9wUHJbZWA8LR26G07vWlR3Kg_iiwjB2s.VkIzYf3SctjiZqB_UWuLqKN.NVS WWVCMTE_mxSOlYYZI1JE1d7NCd7FYlG1ZpP2ShWi70PP5xhp7psPCkXniTd_fVa5evyvp2HKcCet AE4etOB1MB9ggDGo1Tgt2v37jrMQ12Bl8uT10ckqqHzdo3yUDKIlkwtMZfmD_a9uYfBEMu_hAAWx WtDaCY5k8fVXAvvP72t.vb548zDZ_TNnf.7hFKxTyeggj_uRFVYJ9IGxFcKDJqUtAlHIB0YHIc_Q QDbtVOeDMkHAXk6LaGl1aEezRHiWC0I0mcFf4jlQkQNU_5.0RGNT8zk3XoTT1yQmwxJPe7LPyLAl TEEZ0PQE7.UofBRrT6O3EBZ2rMmQPUvVRTkCfF0ULuMbF0hc2Xow3nV2ooZybnL_yp5YLSV7kdWZ jxyVlK8641LatDFT3fNb402hpRs9EVH_6CcgPptAKzOOoOGX.wu9p3DKOMrkGhZD9q4M0BU8JUag ohPnVRE0891PZhYbst1xsDawrfLMOLlj0yvkLUtx2H17Oh7X4UXPzgvEACWrg0P5R6Qlwvu1wvZz CHGMh1pCJ4TCRuhMGfsWaMGf2zc2dq4_Vn8W96nEFpoHmUZEy4T2GEOlHoPOWA58JTU17AmvF6b. Ya2b6sEog.rGAN2VY1HSUiIr4_o8Paw_kYBVtZUrY6NIdP2F3dZr0uVKa1OHk4acilD.MmkZ4805 Tt52aYbsEowflLdiApHMOhO5JqYzJfPC3CDZFtsooW96k2zCSvB7RxTmOUVjoin2dzb_olIAdGhl q_.pc_i8SOPLJomEBrmkGR2oZbuCcjVwRw2gCw5_Z5ChB621nCp3R0e8Ffww694AaQEfmvbA8uFq X36jKNYuZNMj6_5wh0.JkcDDcVGq8LXpQnjd6w1Mx2UuEN4j98L6A7VVafMthFD7Ts4zgpYV2_m7 ITFsZ6lqLIU2H1xrYcbfiCcHedTULx6AVuN5933qW5vFBYLr0kqCrB_RQImXaXavOpQirImKCH8b x4TNde7iymMLgYrvNPqu9tjXJygMvOwVoLZNRUpi7brJ4b8cnVs4OkeUwETFDjL7IiygtDa3NWva QZYaPUJ8UT6q1bXrYtUkLBHoIzcL3aOyfFMZ7Z3hsZWOokT0Cjl9MgUROEYvpnCDbzHbZUKe_ONF zRztWc8.JNRxdU1IT0iH_nsd81M4P0uOEyC7dJm7ZFZX3aBhXoWzSjc8cMpHzzILYtHY1Oaf7dsg xmLU4MNUuNkSeA689Mw.0llcwsQ2IpxSpL2Mb57_rARKTTehHB6Wtg6WHxsF31mBBI3zP64hE6a0 LR1R37fle6rziXdQyrQrXRmT6WnX1_qN2M93K.t85Jhnfc8AtoKj9.cG.BruAYfyTVzAleseUKjL PJAy.tTlNl4h63aZLXmmWRWNnWH3rwJM9DIwViGrpvConRi67cxt2iZ6Ktz0F85V6UfpizRTVdXs tYdczEw0r460xJt3yVhHPrr3TvPkuC6OSjxrLWQJcgMA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 21:08:29 +0000 Received: by kubenode561.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1d889a02c927d93b764b7da5be598b29; Sun, 30 May 2021 21:08:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: Date: Sun, 30 May 2021 14:08:20 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtWHM0d6Yz4Tv3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PuhYlnRK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.46 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.96)[-0.958]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.84:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 13:50, Mark Millard via freebsd-arm wrote: > On 2021-May-30, at 10:59, William Carson via freebsd-arm wrote: >=20 >>> . . . >>> I use a USB3 SSD that has small enough power requirements >>> to not require a powered hub. (I also use a 5.1V 3.5A >>> power supply as part of that context.) I've never tried >>> spinning rust or higher powered USB3 media. >=20 > I view the power supply that I use as just giving a little > more margin, not as a way to increase what the devices > total to. >=20 >> . . . I'm not sure what's considered "high powered" but the Samsung = tech specs say this particular model uses 5.7 W on average and 10.0 W = maximum. But it does seem curious that the Raspberry PI OS will boot = this disk without issue, so I don't think it's the drive. I also tried a = Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 = PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same. > . . . >=20 > Then you need to use a powered hub for that device. I should have just referred to independent power. You had written: QUOTE I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 NVMe, = attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. END QUOTE = https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-= 2230-ssd-expansion-board shows that it has its own power connector and has an image that says "please power x872 via DC Jack of XH2.54 connector if SSD is not recognized or low power". Later text on the page says: QUOTE Specifications: Power Supply =E2=80=A2 5Vdc +/-5% , Powered by Raspberry Pi USB port =E2=80=A2 5Vdc via DC power jack or XH2.5 connector, Extra power = for the SSD END QUOTE So, if I gather right, you need to connect a power supply to the X872 and another to the RPi4B. Another image says "Note: NOT recommended to use SAMSUNG SSD, if use SAMSUNG SSD, please close WiFi". Later text on the page says the same. > = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md > lists: >=20 > "Maximum total USB peripheral current draw" as: 1.2A , > which at 5.1V is 6W. >=20 > That figure is the total for all USB devices attached > that are not powered independently. >=20 > That document also says that a 5.1V supply is required, > not 5V. >=20 > The power supply that the RPi folks supply is 5.1V @ 3A > or 15.3W. Even the 5.1V 3.5A power supply that I use > only multiplies out to 17.85W. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 21:49:01 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A9590BF294A for ; Sun, 30 May 2021 21:49:12 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtXBH5PFLz4Z7M for ; Sun, 30 May 2021 21:49:11 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 14ULn1Db016578 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 30 May 2021 17:49:07 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: "freebsd-arm@freebsd.org" From: George Mitchell Subject: Oversimplification Message-ID: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> Date: Sun, 30 May 2021 17:49:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjKQKwcGi5tItt58aY56KqL0z4B4HVMjG" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4FtXBH5PFLz4Z7M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[freebsd]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VjKQKwcGi5tItt58aY56KqL0z4B4HVMjG Content-Type: multipart/mixed; boundary="xQhUCfsdlOTOfRzgY7aoFYSVPIYIdU3vL"; protected-headers="v1" From: George Mitchell To: "freebsd-arm@freebsd.org" Message-ID: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> Subject: Oversimplification --xQhUCfsdlOTOfRzgY7aoFYSVPIYIdU3vL Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable I've never been shy about oversimplifying complex questions, so here goes: What's the ARM system that presents the least hassle to a prospective FreeBSD user? Here's what I mean by low hassle: 1. Widely available. 2. Runs some standard FreeBSD image with minimal (or no) tweaking. 3. I suspect ARM64 means less hassle than ARM32. 4. Friendly to an external high-speed (at least USB 3; possibly SATA?) disk. 5. Hopefully 8GB on-board memory, though 4GB is probably okay if high speed swapping is available (see point 4). 6. Affordable, but not cheap. And next on my Santa list ... -- George --xQhUCfsdlOTOfRzgY7aoFYSVPIYIdU3vL-- --VjKQKwcGi5tItt58aY56KqL0z4B4HVMjG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAmC0CE0FAwAAAAAACgkQwRES3m+p4fkX Vg//fFOl/kq/qDaj65BIXcvmgYoE5fKdmebNeb9kco4hwqjR+uIV4iCoiOoNMrPbNOoZ/5xnlkG7 bVoiJUi1aiyJbCoM2xovsEnewbaetZnRE+5g6FN+v5Xmue3vNsziUqizSVymw/zKopAj7RjQVYvl FbZQ4SpwDoiW0IfPZCuNVtqAtDkhaCNkh/HleT1/phXsAJcBgOCohl4qW2KLPUsMkZ4W6zM1hptE +en3Jr/OTRADtSWQWGSToqxtOikxwF4yK0DFvGupV8dL8N1wHT+pW30IxpGV+Pp+ybbRFkysHzs9 Q+ZSwn0nq7KNKnZbWwTO95VTAVfULtfpwJjDgnnDYm/qTxMUWeGNTh9l6hEeMdFItCKCbzGbiUyo BHLN67PpR7G6OKruvWVQTKq7jCRDrikTaXx5OTsF0tmX2lKBrXfGr54DU21IfBOPMx/D4vOnB9IW TozGS/bicvkVg/WdTThXLSYUUB2mkgJFaOwdk4oa35ljyh3sT4Qrh19P0wB6zoRyQSOiWynPyEkK j5sbT/Q11ea6p0DNgDvtuo4fQix+E3z1tAftvumLUmBihdufe+kb5Cl72RZTyLGWNBFNsVYOfHrC Nd11WRQv+KoTzDriqjNrEMQmcloybeVFwZ0XXg7AF3AynHc3o7LxS2Zi0X3DLLgixdpyIUhGF5H7 +2g= =b+/M -----END PGP SIGNATURE----- --VjKQKwcGi5tItt58aY56KqL0z4B4HVMjG-- From nobody Sun May 30 23:25:23 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F3664BF7CCB for ; Sun, 30 May 2021 23:25:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtZKW4xfMz4jDN for ; Sun, 30 May 2021 23:25:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622417133; bh=qEzA1Bz0MJN+MwfHhta7P0jqXwkYo5OU7bH3TwX6B/8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oAoVMbcjG9M4DIHs82G3kYc34jMw5MOs/NnIs12fqcWr9jiP8UjS/3TZOBeXTnxLrtKuOc5n4L7JV+Iqv5GzkqTSsycG/H5wD1qkmH/ZB1RyoTpoZR7iTijbvGx70onocs3PH2ehyOGSImnncT8wRwjKvtsy3SbabOa7dEx1g37mQO0ljHu5pe0Al42+LHKxxrggJBgFX0Qxcl+XJjSjUXib/m3Fp6uvMsB/AmJCet5huPsnyiRDcB+y5XhOB7Tj7YI0C3eHAdJqwPB7oO6grpV7ZT1ZLrAROOGj64YBtaI6zDo+9D17tjF6SbAcFvUZH7LAKWP0kQzGsxWIbLq2UA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622417133; bh=1oE/v+Mx4DdrMf7HAYnJcI9b19db9rzptZJS50YlhY4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=khZZSt3/8rWn0jI74ap4vb15UVFreXUH8ThB+K3DzgL+P0MwlCLOBWk1tnFVv1Eaoim6WqpW1/nNe3nuZgrGvY/Ul3Uux7qfIe0U5R2GdEaTJTG2eN0gmFT3i7tAIxy3IDnFBNtz5aIQho2NgYqYNsJfYfVEOpxDI2XHvXFjrPOzYwFxqhccuYMAOR2HJl2WvqT5r5nhosJcoXQRB8cbFrjyMx8KmJ2lmLS134TXQQuOyLX2vRNHlT2ZJfY/BK/RrAoMon2TkH8Lj2nz8o3vOZp7KqSLueWoGJwRm/9Uyf9mNwUlV+YWk2SM2z6sdCsBuomCA2cxk5bFDNe8cp3JDA== X-YMail-OSG: iAwxTJcVM1nGoSdlCbc8gqNiiFkNHbZr9n_PgID1KbBNz219ciCbBXTFxBQfbUO Vy2WrqWoAjo0fnxy_gE7alQBZE4U7fhHAouSIIFqXygfM08XXeS2XX00mTITjiJvLV3reUQvYnOx XRiNspp6yxqfHmiqPeYZT4fLEJrboC8GYERqaG6xDOrPqKzoxd3L6HKhe.Tq.coaAfXfOy6c74GN QE4jNTiGr.CH1.mexQAbqnDeJlgFwTFnHvzdGye5gYknkHURufF7FYBmYy1IIKwr94.tSGSweX_B 7pVJpMYhCycdcsieCMS6nrJmQYaPUK.bt4luDJmfHjT6_BZPovlPqw0eRDpHByLfWPMOCj2G_sAD qtHp7c4iyDELr5s88JIzis2SiX0G_xEoQgm2dO9NOoRzF4YPtRAvWH4YVKq3kybeIDJxCu0GGRMc 4Hyn5bNqPQvd3oXln5_tQaxWV9msVhkrL8k7B7tkEZtf7DXGTZ9_u74.lKNt7eJ17lY36dNZq49A Ju0mkw9u._f5QLI0rM3Q2PDetLdeKaNERoWaotnfbbNFtr_hHXo_4.YPJnwOXALJfiIkrmbnwEPK E.jQV3Yhy3ptJMkXOs_2jynAEF5y1eQVrE9lF_8JPAMsIO9SeW31.lEyONhLq8AaJFlLDd7RJvym HQ6Lw4JDpx2aCA0jHq8_aokAu8VD97KuUO1e8k.7YbFQmBs5pIv4nNPgoKIq6a0NksyGOoxLQxbm yRPiLkGbOOa_F.VPVhbRamHhrqhbyDUN5zkmu7v.TelKJ6h8WqkC2NVymmJiUTmV7fOFsltehMaM 3XT2RQni8fZrpUdFHkYHCB1XMhIB5P900YjMmQS.Ywr0xvgbAleforp8zWpzOeV4AqHQmXw6Bgpp dSfL4ydjq6spC.Myn36bzGcn0ldo8.uomUDzJR4fOWFBXnbnaANCnLBGSjrVkt9PqbXU7v9o04PS 4ygdof2v8gUa_i88K_Zjc_2JCJ8qjXKL7Mczn1UEAC8ABB02OBDH7Es6paaaSJkL5XxuWAUMlxoO t_AwmBQ.OvVX0TfO.Fuluoa7tMb5dQPjfGL74t6Hs7HY68dZM7D1KJW9Qv1FgGMN_mIuXCU3JVNZ fyTmQO3tc0jaF8KEGUul4Rvac6XTZR9hu5gI0ov.RxMz2M_oL4Wf._XYRQXFvJTGpdhWkSl.iYO1 dYYbdX8rCNtpjL7RRq8VRb1.fo2XxrWfnKXtiwkCN0n2oWwY3sxx06aAZHCzId5SRBFLcsAZqC2E 5OQqtpnQmXo5gmB0SYsqYm4RnSPNUO2dtocb3DUa3zqwMXPSimSRHHxLHdbLdoNvvjyxICvXdt0D Cx9KCEA6J5CxOxupqjZOC8iNLR83IQahpM88o2OdkQdFI88.3Ea88CPxrrY9bfi916Hiuc.Z6YTL hOoAqP6_RyXJ43QoIl78gIKilSieCeXkd43gxNizQnQJ6yboFEiCYfFNSvHQ_Kmt_ruJ..4u.rCd pnijTEOO3Wyrkl0Ulst7e.OlE4uzjCs5GI4umGZLiEZOXJop5lg3XijfuHiTHfytFx6qN9__MbVv i_Wy8d4ZzhRiOnuLDwVrbdn2FvUIUPczJuMxpr6iRBZ9Fntg8hJFM1LXsEaD_ZTz9Lx9f.tWQm23 AGi0vQRC2W5TiinAO16Q57Eo9RH.KyRxDg6f3osC5sFGvrU64DkTM316jp1YyHRp2Tj52H.Ubk85 2xxRhzq2CSQa4g4socmfobEixCZZrxLaZKanRgJpsSJtnI6oNGUd3x_8QTTmteO3PfBN5YF9FRVF RA9m1mZRYNuW3qKa8SDKVk6BGYzEiOinelo3tj49e1rN9WMdwTpf9QxDMSsvxjbiZlPvJgdZY3iC fnpGfgBAJ7yoIrvPW9phGTvbLQyi4u4POin8m7a5HcH1cJ1LVSwq9A0XYP.gtIEBZ64oJVv4Oz9p 2_I7zXAd8iM6x3WIuKrS.lT91g02GwrBKTDxUqdvLQT_i0nhxMsr9eVU2Y9o1l6YQ7V7FVchPSwy GXbz6Qazud1lMRr9tSgJf7Cwy68itlXW.0kTlLdl0a7Vrsxxf2BBE6Wy1k4_HplEihWHFOmhtjy3 0b65qJ2KqHnEBaa7SL38cjLfxSatH0jlTNW3FlmqeEOFCKH7R45QzBJBNdxTAoaforGHeZO_5aNo HMAE8X9mGxsBgxyVoVWjcp__wgs0TNEVavqlZ6PO4b6f.IbDBLvIlQD0YOF.rZCv6PgtwEVPiwJ6 AxltUqVX13o0gwgzdR1de1KeHs1vCr8if_zHQtindEnVxKs2i80bXe84vjh9y9httiUrFIC9KUFc roM76At5xlOYAnmcdYnk7qpH0y2O5btxrr2oOQLbciAfrtCrql4Q0wJ2_l1KeE7Vi.ejLcseWxDJ dCaY5Qt0NKCUtK527X76u4pJcy_nzm9HBHwQrRcVdvvWBJDkBx5njugXVtfgQSSgGpArnPYwLvHV Er3tc1Mg5LMTRS0cMpbaxYkQlkzreKQEtOF6ahgpa6CFQnJ9eSjf7QypeCQPcR0aY_fvi54eg8sM T X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 May 2021 23:25:33 +0000 Received: by kubenode544.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d9a79c09efaf450576e7f89aed147e93; Sun, 30 May 2021 23:25:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> Date: Sun, 30 May 2021 16:25:23 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FtZKW4xfMz4jDN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-May-30, at 10:59, William Carson via freebsd-arm wrote: > T. . . >>=20 >>> If I dd Raspberry Pi OS (2021-05-07-raspios-buster-armhf-lite.img) = to the same disk, it boots up no problem. I'm thinking this is a = U-Boot/rpi-firmware problem, but I don't really know where to begin. >> . . . >=20 This does not involve a U-Boot at all --and also is an armv7 boot, instead of an aarch64 boot. It may also be that this manages to use less power on the SSD during booting than a Firmware -> U-Boot -> FreeBSD-Loader -> FreeBSD-Kernel+World would. RaspiOS and RaspiOS64 boot a kernel*.img directly from the firmware, without using U-Boot. We already know that the firmware was working to find, load, and start U-Boot. So this boot does not tell us much new about the boot sequence that is used for FreeBSD (U-Boot and later stages). The issue seems to be tied to U-Boot's stage of activity based on your reports of the notices output. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun May 30 23:54:29 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F7BABF9066 for ; Sun, 30 May 2021 23:54:34 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from mail.disillusion.net (mail.disillusion.net [96.126.127.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.disillusion.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FtZyy1Vhnz4knt for ; Sun, 30 May 2021 23:54:33 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from roast.disillusion.net (localhost [127.0.0.1]) by roast.disillusion.net (OpenSMTPD) with ESMTP id e79419a7; Sun, 30 May 2021 18:54:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dsllsn.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=drip; bh= KqIxGCEqftRhFOoBTOBQ0HPo7pzwnUdxONQ3Og2OuAs=; b=tLs+CFJrf2n+KdsG wz1lPExSOuoI5Terj/offnnVLv14XoEQxC3A91Jok4Ff+iwpHcfW0QnICtiuQlZs iGUyUW+VZLCBHcAYRcyfmE7zfXPk3sDnB1mkG6Z1FK2T35wUaEwNuP/YThJ244Jo DWdGouICuCnmbHV/D3Wy2ADoWuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dsllsn.net; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= drip; b=MquOvvsuXvMtaPkelTJ+b3Bg+Q61wFk73Z9owmUDIih/HohwRr7c0iXG cWLPY4wk6sOI/W56VspME148WlPhznkCS68/V78wnwwW30Z99N7wkpRw4Mm4m3H1 HCaItfnrsCXMVk9lR0CQPUS9l+vV/ak4P+FIHdY7F6zxy8WPUVU= Received: by mail.disillusion.net (OpenSMTPD) with ESMTPSA id b4b61943 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Sun, 30 May 2021 18:54:29 -0500 (CDT) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: Date: Sun, 30 May 2021 18:54:29 -0500 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: Mark Millard X-Mailer: Apple Mail (2.3608.120.23.2.6) X-Rspamd-Queue-Id: 4FtZyy1Vhnz4knt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: freebsd@dsllsn.net From: William Carson via freebsd-arm X-Original-From: William Carson X-ThisMailContainsUnwantedMimeParts: N > On May 30, 2021, at 4:08 PM, Mark Millard wrote: >=20 > On 2021-May-30, at 13:50, Mark Millard via freebsd-arm wrote: >=20 >> On 2021-May-30, at 10:59, William Carson via freebsd-arm wrote: >>=20 >>>> . . . >>>> I use a USB3 SSD that has small enough power requirements >>>> to not require a powered hub. (I also use a 5.1V 3.5A >>>> power supply as part of that context.) I've never tried >>>> spinning rust or higher powered USB3 media. >>=20 >> I view the power supply that I use as just giving a little >> more margin, not as a way to increase what the devices >> total to. >>=20 >>> . . . I'm not sure what's considered "high powered" but the Samsung = tech specs say this particular model uses 5.7 W on average and 10.0 W = maximum. But it does seem curious that the Raspberry PI OS will boot = this disk without issue, so I don't think it's the drive. I also tried a = Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 = PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same. >> . . . >>=20 >> Then you need to use a powered hub for that device. >=20 > I should have just referred to independent power. You > had written: >=20 > QUOTE > I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 = NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. > END QUOTE >=20 > = https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-= 2230-ssd-expansion-board >=20 > shows that it has its own power connector and has an image > that says "please power x872 via DC Jack of XH2.54 connector > if SSD is not recognized or low power". Later text on the > page says: >=20 > QUOTE > Specifications: > Power Supply > =E2=80=A2 5Vdc +/-5% , Powered by Raspberry Pi USB port > =E2=80=A2 5Vdc via DC power jack or XH2.5 connector, Extra power = for the SSD > END QUOTE >=20 > So, if I gather right, you need to connect a power > supply to the X872 and another to the RPi4B. >=20 > Another image says "Note: NOT recommended to use SAMSUNG SSD, > if use SAMSUNG SSD, please close WiFi". Later text on the page > says the same. A-ha, indeed. I just noticed that as well. I've gone ahead and ordered a = supplementary power supply and a lower-power NVMe to do more testing. = I'll send an update once I've received and tested them. Thank you for hopefully pointing me in the right direction. > = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md >> lists: >>=20 >> "Maximum total USB peripheral current draw" as: 1.2A , >> which at 5.1V is 6W. >>=20 >> That figure is the total for all USB devices attached >> that are not powered independently. >>=20 >> That document also says that a 5.1V supply is required, >> not 5V. >>=20 >> The power supply that the RPi folks supply is 5.1V @ 3A >> or 15.3W. Even the 5.1V 3.5A power supply that I use >> only multiplies out to 17.85W. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20