Date: Sat, 22 Oct 2022 02:16:40 +0200 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Mark Millard <marklmi@yahoo.com>, freebsd-arm@freebsd.org Subject: Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it Message-ID: <71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0@googlemail.com> In-Reply-To: <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com> References: <B32F06DD-DFAF-4CB7-A973-7C07846F6E8E@yahoo.com> <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> <DC32CA76-5072-4521-BCD8-CDF1512420D4@yahoo.com> <20221021175142.GA62386@www.zefox.net> <B90AA192-17B4-4FE3-8050-1E7889432ED4@yahoo.com> <0697DE1F-C626-4289-894A-4141CDF1B91B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 21.10.2022 um 22:21 schrieb Mark Millard <marklmi@yahoo.com>: >=20 > On 2022-Oct-21, at 12:53, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On 2022-Oct-21, at 10:51, bob prohaska <fbsd@www.zefox.net> 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. >=20 > Side note on what type of video interfaces are in use > for EDK2, at least for RPi4B EDK2 . . . >=20 > =46rom https://bodhi.fedoraproject.org/updates/FEDORA-2022-1c6a1ca835 >=20 > 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 >=20 > 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. >=20 > =E2=80=A6=E2=80=A6=E2=80=A6. FreeBSD will always run it`s framebuffer driver as long as there is no VC4 driver implemented in FreeBSD. So there=E2=80=99s nothing to bind to VC4 in DT nor ACPI. Regards Klaus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71AB9FAC-EB00-48F0-B0DD-0629C2D3C8C0>