> Great, thank you Rafael.  There's framebuffer corruption issues on
> some other hardware as well, so it may be that the eventual fix for
> those will also solve the MBP issue.


>> Some design questions:
>> * Why do we have both boot1 and loader? It is just the issue with
>> building a usb image without root that requires having a boot1 that
>> has a predictable size?
> No, boot1.efi only exists so that the loader and related Forth and
> config files can be placed in a UFS root filesystem, as is done with
> the x86 BIOS boot and on other platforms.  This way the UEFI boot
> easily integrates with the existing installer and tools.
> We could put the loader and files in the FAT EFI system partition
> instead, but it would require more substantial changes in the
> installer and system configuration.

I see. What should be done for a machine with multiple freebsd
installations (versions 11 and 12 for example)? Will there be a single
boot1 and two loaders? Right now I think boot1 always opens the first
loader it finds.

>> * Even if we want to keep both boot1 and loader, could boot1 use libefi?
> I don't think there's any fundamental reason we couldn't.  However,
> we're going to need to take a broader look at reworking some of this
> in the context of secure boot anyway (as we look at a signed shim
> loader).

Is the idea to develop boot1 to be the signed loader?

>> * Is it ok to always switch to text mode in libefi or should it
>> provide a switch_to_text_mode function?
> I suspect it's fine / correct to always switch; we've just been
> "lucky" that the current approach works with most firmwares.

I confess I don't know the big picture of how EFI is designed. The API
file I found was in a directory called EdkCompatibilityPkg, so maybe
this is just something that newer EFI implementations don't need but
old ones do?

What is the next step? Unfortunately the only EFI capable machines I
have are Macs (or VMs). Can you test it on some other implementation?

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to