On 22 May 2014 11:32, Rafael EspĂndola <rafael.espindola_at_gmail.com> wrote: > The attached patch causes both boot1 and loader.efi to switch to text > mode. This only > seems to make a difference on Macs where otherwise no information was being > displayed. > > The ConsoleControl.h file is copied from > EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl in > https://github.com/tianocore/edk2. > > I tested that both programs are able to change to text mode by > enabling only one of them at a time. > > With this patch I am able to see loaders output on all the macs I > tried. The kernel boots correctly on a MacPro, but unfortunately it > doesn't seem to be able to find the efi buffer in a MacBookPro. 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. > * 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 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.Received on Thu May 22 2014 - 13:54:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC