Re: EDK2 on RPi3 was: Re: u-boot debug, was: Re: U-boot on RPI3, sees disk but won't boot it

> Am 21.10.2022 um 22:21 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> On 2022-Oct-21, at 12:53, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On 2022-Oct-21, at 10:51, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>>> Mixed success has been obtained using EDK2 on a pair of Pi3
>>> systems, one running 13-stable and one running -current. 
>>> 
>>> The 13-stable machine is at stable/13-ef2aa7753
>>> The -current machine is at main-n258665-e03b7883e97c
>>> 
>>> 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.
>>> 
>>> 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. 
>> 
>> Which context does the "need bootcode.bin" problem follow?
>> 
>> 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.
>> 
>> 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.)
>> 
>> 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?
>> 
>> 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.
>> 
>> 
>>> On balance EDK2 appears to be useful, or at least having some
>>> promise.
>> 
>> I'm glad it seems to have helped. But there are things to
>> know.
>> 
>> Point #0: EDK2 versions and testedness
>> 
>> 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.
>> 
>> 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.
>> 
>> The same goes for the RPi4B related EDK2 releases vs. later
>> EDK2 updates vs. overlays and such.
>> 
>> The RPi3B vs. RPi4B EDK2 releases are not based on the same
>> vintage of EDK2 materials --or on the same vintage of RPi*
>> materials.
>> 
>> 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.
>> 
>> I've no clue if or how well the the port's builds might work.
>> 
>> 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.
>> 
>> Point #1: RPi3B microsd slot use is messed up
>> 
>> 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.
>> 
>> By contrast, using a USB reader/writer continued to work
>> just fine.
>> 
>> So just leave a RPi3B EDK2 microsd card in the slot
>> after booting.
>> 
>> I've no clue of the status for things like sound and such.
>> 
>> Point #2: RPi4B does not even start to use the microsd card
>> 
>> In my RPi4B EDK2 use, microsd card in the slot are not
>> supported --by being ignored as I remember.
>> 
>> By contrast, using a USB reader/writer continued to work
>> just fine.
>> 
>> So just leave a RPi4B EDK2 microsd card in the slot
>> after booting.
>> 
>> I've no clue of the status for things like sound and such.
>> 
>> 
>>> Bugzilla traffic suggests work is stalled, can it be
>>> unstuck?
>>> 
>> 
>> 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.)
>> 
>> 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.
>> 
>> 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 . . .
> 
> From 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.
> 
> ……….

FreeBSD will always run it`s framebuffer driver as long as
there is no VC4 driver implemented in FreeBSD.
So there’s nothing to bind to VC4 in DT nor ACPI.

Regards

Klaus