> On 22. Dec 2023, at 11:54, Mark Millard <mark...@yahoo.com> wrote:
>
> On Dec 22, 2023, at 01:36, Toomas Soome <tso...@me.com> wrote:
>>
>>
>>
>>> On 22. Dec 2023, at 11:09, Mark Millard <mark...@yahoo.com> wrote:
>>>
>>> Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp> wrote on
>>> Date: Thu, 21 Dec 2023 23:21:00 UTC :
>>>
>>>> On Thu, 21 Dec 2023 14:22:14 +0100
>>>> Dimitry Andric <d...@freebsd.org> wrote:
>>>>
>>>>> Yeah, my procedure is the same as yours: I first copy
>>>>> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old,
>>>>> then copy the freshly built and installed /boot/loader.efi to
>>>>> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this
>>>>> could not be just another step in the installworld procedure.
>>>>>
>>>>> That said, I am unsure if the pathname /boot/efi/efi is always the same,
>>>>> at least for all UEFI systems. It is the default layout when you do a
>>>>> regular install with recent installer onto a UEFI system, but some users
>>>>> may use completely different mount points. So you should still have some
>>>>> way of configuring the default location for loader installation.
>>>>>
>>>>> Also, on default installations a fallback entry named
>>>>> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of
>>>>> loader.efi but with a different name. Namely, the default name that UEFI
>>>>> (on x86_64 at least) searches for, if it doesn't know anything else. I.e.
>>>>> if it isn't configured via efibootmgr(8), or the EFI variables have been
>>>>> junked for some reason. It might make sense to also update that file.
>>>>>
>>>>> -Dimitry
>>>>
>>>> Just an idea.
>>>>
>>>> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass
>>>> "where am I placed?" info, maybe via kenv.
>>>>
>>>> Would need boot1.efi to pass something (ideally, "where am I booted
>>>> from?", but "boot1_used=1" is sufficient).
>>>>
>>>> To do so, loader.efi can confirm whether it was loaded via boot1.efi or
>>>> directly from UEFI firmware. If nothing is passed to it, it can probe
>>>> "where it is?" using UEFI call and set it, otherwise, it should
>>>> be /boot/loader.efi, so nothing is needed to do.
>>>
>>> To my knowledge aarch64 and armv7 never use the copy in
>>> /boot/loader.efi during a boot. It has to have been copied
>>> into the appropriate msdosfs such that it has an
>>> appropriate path and name there. That is what is found
>>> and used during the boot.
>>
>>
>> All UEFI systems start from ESP (EFI System Partition). The only good reason
>> to install boot1.efi there is when you have very small ESP and need to save
>> that space - and in that case the boot1.esp will search and execute
>> /boot/loader.efi.
>
> Yep. May be I misinterpreted what the text strongly tied to
> "it should be /boot/loader.efi" and so ended up not pointing
> out an actual distinction.
>
>> The problem about boot1.efi (or any other UEFI chainload) is that loading
>> file and executing it will not replace current program in memory, but will
>> add new one, this may be problem with systems with minimal memory
>> configurations. And yes, boot1.efi is not really platform specific - it is
>> just another EFI application - one can build and use it on arm (or any
>> other) systems
>
> Not powerpc (32-bit), powerpc64, or powerpc64le: these are
> not UEFI systems at all, if I understand right.
Yes, building EFI application implies platform with UEFI support.
rgds,
toomas
>
> Of course, if only tier 1 is documented, such would not be
> covered. But documentation that is limited to tier 1 should
> say so explicitly --but various examples have historically
> not done so.
>
>> and then it will load and start /boot/loader.efi.
>>
>> starting loader directly from ESP has few advantages — you wont waste memory
>> for boot1.efi, you save a bit of boot time, you can use auxiliary files from
>> ESP to pass some information to loader.efi (for example to tell where your
>> rootfs is in case of multiboot setups).
>>
>> the boot1.efi could be a bit more appealing if it would be able to load and
>> start kernel directly, allowing to build very memory limited setups, but
>> then again, it does sound like very specific corner case.
>
> Thanks for the UEFi-context notes that go well beyond anything
> I referenced. Good stuff.
>
>> rgds,
>> toomas
>>
>>
>>>
>>>> If no related kenv is set and freebsd-boot partition exists, it should
>>>> be booted with legacy (BIOS) boot.
>>>
>>> If there even is a "legacy (BIOS) boot" is a platform
>>> specific issue as far as I know.
>>>
>>>> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI
>>>> device path. So would need analyzing where actually is on booted
>>>> FreeBBSD environment.
>>>
>>> See the earlier point about aarch64 and armv7 not using
>>> /boot/* files while loading the FreeBSD loader: the
>>> FreeBSD loader variant used is the first stage able to
>>> look inside UFS or ZFS file systems. Loading and
>>> starting the FreeBSD loader happens before that stage
>>> in those types of contexts.
>>>
>>>> . . .
>>>
>>> Also, to my knowledge, powerpc (32-bit), powerpc64, and
>>> powerpc64le do not involve any variant of loader.efi or
>>> UEFI/ACPI or UEFI/DeviceTriee in their boot sequnces.
>>> Again: more platform specific rather than generic.
>>>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
