Re: uBoot broken on RPI2 Model B?

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 04 Mar 2023 14:47:33 UTC
On Mar 4, 2023, at 06:03, Karl Denninger <karl@denninger.net> wrote:

> On 3/4/2023 03:48, Mark Millard wrote:
>>> . . .
>> Karl reported that he was using boot1.efi instead of
>> loader.efi and just substituting in the likes of
>> loader.efi got booting to work.
>> 
>> Why boot1.efi ? Because that is what Crochet put in
>> place.
>> 
>> 
> Yes, and I remember when 13-x first showed up on my AMD box suddenly boot1 blew up there too which was a nasty little and unexpected surprise.  Not a big deal to fix once you realize what is going on but given the fact that u-boot updates have blown up booting on these devices before (and I've kept older versions around for this reason) that prompted me to ask if anyone else had seen a similar problem with the older Pi2s (my '3s are all ok with modern builds) on 13.x
> I've fixed Crochet to build and use the lua loader rather than boot1 for EFI and it appears to be working fine.

U-Boot 2023.01 did break booting 8 GiByte RPi4B 's via
running out of a fixed sized allocation (given the
type of U-Boot build that FreeBSD does). 2023.01 makes
more use of allocation's space than 2022.10 and before
did and 8 GiByte RPi4B 's end up with more in use than
the other RPi* 's that FreeBSD supports.

2023.01 needs more of the space while U-Boot is
working on loading the FreeBSD EFI loader. But the
reported message for the problem is a misnomer.

So it looks like an unmodified releng/13.2 is not
doing going to boot 8 GiByte RPi4B 's, just like
for stable/13 and main [so: 14] snapshots as things
are for now. I expect that 2023.04 will have U-Boot
fixed for this.

===
Mark Millard
marklmi at yahoo.com