> 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. Awesome! >> 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? Cheers, RafaelReceived on Fri May 23 2014 - 01:33:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC