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

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.

===
Mark Millard
marklmi at yahoo.com