From nobody Fri Oct 21 20:21:59 2022 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 4MvG8v1zR7z4gjHW for ; Fri, 21 Oct 2022 20:22:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4MvG8t17WGz3TK9 for ; Fri, 21 Oct 2022 20:22:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666383724; bh=xwcmgkR2N86rBBYriMbE+p7sI/4ucatOy4lYR8Lr2LM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qJwTd+vhj1gfdNKAHtPDVBlW6qZsVOvirjyeFbqBGn+DOYqjtcxztryMbpqBW0uffWuXjNJSyOXxnGLYuO9YnTVg6I/fLneuLfkfAcS16eKLFcqCg8KMobUITkEmK24fUa7N73PNtjTGVhTEsSbFzb408eVYJmq1qtKVvfL05IFvM943XMJzvZ0RaSW/Aew2jInwbB/zJQK2flrFu3CBSAxkYFMbKZMeSPScDTUcpr2i9ZgvF66Mpm57VgP5omNiNeS5A7620TigARi6xxLU0oWo2NC6/0l3mGhRrdVrQqgjoAumNtIMO+rCBhwynQB6w9vUvX17sNSN2/KVoKONoA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666383724; bh=6TlVrHlf5INDX6EexaxhkJNlAjRqa/MgPKrmTeJnD7j=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=IuRYboCi8NpjyEe0bbPOTQf7T9UKdq8yt/YrbO4G+qMUTV9KR70Kw1CnaIfkjcfCas9ITkdmTyfRlrkTaVwFsScxr6Dx/4gxtObK6zpQ8FX4PDUhtU8hmmjaAmJQasKcIoUFrBDIhVi4jMyJtmyzWy3CRKMShn7Z9sy2DBRXSDooLQ660v2FzwSoVddcuED4eRrFphGtPCHZVt6zhi3+b1QvWJ72kGpeFZyjtfZxzxggvEWb98bLvyJdLOLpT0iqWTuwefNYIrksoTWRurNQIe56i2hNojnsvVtvvV+Fjs+Sh4IJuQli4WpUDI0t/zfFnL3qBZGiBZ5jOO8M5GMlkQ== X-YMail-OSG: bY0dX1IVM1nJv5x.e6MvP9O2AnzCJdYsHFvhjasMMve0PDQ.PT2JuehSw7TO7vI LSSfsjPniPuPi0liL7UKVOxl5W_qJv9pqUVpd9lBhFgD3jeBuz3Z7LKA_JkJ6_RJjgyC1Kj34E_f UzN201N4ltb7_Px.3XsmozcYzdjXXPpHn6rIjjFc5N2NnSVI60t2KoyWr9kG2Q7PRnutSVJZtiEG OZ9.8Tey.CTn70f8dYrbukccFp.hWntwh_WwbmjnlMPZfSchNKy7.3g5GrXKujcKsk3wT5NFcA4W Jk3cS2H3HWndg89NbT0QOv5E7EXy9hquGfbYBoibEDIy3uh4ir8khyi0rI6HsNgMb8mZgNdssLdw fBUWLwPFI1T1KGECXyqDfb_m9Wafy.dMQq1yvcLbt9db46aawO.yLIINpzEQ1irR13XpA_PM6G2d NebeRw1KXtklUVRVkTdkUo7XQ8SsQkBgq1Vq7y9anraABYA25WECVOYPZgttBQNH8sa3BhVGIrSn gLiMrSa9VEOmJuMHUjIhVbWXCUxjNO3aO1kaAir101NvW9f40cnZH1oUxB42nRdccIqRFtugeoBg qnrwuDK.devOlxcROKgYEpCxahUIQcT_Q1kaMsap500jHE7_EraInsYiJ5GVDjChXNUtpCPIhAbF lwp1pyVY2M1oTHTk015vIv7zG7B_USv3qYz4FQjl44lBBXlwPyzsxltnEeWTUBotA_jdbZG9CWp4 sax2oiQ_pFyGOEVfYaovNNoh5XHGl8dNva1cqmlY7UMOhLYd9aWYCsu.iwvaSz3MMqFzCx7xwuLP bAxpkG6zGwYB3QOsOF2ZfpJatD2H.ywpd.vXcKF8vZySTDb1hHUW1JIO4KQzRf5duxQHhEq1gGMi GcVx19N4.HkPVcc6O6BDl4O7HwBbsG9fVrE2sN.G0_3nglimtXA0x5IgbjOKFA9rmgrykg0G_PT0 L17BRTD7VhHCy9hs.Y.0s06gxXL_0lVnx6Ds1XL4R6r1a23SU31C9CukMasIs7xWmsPWhC5VeorC U.91Bh7c0c0vR2mhNnd3n3F.dmL7Mn7V7k.dd.ehvqUUOMP83oGkcN4DBfC59n829JCDe0cO.elQ V3KSxP_obxChYMU4x1MnJxs.K.8uCCdzhyeHHgK106kTBZJHB9A1eIXd1cg6WQp8pnIlV2dN4Gw8 B95uziOK7Jcg9f4I5.IntV8U99KpUeMv31Qf2MYUkp3aVl9YkgZWytlw_yJK2onwwb6HpkmFhAqu M.clxj.BJ5YeDdW1yoGAHNhJfVNKwM2I70961uJWWkh6rUbZeFQZIxdqYPdfgz6KWXeBA12HX4vJ pAisk5bYvOD1UU.NFjKoxRaKvxrnpCXE2mCvfE7PF8bj7JOLCL4wA0utDbBg7JUY.AoQZYljohDw D6q6tOmmPpSB_cJxiyobGpjZOHYoFv78Dfa5.lyd6hZsvph0yPGu.XfyOs.7GCy0x8ewU9egq0GS 9X1hZp6mudrjctQ0bj2euxypSq3u9HnGesOx0bQLE9WSmyb4CxQZbgnKbXBg59PwEndXDTBC7_KC RAVamoSPBwPK_uJaI1xyLBoeHtMhYBpZ4eXUoQVxr5XMQyW0fHpJizx9OLXUg3.bB3p4YyeVdjCq G1fM_PE73D.x_JnFszLJ5BDmDXcE.pxyRSwFBJmx5obhRX3Z7h_8YpuUx5dc.PzZkDEyWkmyyoz3 VMEUCmzpB3ZAu8RjCTTPaNyjjqcvhmNcUx.K6qjMElSUGM4NIgXtEfP.nu7l3DoPz1OwGCAnc_d7 2FSvz41YX40ffEqd5cM_BqcQs5uLqRbQsb9SGaymJMvJlAGtLqoNclwQPSmWf3bNMul5hZbTc1m5 w9j5gxLe_lWyCs6P3oKdVgdo9NvOmMxOBsKf6XQ6H00m9Z.zy_crpCcEPz4nrmFLJ.ndc9DW5QNc 6kUnxF4JZy53xMLEwpX8XAQwHmpvRdGkMr2Ciy8PuksKTBGVpFdlYe1YKE7Wr9ltxS6p5kYw6AgO ZLgKnk6zWvdBygXXR6DmOpAtz.WNwO7NAPqicVBQJ7kQfvpvSpSw8xdkRfBVzSExv085XyWwWpZH PIFAQpdc5w_TBbHaEk.nCU3Xlu.9byoA37nG_honLS19dVOPmSbx.WWULdqdTcMbkZhjzxhP7iCc Ay.whhlHk3y2HpR27V5idxzNdtcWluhpkisdrcT4NcXJHbwLGBv.xwjCr8np38mtRzqoRTRuoXP1 4pdcMsfGZY2lbtMrSjlk50Y8qN_ic3LDPJ1sR3__9XEPAnU1vPNamD.S1zpPQSp5lBpQS5Gd2SA- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 21 Oct 2022 20:22:04 +0000 Received: by hermes--production-ne1-c47ffd5f5-8c2cz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8b1ab763c16993c9dc321b14f1e1c869; Fri, 21 Oct 2022 20:22:01 +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 16.0 \(3696.120.41.1.1\)) Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it From: Mark Millard In-Reply-To: Date: Fri, 21 Oct 2022 13:21:59 -0700 Cc: freebsd-arm , freebsd-uboot@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> References: <20221004001857.GA7109@www.zefox.net> <62F8D709-BBC3-41C4-B1A9-939B2001BA52@yahoo.com> <1DE565E3-3906-4C53-83C8-EBC20A4E3C95@yahoo.com> <20221005034608.GA12761@www.zefox.net> <1560695E-4D99-40A1-8D62-29EAB24C7997@yahoo.com> <20221005160737.GA15227@www.zefox.net> <136B9190-4C73-45FB-8B41-FEEF7C38A253@yahoo.com> <3A76826B-B4E6-4837-915E-C9E1172BEA20@yahoo.com> <20221021175142.GA62386@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MvG8t17WGz3TK9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qJwTd+vh; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Oct-21, at 12:53, Mark Millard wrote: > On 2022-Oct-21, at 10:51, bob prohaska wrote: >=20 >> Mixed success has been obtained using EDK2 on a pair of Pi3 >> systems, one running 13-stable and one running -current.=20 >>=20 >> The 13-stable machine is at stable/13-ef2aa7753 >> The -current machine is at main-n258665-e03b7883e97c >>=20 >> The 13-stable machine boots reliably with an EDK2 microSD card >> and will boot almost as reliably with no microSD card at all. >> This seems true with both JMS561 and JMS578 usb-serial bridges. >>=20 >> The -current machine uses an ASMT bridge and is unresponsive >> with either the EDK2 microSD or no microSD at all. It does boot >> reliably using the "special bootcode.bin" file from the Pi = foundation. >> It appears to be the newer of the two Pi3's, having a non-latching >> microSD receptacle.=20 >=20 > Which context does the "need bootcode.bin" problem follow? >=20 > A) Where the ASMT bridge is used vs. not? > B) Which RPi3B is used vs. not? > C) Which OS version is used vs. not? > D) It gets messier to specify if combinations of 2 or more > those need to be specified. I'll not list all the > possibilities. >=20 > Does the newer RPi3B indicate that its USB booting has > been enabled? (You may need to use the likes of a > RaspiOS variant to check this.) >=20 > I'm confused about the "special bootcode.bin": bootcoce.bin > is a normal part of the RPi* firmware, just ignored by > RPi4B related RPi*'s that have an alternate means of doing > things. Is this the bootcode.bin in the standard RPi* > firmware releases? Some other version? >=20 > bootcode.bin always has more recent, bugfixed USB boot code > than a RPi3B has built in, as far as I know. The RPi3B's > do not have a supported means of updating what is built-in > for such functionality. bootcode.bin is used instead. >=20 >=20 >> On balance EDK2 appears to be useful, or at least having some >> promise. >=20 > I'm glad it seems to have helped. But there are things to > know. >=20 > Point #0: EDK2 versions and testedness >=20 > The only tested RPi3B EDK2 versions are the ones that the > developers release. They do not test EDK2 updates after > they make an EDK2 release, at least until they again work > on making a new RPi3B EDK2 release. >=20 > Similarly, they do not test using newer RPi* firmware than > they bundle. Only a small subset of the overall RPi* > firmware is in their RPI3B release. For example, a lack of > most of the overlays. They do have references to at least > using one overlay that they do not include, as I remember. > But use of any other overlays is untested/not-supported as > far as I can tell. >=20 > The same goes for the RPi4B related EDK2 releases vs. later > EDK2 updates vs. overlays and such. >=20 > The RPi3B vs. RPi4B EDK2 releases are not based on the same > vintage of EDK2 materials --or on the same vintage of RPi* > materials. >=20 > This means that using the FreeBSD port will not pick out > the release-matching EDK2 materials as are in the RPi3B > or RPI4B EDK2 releases. Also, the RPi* firmware has to be > separately supplied. Overall: an untested combination > results, a combination that is unsupported by the RPi3B EDK2 > developers and the RPi4B EDK2 developers. >=20 > I've no clue if or how well the the port's builds might work. >=20 > Another issue is that some software that is upstream of > EDK2 tends to have problems staying inside the C language > definition and when this happens, EDK2 builds fail, despite > it not being EDK2's own code that needs the fix. >=20 > Point #1: RPi3B microsd slot use is messed up >=20 > In my RPi3B EDK2 related testing, trying to use a microsd > card in the RPi3B slot for such can corrupt the contents. > It does not even reliably lead to even correct file name > displays in ls output. >=20 > By contrast, using a USB reader/writer continued to work > just fine. >=20 > So just leave a RPi3B EDK2 microsd card in the slot > after booting. >=20 > I've no clue of the status for things like sound and such. >=20 > Point #2: RPi4B does not even start to use the microsd card >=20 > In my RPi4B EDK2 use, microsd card in the slot are not > supported --by being ignored as I remember. >=20 > By contrast, using a USB reader/writer continued to work > just fine. >=20 > So just leave a RPi4B EDK2 microsd card in the slot > after booting. >=20 > I've no clue of the status for things like sound and such. >=20 >=20 >> Bugzilla traffic suggests work is stalled, can it be >> unstuck? >>=20 >=20 > I expect that at some point that some variation on my > patches to allow the builds to at least complete will > be committed so the likes of aarch64 FreeBSD builds > become possible. (So long as EDK2+its-upstream stays > inside the language definition.) >=20 > But I do not know how useful builds are now when built > on amd64 or the like --that will also be true for the > aarch64 built ones. See the above "Point #0: EDK2 > versions and testedness" notes. >=20 > It may end up being more effective to stick to > downloading and using releases made by the RPi3B EDK2 > and RPi4B EDK2 folks if EDK2 is to be used for these > RPi* families. Side note on what type of video interfaces are in use for EDK2, at least for RPi4B EDK2 . . . =46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835 QUOTE of jlinton It looks fine on my RPI4+PFTF UEFI as well, although it should be noted that it's running on the EFI framebuffer in both DT and ACPI mode with that firmware.. This shouldn't be unexpected. At some point, I will update the DT with one that has the vc4 bindings. END QUOTE I do not know if RPi3B EDK2 also uses the EFI framebuffer for its Device Tree vs. ACPI vs. both modes. EFI framebuffer mode would likely be less performant. I'll note that if RPi4+PFTF UEFI is updated for Device Treee, that would not change RPi3+PFTF UEFI for Device Tree. (Fedora 37 was delayed by a failure to have RPi4B HDMI output displayed past a given point in the boot sequence. There was some question if some RPi3B bugfix(es) had caused the RPi4B issue. Looks like kernel-5.19.16-301.fc37 may end up being the basis for the first Fedora release with official RPi4B support, as its initial testing reports are that video is working on both RPi4 and RPi3.) =3D=3D=3D Mark Millard marklmi at yahoo.com