From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Mon, 11 Jun 2018 15:44:19 +0800 Subject: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload In-Reply-To: <95f403de-6ae3-4243-dbb9-128b97c8bb04@suse.de> References: <1528637118-32739-1-git-send-email-bmeng.cn@gmail.com> <1528637118-32739-15-git-send-email-bmeng.cn@gmail.com> <87a37e86-3d45-1f1c-92ef-422893b381ec@suse.de> <95f403de-6ae3-4243-dbb9-128b97c8bb04@suse.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Alex, On Mon, Jun 11, 2018 at 3:34 PM, Alexander Graf wrote: > On 06/11/2018 08:01 AM, Bin Meng wrote: >> >> Hi Alex, >> >> On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf wrote: >>> >>> >>> On 11.06.18 01:29, Bin Meng wrote: >>>> >>>> On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf wrote: >>>>> >>>>> >>>>> On 10.06.18 15:25, Bin Meng wrote: >>>>>> >>>>>> If UEFI BIOS has the graphics output protocol (GOP), let's pass its >>>>>> information to U-Boot payload so that U-Boot can utilize it (eg: >>>>>> an EFI framebuffer driver). >>>>>> >>>>>> Signed-off-by: Bin Meng >>>>> >>>>> Why can't the FB drive determine all of this on its own and just fail >>>>> probe if no GOP protocol can be found? >>>>> >>>> It cannot. Once U-Boot payload is running, the boot services are gone. >>>> There is no way to determine the GOP protocol. >>> >>> Interesting. Is there a particular reason you're not preserving boot >>> services? >>> >> This is EFI payload support with CONFIG_EFI_STUB. Preserving boot >> services is EFI application, with CONFIG_EFI_APP. For example, see >> serial_efi.c which is the serial driver that uses EFI's boot services >> to output characters on the serial port. > > > Oh, I see. That makes sense now. > > Do people actually need CONFIG_EFI_STUB then? I think you wanted to say: Do people actually need CONFIG_EFI_APP then? CONFIG_EFI_STUB is more useful than CONFIG_EFI_APP. The application support is very limited. As the README.u-boot_on_efi says: Running U-Boot on EFI is useful in several situations: - You have EFI running on a board but U-Boot does not natively support it fully yet. You can boot into U-Boot from EFI and use that until U-Boot is fully ported - You need to use an EFI implementation (e.g. UEFI) because your vendor requires it in order to provide support - You plan to use coreboot to boot into U-Boot but coreboot support does not currently exist for your platform. In the meantime you can use U-Boot on EFI and then move to U-Boot on coreboot when ready - You use EFI but want to experiment with a simpler alternative like U-Boot Right now, I have one Intel SkyLake board, and before I get a native U-Boot up and running as the 1st stage bootloader on this board, I can run U-Boot as the EFI payload to experiment something, which is very handy. > >> >>> It might be quite handy to reuse UEFI block interfaces for example. It >>> might also be useful to preserve (parts of?) the memory map so we don't >>> overwrite random SMM code for example. >>> >>> Maybe I misunderstand the purpose of the UEFI U-Boot support though ;). >> >> Looks there is some misunderstanding around the EFI payload support. > > > Yes, I have to admit that I never really cared enough about it to read its > documentation though :). Yep, this sometimes confuses people :) Regards, Bin