All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload
Date: Mon, 11 Jun 2018 10:33:00 +0200	[thread overview]
Message-ID: <8980c788-a4f5-96e1-7913-f5fd935e99b5@suse.de> (raw)
In-Reply-To: <CAEUhbmU7UfnzGh4k-PtrmPavXymABeKh-BULUJOxV8JUs2g_gg@mail.gmail.com>

On 06/11/2018 09:44 AM, Bin Meng wrote:
> Hi Alex,
>
> On Mon, Jun 11, 2018 at 3:34 PM, Alexander Graf <agraf@suse.de> wrote:
>> On 06/11/2018 08:01 AM, Bin Meng wrote:
>>> Hi Alex,
>>>
>>> On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>> On 11.06.18 01:29, Bin Meng wrote:
>>>>> On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf <agraf@suse.de> 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 <bmeng.cn@gmail.com>
>>>>>> 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.

Oh, I see. So it's mostly used as bringup aid. In that case I agree that 
the stub bit makes a lot of sense.

The one thing that really bites us with the stub and different bitness 
is when you want to use efi_api.h again from within U-Boot. The obvious 
example is a 32bit U-Boot built as 64bit payload, allowing 32bit UEFI 
applications to run inside.

Do you think we could just agree on efi.h to not consume any stub config 
options and just determine things from its build environment instead? 
That way it automatically adapts according to the -m32/-m64 build flag 
for the stub and we would not need to worry about the stub in generic code.

Something like the patch below? If yes, I'll resend it with proper 
indentation :).


Alex


diff --git a/include/efi.h b/include/efi.h
index 98bddbac1a..5e1e8ac78c 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,12 +19,12 @@
  #include <linux/string.h>
  #include <linux/types.h>

-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && 
defined(__x86_64__))
-/* EFI uses the Microsoft ABI which is not the default for GCC */
+/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
+#ifdef __x86_64__
  #define EFIAPI __attribute__((ms_abi))
  #else
  #define EFIAPI asmlinkage
-#endif
+#endif /* __x86_64__ */

  struct efi_device_path;

@@ -32,16 +32,7 @@ typedef struct {
      u8 b[16];
  } efi_guid_t;

-#define EFI_BITS_PER_LONG    BITS_PER_LONG
-
-/*
- * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- * in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
-#undef EFI_BITS_PER_LONG
-#define EFI_BITS_PER_LONG    64
-#endif
+#define EFI_BITS_PER_LONG    (sizeof(long) * 8)

  /* Bit mask for EFI status code with error */
  #define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))

  reply	other threads:[~2018-06-11  8:33 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-10 13:24 [U-Boot] [PATCH 00/18] x86: efi: Fixes and enhancements to application and payload support Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot Bin Meng
2018-06-10 13:39   ` Heinrich Schuchardt
2018-06-10 14:01     ` Bin Meng
2018-06-10 17:46       ` Heinrich Schuchardt
2018-06-10 13:25 ` [U-Boot] [PATCH 02/18] x86: Conditionally build the pinctrl_ich6 driver Bin Meng
2018-06-11 14:53   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application Bin Meng
2018-06-11 14:53   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-11 17:18   ` Heinrich Schuchardt
2018-06-11 23:19     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes Bin Meng
2018-06-10 19:11   ` Alexander Graf
2018-06-11  2:34     ` Bin Meng
2018-06-11  5:55       ` Alexander Graf
2018-06-11  6:05         ` Bin Meng
2018-06-11 14:53   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload Bin Meng
2018-06-10 14:02   ` Heinrich Schuchardt
2018-06-10 14:30     ` Bin Meng
2018-06-10 18:17       ` Heinrich Schuchardt
2018-06-10 23:36         ` Bin Meng
2018-06-11 15:31           ` Heinrich Schuchardt
2018-06-11 16:35             ` Bin Meng
2018-06-11 18:35               ` Heinrich Schuchardt
2018-06-11  9:11   ` Bin Meng
2018-06-11 19:43     ` Alexander Graf
2018-06-10 13:25 ` [U-Boot] [PATCH 06/18] dm: pci: Make ranges dt property optional Bin Meng
2018-06-11 14:53   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 07/18] dm: pci: Use a 1:1 mapping for bus <-> phy addresses Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 08/18] x86: efi: Refactor the directory of EFI app and payload support Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 09/18] x86: efi: payload: Add arch_cpu_init() Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 10/18] x86: efi: payload: Minor clean up on error message output Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-12 13:07     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 11/18] x86: Add generic EFI payload support Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 12/18] x86: Drop QEMU-specific " Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 13/18] x86: baytrail: Drop EFI-specific test logics Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload Bin Meng
2018-06-10 19:16   ` Alexander Graf
2018-06-10 23:29     ` Bin Meng
2018-06-11  5:52       ` Alexander Graf
2018-06-11  6:01         ` Bin Meng
2018-06-11  7:34           ` Alexander Graf
2018-06-11  7:44             ` Bin Meng
2018-06-11  8:33               ` Alexander Graf [this message]
2018-06-11  9:02                 ` Bin Meng
2018-06-11 14:53   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 15/18] dm: video: Add an EFI framebuffer driver Bin Meng
2018-06-10 15:52   ` Anatolij Gustschin
2018-06-10 13:25 ` [U-Boot] [PATCH 16/18] x86: efi: payload: Add EFI framebuffer driver support Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-10 13:25 ` [U-Boot] [PATCH 17/18] x86: Rename efi-x86 target to efi-x86_app Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-11 15:50     ` Bin Meng
2018-06-10 13:25 ` [U-Boot] [PATCH 18/18] x86: efi: app: Display correct CPU info during boot Bin Meng
2018-06-11 14:54   ` Simon Glass
2018-06-11 14:53 ` [U-Boot] [PATCH 00/18] x86: efi: Fixes and enhancements to application and payload support Simon Glass
2018-06-11 15:53   ` Bin Meng
2018-06-11 19:38     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8980c788-a4f5-96e1-7913-f5fd935e99b5@suse.de \
    --to=agraf@suse.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.