Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE.

On Sat, Aug 3, 2024, 8:28 AM bob prohaska <fbsd@www.zefox.net> wrote:

> On Fri, Aug 02, 2024 at 11:08:36PM -0700, Mark Millard wrote:
> >
> >
> > On Aug 2, 2024, at 21:59, bob prohaska <fbsd@www.zefox.net> wrote:
> >
> > > On Fri, Aug 02, 2024 at 09:02:46PM -0700, Mark Millard wrote:
> > >> On Aug 2, 2024, at 19:19, bob prohaska <fbsd@www.zefox.net> wrote:
> > >>
> > >>> After a build/install of -current on a Raspberry Pi 2 (so, armv7)
> the
> > >>> console output reported:
> > >>>
> > >>>
> **********************************************************************
> > >>>
> **********************************************************************
> > >>> *****
> *****
> > >>> *****           BOOT LOADER IS TOO OLD. PLEASE UPGRADE.
> *****
> > >>> *****
> *****
> > >>>
> **********************************************************************
> > >>>
> **********************************************************************
> > >>>
> > >>> The statement is likely true, but it's a bit hard to guess exactly
> > >>> what needs upgrading. The boot process succeeded. Is it wiser to
> > >>> heed the command, or leave well enough alone? AFAIK there's no
> > >>> firmware to upgrade on the Pi2.
> > >>
> > >> The message is about the likes of:
> > >>
> > >> RPi2 v1.1 (armv7)?   /boot/efi/EFI/BOOT/bootarm.efi
> > >> RPi2 v1.2 (aarch64)? /boot/efi/EFI/BOOT/bootaa64.efi
> > >>
> > >> Those are not RPi* firmware, nor armstub* , nor are they U-Boot.
> > >>
> > >> They are code from FreeBSD: FreeBSD UEFI loader code. So, yes,
> > >> there is new code to update to.
> > >>
> > > Where can I find the newer version?  Following buildworld/kernel
> > > find / -name bootarm.efi
> > > locates only
> > > /boot/msdos/EFI/BOOT/bootarm.efi
> > > which I imagine is the obsolete version.
> > >
> > > Apologies if this is naive, something suggests it might be....
> >
> > Presuming a self-hosted build was done and was installed to
> > update that system, the updates could be done via:
> >
> >
> > On armv7 (RPi2 v1.1 --or RPi2 v1.2 used with an armv7 kernel/world):
> >
> > # cp /boot/loader.efi /boot/efi/EFI/BOOT/bootarm.efi
>
> In this case the path turns out to be
> /boot/msdos/EFI/BOOT/bootarm.efi but the fix was otherwise trivial.
> It was surprising to find the old file dated Jul 2 2020, I didn't
> realize the machine has been up that long.
>
> >
> > In other words, they are copies of the FreeBSD boot loader
> > but under other path and naming conventions on the msdosfs
> > that is involved.
> >
>
> Is there some reason installworld (or some other make target) doesn't
> do this by default? The msdos filesystem is mounted and writeable any
> time the host is running.
>

Except it's not.

When FreeBSD first did UEFI support we did it in the half assiest way
possible. We had a file that was a FAT that would get dd'd onto the ESP.
So, this was never mounted. That is mistake #1. The boot loader could never
grow. Nor change, really. Or get any new functionality. Oh, and it was a
copy of the loader.efi, but without the scripting. It was a total mess that
barely worked for UFS.

So, there never was a standard place to mount it early on. Plus some people
think having the ESP mointed was bad. So for years we argued about even
whether or not to mount it.

Plus, there are two places yhat loader.efi can go. One is in
/efi/boot/bootXxx.efi. this is the place the BIOS looks for it on removable
media. But is terrible for multiboot. So we implemented the efiboitmgr
protocol and put it in /efi/freebsd/loader.efi. efibootmgr lets it be
anywhere.

Also, there are still systems that use boot1.efi which are impossible to
change.

So what do we update in installworld? How do we deal with all the cases
needing some level dwim, but guessing about the boot loader is high stakes.
It doesn't take too many wrong guesses to really frustrate and drive away a
lot of users.

I have the doodle of a design to have a make installboot that would do it
based on parameters set for their system. But i got bogged down when uboot
and powerpc ofw got into the mix.

Warner

Thank you very much!
>
> bob prohaska
>
>
>