* [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-12 16:04 ` Heinrich Schuchardt
2018-06-17 13:17 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options Bin Meng
` (11 subsequent siblings)
12 siblings, 2 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
separate documents"), the original README.efi was renamed to
README.u-boot_on_efi, but x86 doc still refers to the old one.
This updates the x86 doc to reference both README.u-boot_on_efi and
README.uefi.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- update the x86 doc to reference also README.uefi
doc/README.x86 | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86
index 78664c3..9f657df 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu.
EFI Support
-----------
U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
-This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI
-application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot
-provides an EFI environment to the kernel (i.e. replaces UEFI completely but
-provides the same EFI run-time services) is not currently supported on x86.
+This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
+UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
+The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
+the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
+services) is not currently supported on x86.
-See README.efi for details of EFI support in U-Boot.
+See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
64-bit Support
--------------
U-Boot supports booting a 64-bit kernel directly and is able to change to
-64-bit mode to do so. It also supports (with CONFIG_EFI_STUB) booting from
-both 32-bit and 64-bit UEFI. However, U-Boot itself is currently always built
+64-bit mode to do so. However, U-Boot itself is currently always built
in 32-bit mode. Some access to the full memory range is provided with
arch_phys_memset().
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
2018-06-12 15:36 ` [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot Bin Meng
@ 2018-06-12 16:04 ` Heinrich Schuchardt
2018-06-12 23:06 ` Bin Meng
2018-06-17 13:17 ` Bin Meng
1 sibling, 1 reply; 36+ messages in thread
From: Heinrich Schuchardt @ 2018-06-12 16:04 UTC (permalink / raw)
To: u-boot
On 06/12/2018 05:36 PM, Bin Meng wrote:
> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
> separate documents"), the original README.efi was renamed to
> README.u-boot_on_efi, but x86 doc still refers to the old one.
>
> This updates the x86 doc to reference both README.u-boot_on_efi and
> README.uefi.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> Changes in v2:
> - update the x86 doc to reference also README.uefi
>
> doc/README.x86 | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/doc/README.x86 b/doc/README.x86
> index 78664c3..9f657df 100644
> --- a/doc/README.x86
> +++ b/doc/README.x86
> @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu.
> EFI Support
> -----------
> U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
> -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI
> -application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot
> -provides an EFI environment to the kernel (i.e. replaces UEFI completely but
> -provides the same EFI run-time services) is not currently supported on x86.
> +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
> +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
> +The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
> +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
> +services) is not currently supported on x86.
Do you mean
"is not currently supported on x86 in conjunction with EFI_STUB"
or do you mean
"still has bugs on x86"?
On qemu-x86_defconfig I can start EFI applications like the
helloworld.efi and ipxe. It is only the Linux kernel that has a problem
with memory setup. That is of cause a bug that needs further attention.
Best regards
Heinrich
>
> -See README.efi for details of EFI support in U-Boot.
> +See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
>
> 64-bit Support
> --------------
> U-Boot supports booting a 64-bit kernel directly and is able to change to
> -64-bit mode to do so. It also supports (with CONFIG_EFI_STUB) booting from
> -both 32-bit and 64-bit UEFI. However, U-Boot itself is currently always built
> +64-bit mode to do so. However, U-Boot itself is currently always built
> in 32-bit mode. Some access to the full memory range is provided with
> arch_phys_memset().
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
2018-06-12 16:04 ` Heinrich Schuchardt
@ 2018-06-12 23:06 ` Bin Meng
2018-06-14 6:55 ` Bin Meng
0 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 23:06 UTC (permalink / raw)
To: u-boot
Hi Heinrich,
On Wed, Jun 13, 2018 at 12:04 AM, Heinrich Schuchardt
<xypron.glpk@gmx.de> wrote:
> On 06/12/2018 05:36 PM, Bin Meng wrote:
>> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
>> separate documents"), the original README.efi was renamed to
>> README.u-boot_on_efi, but x86 doc still refers to the old one.
>>
>> This updates the x86 doc to reference both README.u-boot_on_efi and
>> README.uefi.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>> Changes in v2:
>> - update the x86 doc to reference also README.uefi
>>
>> doc/README.x86 | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/doc/README.x86 b/doc/README.x86
>> index 78664c3..9f657df 100644
>> --- a/doc/README.x86
>> +++ b/doc/README.x86
>> @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu.
>> EFI Support
>> -----------
>> U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
>> -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI
>> -application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot
>> -provides an EFI environment to the kernel (i.e. replaces UEFI completely but
>> -provides the same EFI run-time services) is not currently supported on x86.
>> +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
>> +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
>> +The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
>> +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
>> +services) is not currently supported on x86.
>
> Do you mean
> "is not currently supported on x86 in conjunction with EFI_STUB"
> or do you mean
> "still has bugs on x86"?
>
> On qemu-x86_defconfig I can start EFI applications like the
> helloworld.efi and ipxe. It is only the Linux kernel that has a problem
> with memory setup. That is of cause a bug that needs further attention.
>
I did not touch this when I updated the doc. I believe the doc means
CONFIG_EFI_LOADER is not currently supported. As you mentioned, there
are still some issues to work out. Maybe after you address all the
remaining issues, we can update the doc for its support :)
Regards,
Bin
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
2018-06-12 23:06 ` Bin Meng
@ 2018-06-14 6:55 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-14 6:55 UTC (permalink / raw)
To: u-boot
Hi Heinrich,
On Wed, Jun 13, 2018 at 7:06 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Heinrich,
>
> On Wed, Jun 13, 2018 at 12:04 AM, Heinrich Schuchardt
> <xypron.glpk@gmx.de> wrote:
>> On 06/12/2018 05:36 PM, Bin Meng wrote:
>>> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
>>> separate documents"), the original README.efi was renamed to
>>> README.u-boot_on_efi, but x86 doc still refers to the old one.
>>>
>>> This updates the x86 doc to reference both README.u-boot_on_efi and
>>> README.uefi.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>> Changes in v2:
>>> - update the x86 doc to reference also README.uefi
>>>
>>> doc/README.x86 | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/doc/README.x86 b/doc/README.x86
>>> index 78664c3..9f657df 100644
>>> --- a/doc/README.x86
>>> +++ b/doc/README.x86
>>> @@ -1134,18 +1134,18 @@ the "Power" submenu from the Windows start menu.
>>> EFI Support
>>> -----------
>>> U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
>>> -This is enabled with CONFIG_EFI_STUB. U-Boot can also run as an EFI
>>> -application, with CONFIG_EFI_APP. The CONFIG_EFI_LOADER option, where U-Booot
>>> -provides an EFI environment to the kernel (i.e. replaces UEFI completely but
>>> -provides the same EFI run-time services) is not currently supported on x86.
>>> +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
>>> +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
>>> +The CONFIG_EFI_LOADER option, where U-Booot provides an EFI environment to
>>> +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
>>> +services) is not currently supported on x86.
>>
>> Do you mean
>> "is not currently supported on x86 in conjunction with EFI_STUB"
>> or do you mean
>> "still has bugs on x86"?
>>
>> On qemu-x86_defconfig I can start EFI applications like the
>> helloworld.efi and ipxe. It is only the Linux kernel that has a problem
>> with memory setup. That is of cause a bug that needs further attention.
>>
>
> I did not touch this when I updated the doc. I believe the doc means
> CONFIG_EFI_LOADER is not currently supported. As you mentioned, there
> are still some issues to work out. Maybe after you address all the
> remaining issues, we can update the doc for its support :)
I tested CONFIG_EFI_LOADER today, with U-Boot loads EFI application
and EFI payload, on 32-bit QEMU. Here is the log:
=> load ide 0 1000000 u-boot-app.efi
683843 bytes read in 105 ms (6.2 MiB/s)
=> bootefi 1000000
Scanning disk ide.blk#0...
Found 2 disks
WARNING: booting without device tree
## Starting EFI application at 01000000 ...
U-Boot EFI App starting
U-Boot 2018.07-rc1-00097-gc5eea16 (Jun 12 2018 - 23:02:03 +0800)
CPU: x86_64, vendor AMD, device 663h
DRAM: 32 MiB
Model: EFI x86 Application
Hit any key to stop autoboot: 0
=>
=> reset
resetting ...
U-Boot EFI exiting
## Application terminated, r = 0
=>
=>
=> load ide 0 1000000 u-boot-payload.efi
486203 bytes read in 94 ms (4.9 MiB/s)
=> bootefi 1000000
WARNING: booting without device tree
## Starting EFI application at 01000000 ...
U-Boot EFI Payload
U-Boot 2018.07-rc1-00097-gc5eea16 (Jun 12 2018 - 23:01:24 +0800)
CPU: x86_64, vendor AMD, device 663h
DRAM: 108.2 MiB
MMC:
Video: 1024x768x32
Model: EFI x86 Payload
Net: No ethernet found.
IDE: Bus 0: OK Bus 1: OK
Device 0: Model: QEMU HARDDISK Firm: 2.5+ Ser#: QM00001
Type: Hard Disk
Supports 48-bit addressing
Capacity: 504.0 MB = 0.4 GB (1032192 x 512)
Device 1: not available
Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
Type: Removable CD ROM
Capacity: not available
Device 3: not available
Hit any key to stop autoboot: 0
=>
=>
I can update the documentation to change CONFIG_EFI_LOADER support
status, but that is a separate patch.
Regards,
Bin
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot
2018-06-12 15:36 ` [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot Bin Meng
2018-06-12 16:04 ` Heinrich Schuchardt
@ 2018-06-17 13:17 ` Bin Meng
1 sibling, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:17 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two
> separate documents"), the original README.efi was renamed to
> README.u-boot_on_efi, but x86 doc still refers to the old one.
>
> This updates the x86 doc to reference both README.u-boot_on_efi and
> README.uefi.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> Changes in v2:
> - update the x86 doc to reference also README.uefi
>
> doc/README.x86 | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-13 1:29 ` Simon Glass
2018-06-12 15:36 ` [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines Bin Meng
` (10 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
From: Alexander Graf <agraf@suse.de>
Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.
This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2: None
include/efi.h | 17 ++++-------------
lib/efi/Makefile | 4 ++--
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index 98bddba..5e1e8ac 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))
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index f1a3929..a790d2d 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -7,11 +7,11 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB \
+CFLAGS_efi_stub.o := -fpic -fshort-wchar \
$(if $(CONFIG_EFI_STUB_64BIT),-m64)
CFLAGS_REMOVE_efi.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB \
+CFLAGS_efi.o := -fpic -fshort-wchar \
$(if $(CONFIG_EFI_STUB_64BIT),-m64)
extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-12 15:36 ` [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options Bin Meng
@ 2018-06-13 1:29 ` Simon Glass
2018-06-13 10:17 ` Alexander Graf
0 siblings, 1 reply; 36+ messages in thread
From: Simon Glass @ 2018-06-13 1:29 UTC (permalink / raw)
To: u-boot
Hi Bin, Alex,
On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
> From: Alexander Graf <agraf@suse.de>
>
> Currently efi.h determines a few bits of its environment according to
> config options. This falls apart with the efi stub support which may
> result in efi.h getting pulled into the stub as well as real U-Boot
> code. In that case, one may be 32bit while the other one is 64bit.
>
> This patch changes the conditionals to use compiler provided defines
> instead. That way we always adhere to the build environment we're in
> and the definitions adjust automatically.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Tested-by: Bin Meng <bmeng.cn@gmail.com>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> Changes in v2: None
>
> include/efi.h | 17 ++++-------------
> lib/efi/Makefile | 4 ++--
> 2 files changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/include/efi.h b/include/efi.h
> index 98bddba..5e1e8ac 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__ */
I made the same comment in another patch. This is becoming too ad-hoc
where making EFI builds work is distributed and hidden in such a way
that no one will be able to know whether a change causes problems or
not.
I feel that build config should be deterministic given the CONFIG
options provided by the board. Any checks of compiler predefines
should be done in one place (efi.h?) and bugs in that stuff should
there all be in one place too, and easier to debug and fix.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-13 1:29 ` Simon Glass
@ 2018-06-13 10:17 ` Alexander Graf
2018-06-14 12:58 ` Simon Glass
0 siblings, 1 reply; 36+ messages in thread
From: Alexander Graf @ 2018-06-13 10:17 UTC (permalink / raw)
To: u-boot
On 13.06.18 03:29, Simon Glass wrote:
> Hi Bin, Alex,
>
> On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
>> From: Alexander Graf <agraf@suse.de>
>>
>> Currently efi.h determines a few bits of its environment according to
>> config options. This falls apart with the efi stub support which may
>> result in efi.h getting pulled into the stub as well as real U-Boot
>> code. In that case, one may be 32bit while the other one is 64bit.
>>
>> This patch changes the conditionals to use compiler provided defines
>> instead. That way we always adhere to the build environment we're in
>> and the definitions adjust automatically.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>> Changes in v2: None
>>
>> include/efi.h | 17 ++++-------------
>> lib/efi/Makefile | 4 ++--
>> 2 files changed, 6 insertions(+), 15 deletions(-)
>>
>> diff --git a/include/efi.h b/include/efi.h
>> index 98bddba..5e1e8ac 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__ */
>
> I made the same comment in another patch. This is becoming too ad-hoc
> where making EFI builds work is distributed and hidden in such a way
> that no one will be able to know whether a change causes problems or
> not.
>
> I feel that build config should be deterministic given the CONFIG
> options provided by the board. Any checks of compiler predefines
> should be done in one place (efi.h?) and bugs in that stuff should
> there all be in one place too, and easier to debug and fix.
I actually think the opposite is true. We should get rid of any #ifdef
CONFIG_ARCH checks throughout the code base that are not meant to
actually check for the "target" (sandbox for example), but instead
really only want to know the architecture the code is building against.
We can easily trust the compiler to emit correct defines for the target
architecture it's building against. That's what every other piece of C
code on earth depends on. Why be different?
Alex
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-13 10:17 ` Alexander Graf
@ 2018-06-14 12:58 ` Simon Glass
2018-06-14 13:44 ` Alexander Graf
2018-06-15 9:51 ` Bin Meng
0 siblings, 2 replies; 36+ messages in thread
From: Simon Glass @ 2018-06-14 12:58 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 13 June 2018 at 04:17, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 13.06.18 03:29, Simon Glass wrote:
>> Hi Bin, Alex,
>>
>> On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> From: Alexander Graf <agraf@suse.de>
>>>
>>> Currently efi.h determines a few bits of its environment according to
>>> config options. This falls apart with the efi stub support which may
>>> result in efi.h getting pulled into the stub as well as real U-Boot
>>> code. In that case, one may be 32bit while the other one is 64bit.
>>>
>>> This patch changes the conditionals to use compiler provided defines
>>> instead. That way we always adhere to the build environment we're in
>>> and the definitions adjust automatically.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>> Changes in v2: None
>>>
>>> include/efi.h | 17 ++++-------------
>>> lib/efi/Makefile | 4 ++--
>>> 2 files changed, 6 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/include/efi.h b/include/efi.h
>>> index 98bddba..5e1e8ac 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__ */
>>
>> I made the same comment in another patch. This is becoming too ad-hoc
>> where making EFI builds work is distributed and hidden in such a way
>> that no one will be able to know whether a change causes problems or
>> not.
>>
>> I feel that build config should be deterministic given the CONFIG
>> options provided by the board. Any checks of compiler predefines
>> should be done in one place (efi.h?) and bugs in that stuff should
>> there all be in one place too, and easier to debug and fix.
>
> I actually think the opposite is true. We should get rid of any #ifdef
> CONFIG_ARCH checks throughout the code base that are not meant to
> actually check for the "target" (sandbox for example), but instead
> really only want to know the architecture the code is building against.
>
> We can easily trust the compiler to emit correct defines for the target
> architecture it's building against. That's what every other piece of C
> code on earth depends on. Why be different?
By this logic we would check for __x86_64__ everywhere instead of
CONFIG_X86. I can't think of a better way to explain this without
repeating myself.
Bin, do you understand what I am getting at? Are my concerns unwarranted?
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-14 12:58 ` Simon Glass
@ 2018-06-14 13:44 ` Alexander Graf
2018-06-15 9:51 ` Bin Meng
1 sibling, 0 replies; 36+ messages in thread
From: Alexander Graf @ 2018-06-14 13:44 UTC (permalink / raw)
To: u-boot
On 06/14/2018 02:58 PM, Simon Glass wrote:
> Hi Alex,
>
> On 13 June 2018 at 04:17, Alexander Graf <agraf@suse.de> wrote:
>>
>> On 13.06.18 03:29, Simon Glass wrote:
>>> Hi Bin, Alex,
>>>
>>> On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> From: Alexander Graf <agraf@suse.de>
>>>>
>>>> Currently efi.h determines a few bits of its environment according to
>>>> config options. This falls apart with the efi stub support which may
>>>> result in efi.h getting pulled into the stub as well as real U-Boot
>>>> code. In that case, one may be 32bit while the other one is 64bit.
>>>>
>>>> This patch changes the conditionals to use compiler provided defines
>>>> instead. That way we always adhere to the build environment we're in
>>>> and the definitions adjust automatically.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>> ---
>>>>
>>>> Changes in v2: None
>>>>
>>>> include/efi.h | 17 ++++-------------
>>>> lib/efi/Makefile | 4 ++--
>>>> 2 files changed, 6 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/include/efi.h b/include/efi.h
>>>> index 98bddba..5e1e8ac 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__ */
>>> I made the same comment in another patch. This is becoming too ad-hoc
>>> where making EFI builds work is distributed and hidden in such a way
>>> that no one will be able to know whether a change causes problems or
>>> not.
>>>
>>> I feel that build config should be deterministic given the CONFIG
>>> options provided by the board. Any checks of compiler predefines
>>> should be done in one place (efi.h?) and bugs in that stuff should
>>> there all be in one place too, and easier to debug and fix.
>> I actually think the opposite is true. We should get rid of any #ifdef
>> CONFIG_ARCH checks throughout the code base that are not meant to
>> actually check for the "target" (sandbox for example), but instead
>> really only want to know the architecture the code is building against.
>>
>> We can easily trust the compiler to emit correct defines for the target
>> architecture it's building against. That's what every other piece of C
>> code on earth depends on. Why be different?
> By this logic we would check for __x86_64__ everywhere instead of
> CONFIG_X86. I can't think of a better way to explain this without
> repeating myself.
That's my point. I think most cases that check for CONFIG_X86 are just
plain wrong.
Alex
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-14 12:58 ` Simon Glass
2018-06-14 13:44 ` Alexander Graf
@ 2018-06-15 9:51 ` Bin Meng
2018-06-19 22:03 ` Simon Glass
1 sibling, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-15 9:51 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Alex,
>
> On 13 June 2018 at 04:17, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 13.06.18 03:29, Simon Glass wrote:
>>> Hi Bin, Alex,
>>>
>>> On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> From: Alexander Graf <agraf@suse.de>
>>>>
>>>> Currently efi.h determines a few bits of its environment according to
>>>> config options. This falls apart with the efi stub support which may
>>>> result in efi.h getting pulled into the stub as well as real U-Boot
>>>> code. In that case, one may be 32bit while the other one is 64bit.
>>>>
>>>> This patch changes the conditionals to use compiler provided defines
>>>> instead. That way we always adhere to the build environment we're in
>>>> and the definitions adjust automatically.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>> ---
>>>>
>>>> Changes in v2: None
>>>>
>>>> include/efi.h | 17 ++++-------------
>>>> lib/efi/Makefile | 4 ++--
>>>> 2 files changed, 6 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/include/efi.h b/include/efi.h
>>>> index 98bddba..5e1e8ac 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__ */
>>>
>>> I made the same comment in another patch. This is becoming too ad-hoc
>>> where making EFI builds work is distributed and hidden in such a way
>>> that no one will be able to know whether a change causes problems or
>>> not.
>>>
>>> I feel that build config should be deterministic given the CONFIG
>>> options provided by the board. Any checks of compiler predefines
>>> should be done in one place (efi.h?) and bugs in that stuff should
>>> there all be in one place too, and easier to debug and fix.
>>
>> I actually think the opposite is true. We should get rid of any #ifdef
>> CONFIG_ARCH checks throughout the code base that are not meant to
>> actually check for the "target" (sandbox for example), but instead
>> really only want to know the architecture the code is building against.
>>
>> We can easily trust the compiler to emit correct defines for the target
>> architecture it's building against. That's what every other piece of C
>> code on earth depends on. Why be different?
>
> By this logic we would check for __x86_64__ everywhere instead of
> CONFIG_X86. I can't think of a better way to explain this without
> repeating myself.
>
> Bin, do you understand what I am getting at? Are my concerns unwarranted?
I got what you are concerned about. I guess you wanted to say "By this
logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*"
As when CONFIG_X86_64 is defined, the "-m64" flag is passed to
compiler, and __x86_64__ takes effect. But I think this can only be
applied in source codes. In makefiles, we still need CONFIG_X86_64.
For the bug we are trying to address here, I believe current patch to
test __x86_64__ is the simplest way compared to a bunch of config
options checks. In fact, __x86_64__ contains enough information to fix
the problem, and the config options checks look superfluous.
How about we add some comments to the changes above to explain some
more details? Does that look better?
Regards,
Bin
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options
2018-06-15 9:51 ` Bin Meng
@ 2018-06-19 22:03 ` Simon Glass
0 siblings, 0 replies; 36+ messages in thread
From: Simon Glass @ 2018-06-19 22:03 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 15 June 2018 at 03:51, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Alex,
>>
>> On 13 June 2018 at 04:17, Alexander Graf <agraf@suse.de> wrote:
>>>
>>>
>>> On 13.06.18 03:29, Simon Glass wrote:
>>>> Hi Bin, Alex,
>>>>
>>>> On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> From: Alexander Graf <agraf@suse.de>
>>>>>
>>>>> Currently efi.h determines a few bits of its environment according to
>>>>> config options. This falls apart with the efi stub support which may
>>>>> result in efi.h getting pulled into the stub as well as real U-Boot
>>>>> code. In that case, one may be 32bit while the other one is 64bit.
>>>>>
>>>>> This patch changes the conditionals to use compiler provided defines
>>>>> instead. That way we always adhere to the build environment we're in
>>>>> and the definitions adjust automatically.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> ---
>>>>>
>>>>> Changes in v2: None
>>>>>
>>>>> include/efi.h | 17 ++++-------------
>>>>> lib/efi/Makefile | 4 ++--
>>>>> 2 files changed, 6 insertions(+), 15 deletions(-)
>>>>>
>>>>> diff --git a/include/efi.h b/include/efi.h
>>>>> index 98bddba..5e1e8ac 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__ */
>>>>
>>>> I made the same comment in another patch. This is becoming too ad-hoc
>>>> where making EFI builds work is distributed and hidden in such a way
>>>> that no one will be able to know whether a change causes problems or
>>>> not.
>>>>
>>>> I feel that build config should be deterministic given the CONFIG
>>>> options provided by the board. Any checks of compiler predefines
>>>> should be done in one place (efi.h?) and bugs in that stuff should
>>>> there all be in one place too, and easier to debug and fix.
>>>
>>> I actually think the opposite is true. We should get rid of any #ifdef
>>> CONFIG_ARCH checks throughout the code base that are not meant to
>>> actually check for the "target" (sandbox for example), but instead
>>> really only want to know the architecture the code is building against.
>>>
>>> We can easily trust the compiler to emit correct defines for the target
>>> architecture it's building against. That's what every other piece of C
>>> code on earth depends on. Why be different?
>>
>> By this logic we would check for __x86_64__ everywhere instead of
>> CONFIG_X86. I can't think of a better way to explain this without
>> repeating myself.
>>
>> Bin, do you understand what I am getting at? Are my concerns unwarranted?
>
> I got what you are concerned about. I guess you wanted to say "By this
> logic we would check __x86_64__ everywhere instead of *CONFIG_X86_64*"
> As when CONFIG_X86_64 is defined, the "-m64" flag is passed to
> compiler, and __x86_64__ takes effect. But I think this can only be
> applied in source codes. In makefiles, we still need CONFIG_X86_64.
>
> For the bug we are trying to address here, I believe current patch to
> test __x86_64__ is the simplest way compared to a bunch of config
> options checks. In fact, __x86_64__ contains enough information to fix
> the problem, and the config options checks look superfluous.
>
> How about we add some comments to the changes above to explain some
> more details? Does that look better?
Thanks for looking at this.
Yes comments would really help, thanks.
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 01/13] x86: doc: Fix reference to EFI doc in U-Boot Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 02/13] efi.h: Do not use config options Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-12 19:12 ` Alexander Graf
2018-06-12 22:32 ` Simon Glass
2018-06-12 15:36 ` [U-Boot] [PATCH v2 04/13] x86: efi: Refactor the directory of EFI app and payload support Bin Meng
` (9 subsequent siblings)
12 siblings, 2 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86
64-bit payload does not work anymore. The call to GetMemoryMap()
in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
interpreted as int, but it should actually be long in a 64-bit EFI
environment.
This changes the x86 __kernel_size_t conditionals to use compiler
provided defines instead. That way we always adhere to the build
environment we're in and the definitions adjust automatically.
Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch to "change __kernel_size_t conditionals to use compiler
provided defines"
arch/x86/include/asm/posix_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h
index 717f6cb..a19f1a0 100644
--- a/arch/x86/include/asm/posix_types.h
+++ b/arch/x86/include/asm/posix_types.h
@@ -16,7 +16,7 @@ typedef int __kernel_pid_t;
typedef unsigned short __kernel_ipc_pid_t;
typedef unsigned short __kernel_uid_t;
typedef unsigned short __kernel_gid_t;
-#if CONFIG_IS_ENABLED(X86_64)
+#if defined __x86_64__
typedef unsigned long __kernel_size_t;
typedef long __kernel_ssize_t;
#else
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines
2018-06-12 15:36 ` [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines Bin Meng
@ 2018-06-12 19:12 ` Alexander Graf
2018-06-12 22:32 ` Simon Glass
1 sibling, 0 replies; 36+ messages in thread
From: Alexander Graf @ 2018-06-12 19:12 UTC (permalink / raw)
To: u-boot
On 12.06.18 17:36, Bin Meng wrote:
> Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86
> 64-bit payload does not work anymore. The call to GetMemoryMap()
> in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
> the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
> interpreted as int, but it should actually be long in a 64-bit EFI
> environment.
>
> This changes the x86 __kernel_size_t conditionals to use compiler
> provided defines instead. That way we always adhere to the build
> environment we're in and the definitions adjust automatically.
>
> Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t")
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Alex
>
> ---
>
> Changes in v2:
> - new patch to "change __kernel_size_t conditionals to use compiler
> provided defines"
>
> arch/x86/include/asm/posix_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h
> index 717f6cb..a19f1a0 100644
> --- a/arch/x86/include/asm/posix_types.h
> +++ b/arch/x86/include/asm/posix_types.h
> @@ -16,7 +16,7 @@ typedef int __kernel_pid_t;
> typedef unsigned short __kernel_ipc_pid_t;
> typedef unsigned short __kernel_uid_t;
> typedef unsigned short __kernel_gid_t;
> -#if CONFIG_IS_ENABLED(X86_64)
> +#if defined __x86_64__
> typedef unsigned long __kernel_size_t;
> typedef long __kernel_ssize_t;
> #else
>
^ permalink raw reply [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines
2018-06-12 15:36 ` [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines Bin Meng
2018-06-12 19:12 ` Alexander Graf
@ 2018-06-12 22:32 ` Simon Glass
1 sibling, 0 replies; 36+ messages in thread
From: Simon Glass @ 2018-06-12 22:32 UTC (permalink / raw)
To: u-boot
Hi Bin,
On 12 June 2018 at 09:36, Bin Meng <bmeng.cn@gmail.com> wrote:
> Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86
> 64-bit payload does not work anymore. The call to GetMemoryMap()
> in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since
> the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly
> interpreted as int, but it should actually be long in a 64-bit EFI
> environment.
>
> This changes the x86 __kernel_size_t conditionals to use compiler
> provided defines instead. That way we always adhere to the build
> environment we're in and the definitions adjust automatically.
>
> Fixes: bb0bb91cf0aa ("efi_stub: Use efi_uintn_t")
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - new patch to "change __kernel_size_t conditionals to use compiler
> provided defines"
>
> arch/x86/include/asm/posix_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/posix_types.h b/arch/x86/include/asm/posix_types.h
> index 717f6cb..a19f1a0 100644
> --- a/arch/x86/include/asm/posix_types.h
> +++ b/arch/x86/include/asm/posix_types.h
> @@ -16,7 +16,7 @@ typedef int __kernel_pid_t;
> typedef unsigned short __kernel_ipc_pid_t;
> typedef unsigned short __kernel_uid_t;
> typedef unsigned short __kernel_gid_t;
> -#if CONFIG_IS_ENABLED(X86_64)
> +#if defined __x86_64__
Ick.
I worry that this is hiding an EFI peculiarity in generic code.
We have a lot of occurrences of '-#if CONFIG_IS_ENABLED(X86_64)' and
it is not obvious why this one is wrong and the others are correct. A
change to posix_types will presumably affect other things too.
I'm not sure of the best way to solve this,
Is it possible /sensible to introduce a new CONFIG which selects int
or long for these types? I am not even sure what it could be called,
but then it could normally be set according to the X86_64 setting (in
U-Boot or SPL) but changed by EFI.
Or is this not a config setting, but a modulation of a config setting?
If so, then perhaps we can have:
#if CONFIG_IS_ENABLED(X86_64)
# if <some EFI condition>
#define USE_LONG_FOR_64BIT
#else
#define USE_INT_FOR_64BIT
#else
#define USE_LONG_FOR_64BIT
#endif
But in any case I think we need something explicit for the particular
'64-bit int' needed by this particular build of EFI.
I suppose another possibility is that efi_stub.c should not use
efi_uintn_t and we should just revert that patch? At present the
64-bit stub is quite clearly differentiated from the rest of U-Boot.
Are we just going to end up with a spiderweb of problems here?
> typedef unsigned long __kernel_size_t;
> typedef long __kernel_ssize_t;
> #else
> --
> 2.7.4
>
Regards,
Simon
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 04/13] x86: efi: Refactor the directory of EFI app and payload support
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (2 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 03/13] x86: Change __kernel_size_t conditionals to use compiler provided defines Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 05/13] x86: efi: payload: Add arch_cpu_init() Bin Meng
` (8 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
At present the EFI application and payload support codes in the x86
directory is distributed in a hybrid way. For example, the Kconfig
options for both app and payload are in arch/x86/lib/efi/Kconfig,
but the source codes in the same directory get built only for
CONFIG_EFI_STUB.
This refactors the codes by consolidating all the EFI support codes
into arch/x86/cpu/efi, just like other x86 targets.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- update README.u-boot_on_efi to reflect directory changes
arch/x86/Kconfig | 3 +--
arch/x86/cpu/Makefile | 2 +-
arch/x86/{lib => cpu}/efi/Kconfig | 0
arch/x86/cpu/efi/Makefile | 7 +++++++
arch/x86/{lib => cpu}/efi/car.S | 0
arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} | 0
arch/x86/lib/Makefile | 1 -
arch/x86/lib/efi/Makefile | 7 -------
doc/README.u-boot_on_efi | 6 +-----
9 files changed, 10 insertions(+), 16 deletions(-)
rename arch/x86/{lib => cpu}/efi/Kconfig (100%)
rename arch/x86/{lib => cpu}/efi/car.S (100%)
rename arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} (100%)
delete mode 100644 arch/x86/lib/efi/Makefile
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 18c7fb2..a1c18d2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -112,6 +112,7 @@ source "arch/x86/cpu/braswell/Kconfig"
source "arch/x86/cpu/broadwell/Kconfig"
source "arch/x86/cpu/coreboot/Kconfig"
source "arch/x86/cpu/ivybridge/Kconfig"
+source "arch/x86/cpu/efi/Kconfig"
source "arch/x86/cpu/qemu/Kconfig"
source "arch/x86/cpu/quark/Kconfig"
source "arch/x86/cpu/queensbay/Kconfig"
@@ -772,6 +773,4 @@ config HIGH_TABLE_SIZE
Increse it if the default size does not fit the board's needs.
This is most likely due to a large ACPI DSDT table is used.
-source "arch/x86/lib/efi/Kconfig"
-
endmenu
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index af9e26c..f862d8c 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_INTEL_BAYTRAIL) += baytrail/
obj-$(CONFIG_INTEL_BRASWELL) += braswell/
obj-$(CONFIG_INTEL_BROADWELL) += broadwell/
obj-$(CONFIG_SYS_COREBOOT) += coreboot/
-obj-$(CONFIG_EFI_APP) += efi/
+obj-$(CONFIG_EFI) += efi/
obj-$(CONFIG_QEMU) += qemu/
obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/
obj-$(CONFIG_INTEL_QUARK) += quark/
diff --git a/arch/x86/lib/efi/Kconfig b/arch/x86/cpu/efi/Kconfig
similarity index 100%
rename from arch/x86/lib/efi/Kconfig
rename to arch/x86/cpu/efi/Kconfig
diff --git a/arch/x86/cpu/efi/Makefile b/arch/x86/cpu/efi/Makefile
index 06d0480..32c2dde 100644
--- a/arch/x86/cpu/efi/Makefile
+++ b/arch/x86/cpu/efi/Makefile
@@ -2,5 +2,12 @@
#
# Copyright (c) 2015 Google, Inc
+ifdef CONFIG_EFI_APP
obj-y += efi.o
obj-y += sdram.o
+endif
+
+ifdef CONFIG_EFI_STUB
+obj-y += car.o
+obj-y += payload.o
+endif
diff --git a/arch/x86/lib/efi/car.S b/arch/x86/cpu/efi/car.S
similarity index 100%
rename from arch/x86/lib/efi/car.S
rename to arch/x86/cpu/efi/car.S
diff --git a/arch/x86/lib/efi/efi.c b/arch/x86/cpu/efi/payload.c
similarity index 100%
rename from arch/x86/lib/efi/efi.c
rename to arch/x86/cpu/efi/payload.c
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 0e054da..ba07ac7 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -14,7 +14,6 @@ endif
obj-y += cmd_boot.o
obj-$(CONFIG_SEABIOS) += coreboot_table.o
obj-y += early_cmos.o
-obj-$(CONFIG_EFI) += efi/
obj-y += e820.o
obj-y += init_helpers.o
obj-y += interrupts.o
diff --git a/arch/x86/lib/efi/Makefile b/arch/x86/lib/efi/Makefile
deleted file mode 100644
index f6c6523..0000000
--- a/arch/x86/lib/efi/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# (C) Copyright 2002-2006
-# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
-
-obj-$(CONFIG_EFI_STUB) += car.o
-obj-$(CONFIG_EFI_STUB) += efi.o
diff --git a/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi
index d5903c7..0349c56 100644
--- a/doc/README.u-boot_on_efi
+++ b/doc/README.u-boot_on_efi
@@ -235,12 +235,8 @@ Where is the code?
lib/efi
payload stub, application, support code. Mostly arch-neutral
-arch/x86/lib/efi
- helper functions for the fake DRAM init, etc. These can be used by
- any board that runs as a payload.
-
arch/x86/cpu/efi
- x86 support code for running as an EFI application
+ x86 support code for running as an EFI application and payload
board/efi/efi-x86/efi.c
x86 board code for running as an EFI application
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 04/13] x86: efi: Refactor the directory of EFI app and payload support
2018-06-12 15:36 ` [U-Boot] [PATCH v2 04/13] x86: efi: Refactor the directory of EFI app and payload support Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> At present the EFI application and payload support codes in the x86
> directory is distributed in a hybrid way. For example, the Kconfig
> options for both app and payload are in arch/x86/lib/efi/Kconfig,
> but the source codes in the same directory get built only for
> CONFIG_EFI_STUB.
>
> This refactors the codes by consolidating all the EFI support codes
> into arch/x86/cpu/efi, just like other x86 targets.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - update README.u-boot_on_efi to reflect directory changes
>
> arch/x86/Kconfig | 3 +--
> arch/x86/cpu/Makefile | 2 +-
> arch/x86/{lib => cpu}/efi/Kconfig | 0
> arch/x86/cpu/efi/Makefile | 7 +++++++
> arch/x86/{lib => cpu}/efi/car.S | 0
> arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} | 0
> arch/x86/lib/Makefile | 1 -
> arch/x86/lib/efi/Makefile | 7 -------
> doc/README.u-boot_on_efi | 6 +-----
> 9 files changed, 10 insertions(+), 16 deletions(-)
> rename arch/x86/{lib => cpu}/efi/Kconfig (100%)
> rename arch/x86/{lib => cpu}/efi/car.S (100%)
> rename arch/x86/{lib/efi/efi.c => cpu/efi/payload.c} (100%)
> delete mode 100644 arch/x86/lib/efi/Makefile
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 05/13] x86: efi: payload: Add arch_cpu_init()
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (3 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 04/13] x86: efi: Refactor the directory of EFI app and payload support Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 06/13] x86: Add generic EFI payload support Bin Meng
` (7 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
This adds arch_cpu_init() to the payload codes, in preparation for
supporting a generic efi payload.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/cpu/efi/payload.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
index 81fb8b5..9fd9f57 100644
--- a/arch/x86/cpu/efi/payload.c
+++ b/arch/x86/cpu/efi/payload.c
@@ -5,11 +5,9 @@
*/
#include <common.h>
-#include <debug_uart.h>
#include <efi.h>
#include <errno.h>
-#include <linux/err.h>
-#include <linux/types.h>
+#include <asm/post.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -126,6 +124,13 @@ int dram_init_banksize(void)
return 0;
}
+int arch_cpu_init(void)
+{
+ post_code(POST_CPU_INIT);
+
+ return x86_cpu_init_f();
+}
+
int checkcpu(void)
{
return 0;
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 06/13] x86: Add generic EFI payload support
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (4 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 05/13] x86: efi: payload: Add arch_cpu_init() Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 07/13] x86: Drop QEMU-specific " Bin Meng
` (6 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
It is possible to create a generic EFI payload for all x86 boards.
The payload is configured to include as many generic drivers as
possible. All stuff that touches low-level initialization are not
allowed as such is the EFI BIOS's responsibility. Platform specific
drivers (like gpio, spi, etc) are not included.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- update README.u-boot_on_efi to mention generic EFI payload support
arch/x86/dts/Makefile | 1 +
arch/x86/dts/efi-x86_payload.dts | 36 +++++++++++++++++++++++++++++++++
board/efi/Kconfig | 9 +++++++++
board/efi/efi-x86_payload/Kconfig | 38 +++++++++++++++++++++++++++++++++++
board/efi/efi-x86_payload/MAINTAINERS | 7 +++++++
board/efi/efi-x86_payload/Makefile | 5 +++++
board/efi/efi-x86_payload/start.S | 8 ++++++++
configs/efi-x86_payload32_defconfig | 35 ++++++++++++++++++++++++++++++++
configs/efi-x86_payload64_defconfig | 36 +++++++++++++++++++++++++++++++++
doc/README.u-boot_on_efi | 19 +++++++++---------
include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++
11 files changed, 216 insertions(+), 10 deletions(-)
create mode 100644 arch/x86/dts/efi-x86_payload.dts
create mode 100644 board/efi/efi-x86_payload/Kconfig
create mode 100644 board/efi/efi-x86_payload/MAINTAINERS
create mode 100644 board/efi/efi-x86_payload/Makefile
create mode 100644 board/efi/efi-x86_payload/start.S
create mode 100644 configs/efi-x86_payload32_defconfig
create mode 100644 configs/efi-x86_payload64_defconfig
create mode 100644 include/configs/efi-x86_payload.h
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 7379774..9872c04 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -11,6 +11,7 @@ dtb-y += bayleybay.dtb \
dfi-bt700-q7x-151.dtb \
edison.dtb \
efi.dtb \
+ efi-x86_payload.dtb \
galileo.dtb \
minnowmax.dtb \
qemu-x86_i440fx.dtb \
diff --git a/arch/x86/dts/efi-x86_payload.dts b/arch/x86/dts/efi-x86_payload.dts
new file mode 100644
index 0000000..137bde5
--- /dev/null
+++ b/arch/x86/dts/efi-x86_payload.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * Generic EFI payload device tree for x86 targets
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+/include/ "serial.dtsi"
+/include/ "keyboard.dtsi"
+/include/ "rtc.dtsi"
+/include/ "tsc_timer.dtsi"
+
+/ {
+ model = "EFI x86 Payload";
+ compatible = "efi,x86-payload";
+
+ aliases {
+ serial0 = &serial;
+ };
+
+ config {
+ silent_console = <0>;
+ };
+
+ chosen {
+ stdout-path = "/serial";
+ };
+
+ pci {
+ compatible = "pci-x86";
+ u-boot,dm-pre-reloc;
+ };
+};
diff --git a/board/efi/Kconfig b/board/efi/Kconfig
index 6f86a48..d37f6ff 100644
--- a/board/efi/Kconfig
+++ b/board/efi/Kconfig
@@ -12,8 +12,17 @@ config TARGET_EFI
takes over once the RAM, video and CPU are fully running.
U-Boot is loaded as an application from EFI.
+config TARGET_EFI_PAYLOAD
+ bool "efi payload"
+ help
+ This target is used for running U-Boot on top of EFI. In
+ this case EFI does the early initialisation, and U-Boot
+ takes over once the RAM, video and CPU are fully running.
+ U-Boot is loaded as a payload from EFI.
+
endchoice
source "board/efi/efi-x86/Kconfig"
+source "board/efi/efi-x86_payload/Kconfig"
endif
diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig
new file mode 100644
index 0000000..dcf4de8
--- /dev/null
+++ b/board/efi/efi-x86_payload/Kconfig
@@ -0,0 +1,38 @@
+if TARGET_EFI_PAYLOAD
+
+config SYS_BOARD
+ default "efi-x86_payload"
+
+config SYS_VENDOR
+ default "efi"
+
+config SYS_SOC
+ default "efi"
+
+config SYS_CONFIG_NAME
+ default "efi-x86_payload"
+
+config SYS_TEXT_BASE
+ default 0x00200000
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+ def_bool y
+ imply SYS_NS16550
+ imply SCSI
+ imply SCSI_AHCI
+ imply AHCI_PCI
+ imply MMC
+ imply MMC_PCI
+ imply MMC_SDHCI
+ imply MMC_SDHCI_SDMA
+ imply USB
+ imply USB_EHCI_HCD
+ imply USB_XHCI_HCD
+ imply USB_STORAGE
+ imply USB_KEYBOARD
+ imply E1000
+ imply ETH_DESIGNWARE
+ imply PCH_GBE
+ imply RTL8169
+
+endif
diff --git a/board/efi/efi-x86_payload/MAINTAINERS b/board/efi/efi-x86_payload/MAINTAINERS
new file mode 100644
index 0000000..abf3a15
--- /dev/null
+++ b/board/efi/efi-x86_payload/MAINTAINERS
@@ -0,0 +1,7 @@
+EFI-X86_PAYLOAD BOARD
+M: Bin Meng <bmeng.cn@gmail.com>
+S: Maintained
+F: board/efi/efi-x86_payload/
+F: include/configs/efi-x86_payload.h
+F: configs/efi-x86_payload32_defconfig
+F: configs/efi-x86_payload64_defconfig
diff --git a/board/efi/efi-x86_payload/Makefile b/board/efi/efi-x86_payload/Makefile
new file mode 100644
index 0000000..6982340
--- /dev/null
+++ b/board/efi/efi-x86_payload/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+
+obj-y += start.o
diff --git a/board/efi/efi-x86_payload/start.S b/board/efi/efi-x86_payload/start.S
new file mode 100644
index 0000000..f7eaa7c
--- /dev/null
+++ b/board/efi/efi-x86_payload/start.S
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+.globl early_board_init
+early_board_init:
+ jmp early_board_init_ret
diff --git a/configs/efi-x86_payload32_defconfig b/configs/efi-x86_payload32_defconfig
new file mode 100644
index 0000000..7f0cab0
--- /dev/null
+++ b/configs/efi-x86_payload32_defconfig
@@ -0,0 +1,35 @@
+CONFIG_X86=y
+CONFIG_VENDOR_EFI=y
+CONFIG_DEFAULT_DEVICE_TREE="efi-x86_payload"
+CONFIG_TARGET_EFI_PAYLOAD=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_IDE=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+# CONFIG_PCI_PNP is not set
+CONFIG_EFI=y
+CONFIG_EFI_STUB=y
diff --git a/configs/efi-x86_payload64_defconfig b/configs/efi-x86_payload64_defconfig
new file mode 100644
index 0000000..8d7f3f0
--- /dev/null
+++ b/configs/efi-x86_payload64_defconfig
@@ -0,0 +1,36 @@
+CONFIG_X86=y
+CONFIG_VENDOR_EFI=y
+CONFIG_DEFAULT_DEVICE_TREE="efi-x86_payload"
+CONFIG_TARGET_EFI_PAYLOAD=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_HUSH_PARSER=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_IDE=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+# CONFIG_PCI_PNP is not set
+CONFIG_EFI=y
+CONFIG_EFI_STUB=y
+CONFIG_EFI_STUB_64BIT=y
diff --git a/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi
index 0349c56..8fba112 100644
--- a/doc/README.u-boot_on_efi
+++ b/doc/README.u-boot_on_efi
@@ -71,12 +71,13 @@ Just build U-Boot as normal, e.g.
make efi-x86_defconfig
make
-To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust an
-existing config (like qemu-x86_defconfig) to enable CONFIG_EFI, CONFIG_EFI_STUB
-and either CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT. All of these are
-boolean Kconfig options. Then build U-Boot as normal, e.g.
+To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable
+CONFIG_EFI, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or
+CONFIG_EFI_STUB_64BIT. The efi-x86_payload configs (efi-x86_payload32_defconfig
+and efi-x86_payload32_defconfig) are set up for this. Then build U-Boot as
+normal, e.g.
- make qemu-x86_defconfig
+ make efi-x86_payload32_defconfig (or efi-x86_payload64_defconfig)
make
You will end up with one of these files depending on what you build for:
@@ -211,11 +212,6 @@ Future work
-----------
This work could be extended in a number of ways:
-- Add a generic x86 EFI payload configuration. At present you need to modify
-an existing one, but mostly the low-level x86 code is disabled when booting
-on EFI anyway, so a generic 'EFI' board could be created with a suitable set
-of drivers enabled.
-
- Add ARM support
- Add 64-bit application support
@@ -241,6 +237,9 @@ arch/x86/cpu/efi
board/efi/efi-x86/efi.c
x86 board code for running as an EFI application
+board/efi/efi-x86_payload
+ generic x86 EFI payload board support code
+
common/cmd_efi.c
the 'efi' command
diff --git a/include/configs/efi-x86_payload.h b/include/configs/efi-x86_payload.h
new file mode 100644
index 0000000..9c62fd2
--- /dev/null
+++ b/include/configs/efi-x86_payload.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+/*
+ * board/config.h - configuration options, board specific
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <configs/x86-common.h>
+
+#define CONFIG_SYS_MONITOR_LEN (1 << 20)
+
+#define CONFIG_STD_DEVICES_SETTINGS "stdin=serial,i8042-kbd\0" \
+ "stdout=serial,vidconsole\0" \
+ "stderr=serial,vidconsole\0"
+
+/* ATA/IDE support */
+#define CONFIG_SYS_IDE_MAXBUS 2
+#define CONFIG_SYS_IDE_MAXDEVICE 4
+#define CONFIG_SYS_ATA_BASE_ADDR 0
+#define CONFIG_SYS_ATA_DATA_OFFSET 0
+#define CONFIG_SYS_ATA_REG_OFFSET 0
+#define CONFIG_SYS_ATA_ALT_OFFSET 0
+#define CONFIG_SYS_ATA_IDE0_OFFSET 0x1f0
+#define CONFIG_SYS_ATA_IDE1_OFFSET 0x170
+#define CONFIG_ATAPI
+
+#endif /* __CONFIG_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 06/13] x86: Add generic EFI payload support
2018-06-12 15:36 ` [U-Boot] [PATCH v2 06/13] x86: Add generic EFI payload support Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> It is possible to create a generic EFI payload for all x86 boards.
> The payload is configured to include as many generic drivers as
> possible. All stuff that touches low-level initialization are not
> allowed as such is the EFI BIOS's responsibility. Platform specific
> drivers (like gpio, spi, etc) are not included.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - update README.u-boot_on_efi to mention generic EFI payload support
>
> arch/x86/dts/Makefile | 1 +
> arch/x86/dts/efi-x86_payload.dts | 36 +++++++++++++++++++++++++++++++++
> board/efi/Kconfig | 9 +++++++++
> board/efi/efi-x86_payload/Kconfig | 38 +++++++++++++++++++++++++++++++++++
> board/efi/efi-x86_payload/MAINTAINERS | 7 +++++++
> board/efi/efi-x86_payload/Makefile | 5 +++++
> board/efi/efi-x86_payload/start.S | 8 ++++++++
> configs/efi-x86_payload32_defconfig | 35 ++++++++++++++++++++++++++++++++
> configs/efi-x86_payload64_defconfig | 36 +++++++++++++++++++++++++++++++++
> doc/README.u-boot_on_efi | 19 +++++++++---------
> include/configs/efi-x86_payload.h | 32 +++++++++++++++++++++++++++++
> 11 files changed, 216 insertions(+), 10 deletions(-)
> create mode 100644 arch/x86/dts/efi-x86_payload.dts
> create mode 100644 board/efi/efi-x86_payload/Kconfig
> create mode 100644 board/efi/efi-x86_payload/MAINTAINERS
> create mode 100644 board/efi/efi-x86_payload/Makefile
> create mode 100644 board/efi/efi-x86_payload/start.S
> create mode 100644 configs/efi-x86_payload32_defconfig
> create mode 100644 configs/efi-x86_payload64_defconfig
> create mode 100644 include/configs/efi-x86_payload.h
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 07/13] x86: Drop QEMU-specific EFI payload support
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (5 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 06/13] x86: Add generic EFI payload support Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 08/13] x86: baytrail: Drop EFI-specific test logics Bin Meng
` (5 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
Now that we have generic EFI payload support for all x86 boards,
drop the QEMU-specific one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- update QEMU MAINTAINERS file to remove defconfig files
arch/x86/cpu/qemu/Makefile | 2 --
arch/x86/cpu/qemu/qemu.c | 4 ---
board/emulation/qemu-x86/Kconfig | 6 ++--
board/emulation/qemu-x86/MAINTAINERS | 2 --
configs/qemu-x86_efi_payload32_defconfig | 47 -------------------------------
configs/qemu-x86_efi_payload64_defconfig | 48 --------------------------------
6 files changed, 3 insertions(+), 106 deletions(-)
delete mode 100644 configs/qemu-x86_efi_payload32_defconfig
delete mode 100644 configs/qemu-x86_efi_payload64_defconfig
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
index e5ea925..1761244 100644
--- a/arch/x86/cpu/qemu/Makefile
+++ b/arch/x86/cpu/qemu/Makefile
@@ -2,8 +2,6 @@
#
# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com>
-ifndef CONFIG_EFI_STUB
obj-y += car.o dram.o
-endif
obj-y += qemu.o
obj-$(CONFIG_QFW) += cpu.o e820.o
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 1fdb11c..ca4b3f0 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -143,10 +143,6 @@ int arch_cpu_init(void)
return x86_cpu_init_f();
}
-#endif
-
-#if !CONFIG_IS_ENABLED(EFI_STUB) && \
- !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
int checkcpu(void)
{
diff --git a/board/emulation/qemu-x86/Kconfig b/board/emulation/qemu-x86/Kconfig
index a593f8c..41a27dd 100644
--- a/board/emulation/qemu-x86/Kconfig
+++ b/board/emulation/qemu-x86/Kconfig
@@ -13,12 +13,12 @@ config SYS_CONFIG_NAME
default "qemu-x86"
config SYS_TEXT_BASE
- default 0xfff00000 if !EFI_STUB && !SUPPORT_SPL
- default 0x01110000 if EFI_STUB || SUPPORT_SPL
+ default 0xfff00000 if !SUPPORT_SPL
+ default 0x01110000 if SUPPORT_SPL
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
- select X86_RESET_VECTOR if !EFI_STUB
+ select X86_RESET_VECTOR
select QEMU
select BOARD_ROMSIZE_KB_1024
diff --git a/board/emulation/qemu-x86/MAINTAINERS b/board/emulation/qemu-x86/MAINTAINERS
index 4cf8ac9..9a99d38 100644
--- a/board/emulation/qemu-x86/MAINTAINERS
+++ b/board/emulation/qemu-x86/MAINTAINERS
@@ -4,8 +4,6 @@ S: Maintained
F: board/emulation/qemu-x86/
F: include/configs/qemu-x86.h
F: configs/qemu-x86_defconfig
-F: configs/qemu-x86_efi_payload32_defconfig
-F: configs/qemu-x86_efi_payload64_defconfig
QEMU X86 64-bit BOARD
M: Bin Meng <bmeng.cn@gmail.com>
diff --git a/configs/qemu-x86_efi_payload32_defconfig b/configs/qemu-x86_efi_payload32_defconfig
deleted file mode 100644
index 36705db..0000000
--- a/configs/qemu-x86_efi_payload32_defconfig
+++ /dev/null
@@ -1,47 +0,0 @@
-CONFIG_X86=y
-CONFIG_SYS_TEXT_BASE=0x1110000
-CONFIG_MAX_CPUS=2
-CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
-CONFIG_SMP=y
-CONFIG_FIT=y
-CONFIG_BOOTSTAGE=y
-CONFIG_BOOTSTAGE_REPORT=y
-CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_LAST_STAGE_INIT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_CPU=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_IDE=y
-CONFIG_CMD_PART=y
-CONFIG_CMD_SF=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-# CONFIG_CMD_NFS is not set
-CONFIG_CMD_PING=y
-CONFIG_CMD_TIME=y
-CONFIG_CMD_QFW=y
-CONFIG_CMD_BOOTSTAGE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_MAC_PARTITION=y
-CONFIG_ISO_PARTITION=y
-CONFIG_EFI_PARTITION=y
-CONFIG_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_CPU=y
-CONFIG_SPI=y
-CONFIG_USB_STORAGE=y
-CONFIG_USB_KEYBOARD=y
-CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_FRAMEBUFFER_VESA_MODE_112=y
-CONFIG_CONSOLE_SCROLL_LINES=5
-CONFIG_EFI=y
-CONFIG_EFI_STUB=y
diff --git a/configs/qemu-x86_efi_payload64_defconfig b/configs/qemu-x86_efi_payload64_defconfig
deleted file mode 100644
index 5b0806b..0000000
--- a/configs/qemu-x86_efi_payload64_defconfig
+++ /dev/null
@@ -1,48 +0,0 @@
-CONFIG_X86=y
-CONFIG_SYS_TEXT_BASE=0x1110000
-CONFIG_MAX_CPUS=2
-CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
-CONFIG_SMP=y
-CONFIG_FIT=y
-CONFIG_BOOTSTAGE=y
-CONFIG_BOOTSTAGE_REPORT=y
-CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_LAST_STAGE_INIT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_CPU=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_IDE=y
-CONFIG_CMD_PART=y
-CONFIG_CMD_SF=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-# CONFIG_CMD_NFS is not set
-CONFIG_CMD_PING=y
-CONFIG_CMD_TIME=y
-CONFIG_CMD_QFW=y
-CONFIG_CMD_BOOTSTAGE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_MAC_PARTITION=y
-CONFIG_ISO_PARTITION=y
-CONFIG_EFI_PARTITION=y
-CONFIG_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_CPU=y
-CONFIG_SPI=y
-CONFIG_USB_STORAGE=y
-CONFIG_USB_KEYBOARD=y
-CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_FRAMEBUFFER_VESA_MODE_112=y
-CONFIG_CONSOLE_SCROLL_LINES=5
-CONFIG_EFI=y
-CONFIG_EFI_STUB=y
-CONFIG_EFI_STUB_64BIT=y
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 07/13] x86: Drop QEMU-specific EFI payload support
2018-06-12 15:36 ` [U-Boot] [PATCH v2 07/13] x86: Drop QEMU-specific " Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Now that we have generic EFI payload support for all x86 boards,
> drop the QEMU-specific one.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - update QEMU MAINTAINERS file to remove defconfig files
>
> arch/x86/cpu/qemu/Makefile | 2 --
> arch/x86/cpu/qemu/qemu.c | 4 ---
> board/emulation/qemu-x86/Kconfig | 6 ++--
> board/emulation/qemu-x86/MAINTAINERS | 2 --
> configs/qemu-x86_efi_payload32_defconfig | 47 -------------------------------
> configs/qemu-x86_efi_payload64_defconfig | 48 --------------------------------
> 6 files changed, 3 insertions(+), 106 deletions(-)
> delete mode 100644 configs/qemu-x86_efi_payload32_defconfig
> delete mode 100644 configs/qemu-x86_efi_payload64_defconfig
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 08/13] x86: baytrail: Drop EFI-specific test logics
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (6 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 07/13] x86: Drop QEMU-specific " Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 09/13] efi: stub: Pass EFI GOP information to U-Boot payload Bin Meng
` (4 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
Now that we have generic EFI payload support, drop EFI-specific test
logics in BayTrail Kconfig and codes, and all BayTrail boards too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/cpu/baytrail/Kconfig | 6 +++---
arch/x86/cpu/baytrail/valleyview.c | 3 ---
board/advantech/som-db5800-som-6867/Kconfig | 5 ++---
board/congatec/conga-qeval20-qa3-e3845/Kconfig | 5 ++---
board/dfi/dfi-bt700/Kconfig | 5 ++---
board/intel/minnowmax/Kconfig | 5 ++---
6 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/arch/x86/cpu/baytrail/Kconfig b/arch/x86/cpu/baytrail/Kconfig
index 022a9f2..d2c3473 100644
--- a/arch/x86/cpu/baytrail/Kconfig
+++ b/arch/x86/cpu/baytrail/Kconfig
@@ -4,10 +4,10 @@
config INTEL_BAYTRAIL
bool
- select HAVE_FSP if !EFI
- select ARCH_MISC_INIT if !EFI
+ select HAVE_FSP
+ select ARCH_MISC_INIT
select CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED
- imply HAVE_INTEL_ME if !EFI
+ imply HAVE_INTEL_ME
imply ENABLE_MRC_CACHE
imply AHCI_PCI
imply ICH_SPI
diff --git a/arch/x86/cpu/baytrail/valleyview.c b/arch/x86/cpu/baytrail/valleyview.c
index 3194f8c..b7d481a 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -17,7 +17,6 @@
#define BYT_TRIG_LVL BIT(24)
#define BYT_TRIG_POS BIT(25)
-#ifndef CONFIG_EFI_APP
int arch_cpu_init(void)
{
post_code(POST_CPU_INIT);
@@ -57,8 +56,6 @@ int arch_misc_init(void)
return 0;
}
-#endif
-
void reset_cpu(ulong addr)
{
/* cold reset */
diff --git a/board/advantech/som-db5800-som-6867/Kconfig b/board/advantech/som-db5800-som-6867/Kconfig
index fac562a..35d58fc 100644
--- a/board/advantech/som-db5800-som-6867/Kconfig
+++ b/board/advantech/som-db5800-som-6867/Kconfig
@@ -13,12 +13,11 @@ config SYS_CONFIG_NAME
default "som-db5800-som-6867"
config SYS_TEXT_BASE
- default 0xfff00000 if !EFI_STUB
- default 0x01110000 if EFI_STUB
+ default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
- select X86_RESET_VECTOR if !EFI_STUB
+ select X86_RESET_VECTOR
select INTEL_BAYTRAIL
select BOARD_ROMSIZE_KB_8192
select BOARD_EARLY_INIT_F
diff --git a/board/congatec/conga-qeval20-qa3-e3845/Kconfig b/board/congatec/conga-qeval20-qa3-e3845/Kconfig
index 9e44413..6469250 100644
--- a/board/congatec/conga-qeval20-qa3-e3845/Kconfig
+++ b/board/congatec/conga-qeval20-qa3-e3845/Kconfig
@@ -12,12 +12,11 @@ config SYS_CONFIG_NAME
default "theadorable-x86-conga-qa3-e3845" if TARGET_THEADORABLE_X86_CONGA_QA3_E3845
config SYS_TEXT_BASE
- default 0xfff00000 if !EFI_STUB
- default 0x01110000 if EFI_STUB
+ default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
- select X86_RESET_VECTOR if !EFI_STUB
+ select X86_RESET_VECTOR
select INTEL_BAYTRAIL
select BOARD_ROMSIZE_KB_8192
select BOARD_EARLY_INIT_F
diff --git a/board/dfi/dfi-bt700/Kconfig b/board/dfi/dfi-bt700/Kconfig
index f92f50a..50c7b2a 100644
--- a/board/dfi/dfi-bt700/Kconfig
+++ b/board/dfi/dfi-bt700/Kconfig
@@ -12,12 +12,11 @@ config SYS_CONFIG_NAME
default "theadorable-x86-dfi-bt700" if TARGET_THEADORABLE_X86_DFI_BT700
config SYS_TEXT_BASE
- default 0xfff00000 if !EFI_STUB
- default 0x01110000 if EFI_STUB
+ default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
- select X86_RESET_VECTOR if !EFI_STUB
+ select X86_RESET_VECTOR
select INTEL_BAYTRAIL
select BOARD_ROMSIZE_KB_8192
select BOARD_EARLY_INIT_F
diff --git a/board/intel/minnowmax/Kconfig b/board/intel/minnowmax/Kconfig
index a8668e4..543468c 100644
--- a/board/intel/minnowmax/Kconfig
+++ b/board/intel/minnowmax/Kconfig
@@ -13,12 +13,11 @@ config SYS_CONFIG_NAME
default "minnowmax"
config SYS_TEXT_BASE
- default 0xfff00000 if !EFI_STUB
- default 0x01110000 if EFI_STUB
+ default 0xfff00000
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
- select X86_RESET_VECTOR if !EFI_STUB
+ select X86_RESET_VECTOR
select INTEL_BAYTRAIL
select BOARD_ROMSIZE_KB_8192
select SPI_FLASH_STMICRO
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 08/13] x86: baytrail: Drop EFI-specific test logics
2018-06-12 15:36 ` [U-Boot] [PATCH v2 08/13] x86: baytrail: Drop EFI-specific test logics Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Now that we have generic EFI payload support, drop EFI-specific test
> logics in BayTrail Kconfig and codes, and all BayTrail boards too.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
> arch/x86/cpu/baytrail/Kconfig | 6 +++---
> arch/x86/cpu/baytrail/valleyview.c | 3 ---
> board/advantech/som-db5800-som-6867/Kconfig | 5 ++---
> board/congatec/conga-qeval20-qa3-e3845/Kconfig | 5 ++---
> board/dfi/dfi-bt700/Kconfig | 5 ++---
> board/intel/minnowmax/Kconfig | 5 ++---
> 6 files changed, 11 insertions(+), 18 deletions(-)
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 09/13] efi: stub: Pass EFI GOP information to U-Boot payload
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (7 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 08/13] x86: baytrail: Drop EFI-specific test logics Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 10/13] dm: video: Add an EFI framebuffer driver Bin Meng
` (3 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
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>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
include/efi.h | 35 +++++++++++++++++++++++++++++++++++
lib/efi/efi_stub.c | 15 +++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/include/efi.h b/include/efi.h
index 5e1e8ac..639ace0 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -233,6 +233,7 @@ struct efi_open_protocol_info_entry {
enum efi_entry_t {
EFIET_END, /* Signals this is the last (empty) entry */
EFIET_MEMORY_MAP,
+ EFIET_GOP_MODE,
/* Number of entries */
EFIET_MEMORY_COUNT,
@@ -289,6 +290,40 @@ struct efi_entry_memmap {
struct efi_mem_desc desc[];
};
+/**
+ * struct efi_entry_gopmode - a GOP mode table passed to U-Boot
+ *
+ * @fb_base: EFI's framebuffer base address
+ * @fb_size: EFI's framebuffer size
+ * @info_size: GOP mode info structure size
+ * @info: Start address of the GOP mode info structure
+ */
+struct efi_entry_gopmode {
+ efi_physical_addr_t fb_base;
+ /*
+ * Not like the ones in 'struct efi_gop_mode' which are 'unsigned
+ * long', @fb_size and @info_size have to be 'u64' here. As the EFI
+ * stub codes may have different bit size from the U-Boot payload,
+ * using 'long' will cause mismatch between the producer (stub) and
+ * the consumer (payload).
+ */
+ u64 fb_size;
+ u64 info_size;
+ /*
+ * We cannot directly use 'struct efi_gop_mode_info info[]' here as
+ * it causes compiler to complain: array type has incomplete element
+ * type 'struct efi_gop_mode_info'.
+ */
+ struct /* efi_gop_mode_info */ {
+ u32 version;
+ u32 width;
+ u32 height;
+ u32 pixel_format;
+ u32 pixel_bitmask[4];
+ u32 pixels_per_scanline;
+ } info[];
+};
+
static inline struct efi_mem_desc *efi_get_next_mem_desc(
struct efi_entry_memmap *map, struct efi_mem_desc *desc)
{
diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index 09023a2..4819373 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -274,6 +274,9 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
struct efi_boot_services *boot = sys_table->boottime;
struct efi_mem_desc *desc;
struct efi_entry_memmap map;
+ struct efi_gop *gop;
+ struct efi_entry_gopmode mode;
+ efi_guid_t efi_gop_guid = EFI_GOP_GUID;
efi_uintn_t key, desc_size, size;
efi_status_t ret;
u32 version;
@@ -312,6 +315,18 @@ efi_status_t efi_main(efi_handle_t image, struct efi_system_table *sys_table)
if (ret)
return ret;
+ ret = boot->locate_protocol(&efi_gop_guid, NULL, (void **)&gop);
+ if (ret) {
+ puts(" GOP unavailable\n");
+ } else {
+ mode.fb_base = gop->mode->fb_base;
+ mode.fb_size = gop->mode->fb_size;
+ mode.info_size = gop->mode->info_size;
+ add_entry_addr(priv, EFIET_GOP_MODE, &mode, sizeof(mode),
+ gop->mode->info,
+ sizeof(struct efi_gop_mode_info));
+ }
+
ret = boot->get_memory_map(&size, desc, &key, &desc_size, &version);
if (ret) {
printhex2(ret);
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 10/13] dm: video: Add an EFI framebuffer driver
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (8 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 09/13] efi: stub: Pass EFI GOP information to U-Boot payload Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 11/13] x86: efi: payload: Add EFI framebuffer driver support Bin Meng
` (2 subsequent siblings)
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
This adds a DM video driver for U-Boot as the EFI payload. The driver
makes use of all necessary information from the passed EFI GOP info
to create a linear framebuffer device, as if it were initialized by
U-Boot itself.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
---
Changes in v2: None
drivers/video/Kconfig | 9 +++
drivers/video/Makefile | 1 +
drivers/video/efi.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 156 insertions(+)
create mode 100644 drivers/video/efi.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c4d286..5ee9032 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -156,6 +156,15 @@ config VIDEO_COREBOOT
coreboot already. This can in principle be used with any platform
that coreboot supports.
+config VIDEO_EFI
+ bool "Enable EFI framebuffer driver support"
+ depends on EFI_STUB
+ help
+ Turn on this option to enable a framebuffeer driver when U-Boot is
+ loaded as a payload (see README.u-boot_on_efi) by an EFI BIOS where
+ the graphics device is configured by the EFI BIOS already. This can
+ in principle be used with any platform that has an EFI BIOS.
+
config VIDEO_VESA
bool "Enable VESA video driver support"
default n
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index cf7ad28..7c89c67 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_LD9040) += ld9040.o
obj-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o
obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
+obj-$(CONFIG_VIDEO_EFI) += efi.o
obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o
obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o
obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
diff --git a/drivers/video/efi.c b/drivers/video/efi.c
new file mode 100644
index 0000000..653cb47
--- /dev/null
+++ b/drivers/video/efi.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ *
+ * EFI framebuffer driver based on GOP
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <efi_api.h>
+#include <vbe.h>
+#include <video.h>
+
+struct pixel {
+ u8 pos;
+ u8 size;
+};
+
+static const struct efi_framebuffer {
+ struct pixel red;
+ struct pixel green;
+ struct pixel blue;
+ struct pixel rsvd;
+} efi_framebuffer_format_map[] = {
+ [EFI_GOT_RGBA8] = { {0, 8}, {8, 8}, {16, 8}, {24, 8} },
+ [EFI_GOT_BGRA8] = { {16, 8}, {8, 8}, {0, 8}, {24, 8} },
+};
+
+static void efi_find_pixel_bits(u32 mask, u8 *pos, u8 *size)
+{
+ u8 first, len;
+
+ first = 0;
+ len = 0;
+
+ if (mask) {
+ while (!(mask & 0x1)) {
+ mask = mask >> 1;
+ first++;
+ }
+
+ while (mask & 0x1) {
+ mask = mask >> 1;
+ len++;
+ }
+ }
+
+ *pos = first;
+ *size = len;
+}
+
+static int save_vesa_mode(struct vesa_mode_info *vesa)
+{
+ struct efi_entry_gopmode *mode;
+ const struct efi_framebuffer *fbinfo;
+ int size;
+ int ret;
+
+ ret = efi_info_get(EFIET_GOP_MODE, (void **)&mode, &size);
+ if (ret == -ENOENT) {
+ debug("efi graphics output protocol mode not found\n");
+ return -ENXIO;
+ }
+
+ vesa->phys_base_ptr = mode->fb_base;
+ vesa->x_resolution = mode->info->width;
+ vesa->y_resolution = mode->info->height;
+
+ if (mode->info->pixel_format < EFI_GOT_BITMASK) {
+ fbinfo = &efi_framebuffer_format_map[mode->info->pixel_format];
+ vesa->red_mask_size = fbinfo->red.size;
+ vesa->red_mask_pos = fbinfo->red.pos;
+ vesa->green_mask_size = fbinfo->green.size;
+ vesa->green_mask_pos = fbinfo->green.pos;
+ vesa->blue_mask_size = fbinfo->blue.size;
+ vesa->blue_mask_pos = fbinfo->blue.pos;
+ vesa->reserved_mask_size = fbinfo->rsvd.size;
+ vesa->reserved_mask_pos = fbinfo->rsvd.pos;
+
+ vesa->bits_per_pixel = 32;
+ vesa->bytes_per_scanline = mode->info->pixels_per_scanline * 4;
+ } else if (mode->info->pixel_format == EFI_GOT_BITMASK) {
+ efi_find_pixel_bits(mode->info->pixel_bitmask[0],
+ &vesa->red_mask_pos,
+ &vesa->red_mask_size);
+ efi_find_pixel_bits(mode->info->pixel_bitmask[1],
+ &vesa->green_mask_pos,
+ &vesa->green_mask_size);
+ efi_find_pixel_bits(mode->info->pixel_bitmask[2],
+ &vesa->blue_mask_pos,
+ &vesa->blue_mask_size);
+ efi_find_pixel_bits(mode->info->pixel_bitmask[3],
+ &vesa->reserved_mask_pos,
+ &vesa->reserved_mask_size);
+ vesa->bits_per_pixel = vesa->red_mask_size +
+ vesa->green_mask_size +
+ vesa->blue_mask_size +
+ vesa->reserved_mask_size;
+ vesa->bytes_per_scanline = (mode->info->pixels_per_scanline *
+ vesa->bits_per_pixel) / 8;
+ } else {
+ debug("efi set unknown framebuffer format: %d\n",
+ mode->info->pixel_format);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int efi_video_probe(struct udevice *dev)
+{
+ struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+ struct video_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct vesa_mode_info *vesa = &mode_info.vesa;
+ int ret;
+
+ /* Initialize vesa_mode_info structure */
+ ret = save_vesa_mode(vesa);
+ if (ret)
+ goto err;
+
+ ret = vbe_setup_video_priv(vesa, uc_priv, plat);
+ if (ret)
+ goto err;
+
+ printf("Video: %dx%dx%d\n", uc_priv->xsize, uc_priv->ysize,
+ vesa->bits_per_pixel);
+
+ return 0;
+
+err:
+ printf("No video mode configured in EFI!\n");
+ return ret;
+}
+
+static const struct udevice_id efi_video_ids[] = {
+ { .compatible = "efi-fb" },
+ { }
+};
+
+U_BOOT_DRIVER(efi_video) = {
+ .name = "efi_video",
+ .id = UCLASS_VIDEO,
+ .of_match = efi_video_ids,
+ .probe = efi_video_probe,
+};
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 10/13] dm: video: Add an EFI framebuffer driver
2018-06-12 15:36 ` [U-Boot] [PATCH v2 10/13] dm: video: Add an EFI framebuffer driver Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> This adds a DM video driver for U-Boot as the EFI payload. The driver
> makes use of all necessary information from the passed EFI GOP info
> to create a linear framebuffer device, as if it were initialized by
> U-Boot itself.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Anatolij Gustschin <agust@denx.de>
> ---
>
> Changes in v2: None
>
> drivers/video/Kconfig | 9 +++
> drivers/video/Makefile | 1 +
> drivers/video/efi.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 156 insertions(+)
> create mode 100644 drivers/video/efi.c
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 11/13] x86: efi: payload: Add EFI framebuffer driver support
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (9 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 10/13] dm: video: Add an EFI framebuffer driver Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 12/13] x86: Rename efi-x86 target to efi-x86_app Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 13/13] x86: efi: app: Display correct CPU info during boot Bin Meng
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
This turns on the EFI framebuffer driver support so that a graphics
console can be of additional help.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2: None
arch/x86/dts/efi-x86_payload.dts | 4 ++++
board/efi/efi-x86_payload/Kconfig | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/x86/dts/efi-x86_payload.dts b/arch/x86/dts/efi-x86_payload.dts
index 137bde5..148b587 100644
--- a/arch/x86/dts/efi-x86_payload.dts
+++ b/arch/x86/dts/efi-x86_payload.dts
@@ -33,4 +33,8 @@
compatible = "pci-x86";
u-boot,dm-pre-reloc;
};
+
+ efi-fb {
+ compatible = "efi-fb";
+ };
};
diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig
index dcf4de8..b6e57b9 100644
--- a/board/efi/efi-x86_payload/Kconfig
+++ b/board/efi/efi-x86_payload/Kconfig
@@ -30,6 +30,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply USB_XHCI_HCD
imply USB_STORAGE
imply USB_KEYBOARD
+ imply VIDEO_EFI
imply E1000
imply ETH_DESIGNWARE
imply PCH_GBE
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 12/13] x86: Rename efi-x86 target to efi-x86_app
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (10 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 11/13] x86: efi: payload: Add EFI framebuffer driver support Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
2018-06-12 15:36 ` [U-Boot] [PATCH v2 13/13] x86: efi: app: Display correct CPU info during boot Bin Meng
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- update README.u-boot_on_efi to use efi-x86_app
arch/x86/cpu/efi/Makefile | 2 +-
arch/x86/cpu/efi/{efi.c => app.c} | 0
arch/x86/cpu/intel_common/Makefile | 2 +-
arch/x86/dts/Makefile | 2 +-
arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 ++--
board/efi/Kconfig | 6 +++---
board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +++---
board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0
board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +-
board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0
configs/{efi-x86_defconfig => efi-x86_app_defconfig} | 4 ++--
doc/README.u-boot_on_efi | 8 ++++----
include/configs/{efi-x86.h => efi-x86_app.h} | 0
13 files changed, 18 insertions(+), 18 deletions(-)
rename arch/x86/cpu/efi/{efi.c => app.c} (100%)
rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%)
rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%)
rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%)
rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%)
rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%)
rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (92%)
rename include/configs/{efi-x86.h => efi-x86_app.h} (100%)
diff --git a/arch/x86/cpu/efi/Makefile b/arch/x86/cpu/efi/Makefile
index 32c2dde..9716a4e 100644
--- a/arch/x86/cpu/efi/Makefile
+++ b/arch/x86/cpu/efi/Makefile
@@ -3,7 +3,7 @@
# Copyright (c) 2015 Google, Inc
ifdef CONFIG_EFI_APP
-obj-y += efi.o
+obj-y += app.o
obj-y += sdram.o
endif
diff --git a/arch/x86/cpu/efi/efi.c b/arch/x86/cpu/efi/app.c
similarity index 100%
rename from arch/x86/cpu/efi/efi.c
rename to arch/x86/cpu/efi/app.c
diff --git a/arch/x86/cpu/intel_common/Makefile b/arch/x86/cpu/intel_common/Makefile
index c0fcf0c..bf798c2 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += mrc.o
endif
obj-y += cpu.o
obj-y += lpc.o
-ifndef CONFIG_TARGET_EFI
+ifndef CONFIG_TARGET_EFI_APP
obj-y += microcode.o
endif
obj-y += pch.o
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 9872c04..37e4fdc 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -10,7 +10,7 @@ dtb-y += bayleybay.dtb \
crownbay.dtb \
dfi-bt700-q7x-151.dtb \
edison.dtb \
- efi.dtb \
+ efi-x86_app.dtb \
efi-x86_payload.dtb \
galileo.dtb \
minnowmax.dtb \
diff --git a/arch/x86/dts/efi.dts b/arch/x86/dts/efi-x86_app.dts
similarity index 82%
rename from arch/x86/dts/efi.dts
rename to arch/x86/dts/efi-x86_app.dts
index 62ae96a..e70e351 100644
--- a/arch/x86/dts/efi.dts
+++ b/arch/x86/dts/efi-x86_app.dts
@@ -9,8 +9,8 @@
/include/ "tsc_timer.dtsi"
/ {
- model = "EFI";
- compatible = "efi,app";
+ model = "EFI x86 Application";
+ compatible = "efi,x86-app";
chosen {
stdout-path = &serial;
diff --git a/board/efi/Kconfig b/board/efi/Kconfig
index d37f6ff..291bd2c 100644
--- a/board/efi/Kconfig
+++ b/board/efi/Kconfig
@@ -4,8 +4,8 @@ choice
prompt "Mainboard model"
optional
-config TARGET_EFI
- bool "efi"
+config TARGET_EFI_APP
+ bool "efi application"
help
This target is used for running U-Boot on top of EFI. In
this case EFI does the early initialisation, and U-Boot
@@ -22,7 +22,7 @@ config TARGET_EFI_PAYLOAD
endchoice
-source "board/efi/efi-x86/Kconfig"
+source "board/efi/efi-x86_app/Kconfig"
source "board/efi/efi-x86_payload/Kconfig"
endif
diff --git a/board/efi/efi-x86/Kconfig b/board/efi/efi-x86_app/Kconfig
similarity index 64%
rename from board/efi/efi-x86/Kconfig
rename to board/efi/efi-x86_app/Kconfig
index fa609ba..ae87bf3 100644
--- a/board/efi/efi-x86/Kconfig
+++ b/board/efi/efi-x86_app/Kconfig
@@ -1,7 +1,7 @@
-if TARGET_EFI
+if TARGET_EFI_APP
config SYS_BOARD
- default "efi-x86"
+ default "efi-x86_app"
config SYS_VENDOR
default "efi"
@@ -10,6 +10,6 @@ config SYS_SOC
default "efi"
config SYS_CONFIG_NAME
- default "efi-x86"
+ default "efi-x86_app"
endif
diff --git a/board/efi/efi-x86/MAINTAINERS b/board/efi/efi-x86_app/MAINTAINERS
similarity index 100%
rename from board/efi/efi-x86/MAINTAINERS
rename to board/efi/efi-x86_app/MAINTAINERS
diff --git a/board/efi/efi-x86/Makefile b/board/efi/efi-x86_app/Makefile
similarity index 82%
rename from board/efi/efi-x86/Makefile
rename to board/efi/efi-x86_app/Makefile
index 2097283..cb48d1c 100644
--- a/board/efi/efi-x86/Makefile
+++ b/board/efi/efi-x86_app/Makefile
@@ -2,4 +2,4 @@
#
# Copyright (c) 2015 Google, Inc
-obj-y += efi.o
+obj-y += app.o
diff --git a/board/efi/efi-x86/efi.c b/board/efi/efi-x86_app/app.c
similarity index 100%
rename from board/efi/efi-x86/efi.c
rename to board/efi/efi-x86_app/app.c
diff --git a/configs/efi-x86_defconfig b/configs/efi-x86_app_defconfig
similarity index 92%
rename from configs/efi-x86_defconfig
rename to configs/efi-x86_app_defconfig
index a2f072b..9c1d5e7 100644
--- a/configs/efi-x86_defconfig
+++ b/configs/efi-x86_app_defconfig
@@ -2,8 +2,8 @@ CONFIG_X86=y
CONFIG_DEBUG_UART_BASE=0
CONFIG_DEBUG_UART_CLOCK=0
CONFIG_VENDOR_EFI=y
-CONFIG_DEFAULT_DEVICE_TREE="efi"
-CONFIG_TARGET_EFI=y
+CONFIG_DEFAULT_DEVICE_TREE="efi-x86_app"
+CONFIG_TARGET_EFI_APP=y
CONFIG_DEBUG_UART=y
CONFIG_FIT=y
CONFIG_USE_BOOTARGS=y
diff --git a/doc/README.u-boot_on_efi b/doc/README.u-boot_on_efi
index 8fba112..e12dd4e 100644
--- a/doc/README.u-boot_on_efi
+++ b/doc/README.u-boot_on_efi
@@ -65,10 +65,10 @@ for that board. It will be either 32-bit or 64-bit. Alternatively, you can
opt for using QEMU [1] and the OVMF [2], as detailed below.
To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
-and CONFIG_EFI_APP. The efi-x86 config (efi-x86_defconfig) is set up for this.
-Just build U-Boot as normal, e.g.
+and CONFIG_EFI_APP. The efi-x86_app config (efi-x86_app_defconfig) is set up
+for this. Just build U-Boot as normal, e.g.
- make efi-x86_defconfig
+ make efi-x86_app_defconfig
make
To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable
@@ -234,7 +234,7 @@ lib/efi
arch/x86/cpu/efi
x86 support code for running as an EFI application and payload
-board/efi/efi-x86/efi.c
+board/efi/efi-x86_app/efi.c
x86 board code for running as an EFI application
board/efi/efi-x86_payload
diff --git a/include/configs/efi-x86.h b/include/configs/efi-x86_app.h
similarity index 100%
rename from include/configs/efi-x86.h
rename to include/configs/efi-x86_app.h
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 12/13] x86: Rename efi-x86 target to efi-x86_app
2018-06-12 15:36 ` [U-Boot] [PATCH v2 12/13] x86: Rename efi-x86 target to efi-x86_app Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - update README.u-boot_on_efi to use efi-x86_app
>
> arch/x86/cpu/efi/Makefile | 2 +-
> arch/x86/cpu/efi/{efi.c => app.c} | 0
> arch/x86/cpu/intel_common/Makefile | 2 +-
> arch/x86/dts/Makefile | 2 +-
> arch/x86/dts/{efi.dts => efi-x86_app.dts} | 4 ++--
> board/efi/Kconfig | 6 +++---
> board/efi/{efi-x86 => efi-x86_app}/Kconfig | 6 +++---
> board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS | 0
> board/efi/{efi-x86 => efi-x86_app}/Makefile | 2 +-
> board/efi/{efi-x86/efi.c => efi-x86_app/app.c} | 0
> configs/{efi-x86_defconfig => efi-x86_app_defconfig} | 4 ++--
> doc/README.u-boot_on_efi | 8 ++++----
> include/configs/{efi-x86.h => efi-x86_app.h} | 0
> 13 files changed, 18 insertions(+), 18 deletions(-)
> rename arch/x86/cpu/efi/{efi.c => app.c} (100%)
> rename arch/x86/dts/{efi.dts => efi-x86_app.dts} (82%)
> rename board/efi/{efi-x86 => efi-x86_app}/Kconfig (64%)
> rename board/efi/{efi-x86 => efi-x86_app}/MAINTAINERS (100%)
> rename board/efi/{efi-x86 => efi-x86_app}/Makefile (82%)
> rename board/efi/{efi-x86/efi.c => efi-x86_app/app.c} (100%)
> rename configs/{efi-x86_defconfig => efi-x86_app_defconfig} (92%)
> rename include/configs/{efi-x86.h => efi-x86_app.h} (100%)
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread
* [U-Boot] [PATCH v2 13/13] x86: efi: app: Display correct CPU info during boot
2018-06-12 15:36 [U-Boot] [PATCH v2 00/13] x86: efi: Fixes and enhancements to application and payload support Bin Meng
` (11 preceding siblings ...)
2018-06-12 15:36 ` [U-Boot] [PATCH v2 12/13] x86: Rename efi-x86 target to efi-x86_app Bin Meng
@ 2018-06-12 15:36 ` Bin Meng
2018-06-17 13:18 ` Bin Meng
12 siblings, 1 reply; 36+ messages in thread
From: Bin Meng @ 2018-06-12 15:36 UTC (permalink / raw)
To: u-boot
Currently when EFI application boots, it says:
CPU: x86_64, vendor <invalid cpu vendor>, device 0h
Fix this by calling x86_cpu_init_f() in arch_cpu_init().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- drop patches that were already applied to u-boot-x86
arch/x86/cpu/efi/app.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/efi/app.c b/arch/x86/cpu/efi/app.c
index cda4fab..ba7c02b 100644
--- a/arch/x86/cpu/efi/app.c
+++ b/arch/x86/cpu/efi/app.c
@@ -9,7 +9,7 @@
int arch_cpu_init(void)
{
- return 0;
+ return x86_cpu_init_f();
}
int checkcpu(void)
--
2.7.4
^ permalink raw reply related [flat|nested] 36+ messages in thread* [U-Boot] [PATCH v2 13/13] x86: efi: app: Display correct CPU info during boot
2018-06-12 15:36 ` [U-Boot] [PATCH v2 13/13] x86: efi: app: Display correct CPU info during boot Bin Meng
@ 2018-06-17 13:18 ` Bin Meng
0 siblings, 0 replies; 36+ messages in thread
From: Bin Meng @ 2018-06-17 13:18 UTC (permalink / raw)
To: u-boot
On Tue, Jun 12, 2018 at 11:36 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Currently when EFI application boots, it says:
>
> CPU: x86_64, vendor <invalid cpu vendor>, device 0h
>
> Fix this by calling x86_cpu_init_f() in arch_cpu_init().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> ---
>
> Changes in v2:
> - drop patches that were already applied to u-boot-x86
>
> arch/x86/cpu/efi/app.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
applied to u-boot-x86, thanks!
^ permalink raw reply [flat|nested] 36+ messages in thread