| Message ID | 1528637118-32739-5-git-send-email-bmeng.cn@gmail.com |
|---|---|
| State | Accepted |
| Commit | 16dde8945ea948e675e48326e740e098dea2035e |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | x86: efi: Fixes and enhancements to application and payload support | expand |
On 10.06.18 15:25, Bin Meng wrote: > Attempting to use a toolchain that is preconfigured to generate code > for the 32-bit architecture (i386), for example, the i386-linux-gcc > toolchain on kernel.org, to compile the 64-bit EFI payload does not > build. This updates the makefile fragments to ensure '-m64' is passed > to toolchain when building the 64-bit EFI payload stub codes. > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Is there any sane reason to keep the split between EFI and U-Boot long size alive? The x86_64 U-Boot port is getting along reasonably well from what I can tell and 32bit UEFI implementations on 64-bit hosts are dying out. So can't we just remove all of that cruft altogether instead and just have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI stub as only combinations? That would dramatically simplify the code. Alex
On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf <agraf@suse.de> wrote: > > > On 10.06.18 15:25, Bin Meng wrote: >> Attempting to use a toolchain that is preconfigured to generate code >> for the 32-bit architecture (i386), for example, the i386-linux-gcc >> toolchain on kernel.org, to compile the 64-bit EFI payload does not >> build. This updates the makefile fragments to ensure '-m64' is passed >> to toolchain when building the 64-bit EFI payload stub codes. >> >> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > > Is there any sane reason to keep the split between EFI and U-Boot long > size alive? The x86_64 U-Boot port is getting along reasonably well from > what I can tell and 32bit UEFI implementations on 64-bit hosts are dying > out. > I think you are mixing two type of things. U-Boot building as 32-bit or 64-bit is one thing. How to build U-Boot is another thing. This patch was to address the build. > So can't we just remove all of that cruft altogether instead and just > have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI > stub as only combinations? > Some day once U-Boot x86_64 support is mature, we can consider that. Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that does not mean i386-linux-gcc cannot be used. '-m64' is required to pass to such toolchain to cross-compile 64-bit codes correctly. > That would dramatically simplify the code. > Regards, Bin
On 11.06.18 04:34, Bin Meng wrote: > On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf <agraf@suse.de> wrote: >> >> >> On 10.06.18 15:25, Bin Meng wrote: >>> Attempting to use a toolchain that is preconfigured to generate code >>> for the 32-bit architecture (i386), for example, the i386-linux-gcc >>> toolchain on kernel.org, to compile the 64-bit EFI payload does not >>> build. This updates the makefile fragments to ensure '-m64' is passed >>> to toolchain when building the 64-bit EFI payload stub codes. >>> >>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >> >> Is there any sane reason to keep the split between EFI and U-Boot long >> size alive? The x86_64 U-Boot port is getting along reasonably well from >> what I can tell and 32bit UEFI implementations on 64-bit hosts are dying >> out. >> > > I think you are mixing two type of things. U-Boot building as 32-bit > or 64-bit is one thing. How to build U-Boot is another thing. This > patch was to address the build. > >> So can't we just remove all of that cruft altogether instead and just >> have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI >> stub as only combinations? >> > > Some day once U-Boot x86_64 support is mature, we can consider that. > Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that > does not mean i386-linux-gcc cannot be used. '-m64' is required to > pass to such toolchain to cross-compile 64-bit codes correctly. Yes, but then all of this would be unconditional for the full code base and not depend on CONFIG_EFI_STUB_64BIT at all :). I'm just wary that the efi payload code is quite hard to follow with all the combinations of 32/64 payload/u-boot bitnesses. Alex
Hi Alex, On Mon, Jun 11, 2018 at 1:55 PM, Alexander Graf <agraf@suse.de> wrote: > > > On 11.06.18 04:34, Bin Meng wrote: >> On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf <agraf@suse.de> wrote: >>> >>> >>> On 10.06.18 15:25, Bin Meng wrote: >>>> Attempting to use a toolchain that is preconfigured to generate code >>>> for the 32-bit architecture (i386), for example, the i386-linux-gcc >>>> toolchain on kernel.org, to compile the 64-bit EFI payload does not >>>> build. This updates the makefile fragments to ensure '-m64' is passed >>>> to toolchain when building the 64-bit EFI payload stub codes. >>>> >>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>> >>> Is there any sane reason to keep the split between EFI and U-Boot long >>> size alive? The x86_64 U-Boot port is getting along reasonably well from >>> what I can tell and 32bit UEFI implementations on 64-bit hosts are dying >>> out. >>> >> >> I think you are mixing two type of things. U-Boot building as 32-bit >> or 64-bit is one thing. How to build U-Boot is another thing. This >> patch was to address the build. >> >>> So can't we just remove all of that cruft altogether instead and just >>> have x86_64 U-Boot with 64bit EFI stub and i386 U-Boot with 32bit EFI >>> stub as only combinations? >>> >> >> Some day once U-Boot x86_64 support is mature, we can consider that. >> Even if we only support 64-bit U-Boot as the 64-bit EFI payload, that >> does not mean i386-linux-gcc cannot be used. '-m64' is required to >> pass to such toolchain to cross-compile 64-bit codes correctly. > > Yes, but then all of this would be unconditional for the full code base > and not depend on CONFIG_EFI_STUB_64BIT at all :). > No, it is not unconditional. The '-m64' flag will only be added when compiling efi_stub.c if CONFIG_EFI_STUB_64BIT is on. See below. CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB \ $(if $(CONFIG_EFI_STUB_64BIT),-m64) > I'm just wary that the efi payload code is quite hard to follow with all > the combinations of 32/64 payload/u-boot bitnesses. Yes, but not that bad. Still manageable :) Regards, Bin
On 10 June 2018 at 05:25, Bin Meng <bmeng.cn@gmail.com> wrote: > Attempting to use a toolchain that is preconfigured to generate code > for the 32-bit architecture (i386), for example, the i386-linux-gcc > toolchain on kernel.org, to compile the 64-bit EFI payload does not > build. This updates the makefile fragments to ensure '-m64' is passed > to toolchain when building the 64-bit EFI payload stub codes. > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > --- > > arch/x86/cpu/Makefile | 3 ++- > arch/x86/lib/Makefile | 4 ++-- > lib/efi/Makefile | 6 ++++-- > 3 files changed, 8 insertions(+), 5 deletions(-) > Reviewed-by: Simon Glass <sjg@chromium.org> Nice to get this working with an i386 compiler!
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass <sjg@chromium.org> wrote: > On 10 June 2018 at 05:25, Bin Meng <bmeng.cn@gmail.com> wrote: >> Attempting to use a toolchain that is preconfigured to generate code >> for the 32-bit architecture (i386), for example, the i386-linux-gcc >> toolchain on kernel.org, to compile the 64-bit EFI payload does not >> build. This updates the makefile fragments to ensure '-m64' is passed >> to toolchain when building the 64-bit EFI payload stub codes. >> >> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >> --- >> >> arch/x86/cpu/Makefile | 3 ++- >> arch/x86/lib/Makefile | 4 ++-- >> lib/efi/Makefile | 6 ++++-- >> 3 files changed, 8 insertions(+), 5 deletions(-) >> > > Reviewed-by: Simon Glass <sjg@chromium.org> > > Nice to get this working with an i386 compiler! applied to u-boot-x86, thanks!
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index d5a17d0..af9e26c 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -18,7 +18,8 @@ obj-y += cpu.o cpu_x86.o ifndef CONFIG_$(SPL_)X86_64 AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) -AFLAGS_call32.o := -fpic -fshort-wchar +AFLAGS_call32.o := -fpic -fshort-wchar \ + $(if $(CONFIG_EFI_STUB_64BIT),-m64) extra-y += call32.o endif diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 2adb236..112ac3d 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -58,10 +58,10 @@ CFLAGS_reloc_ia32_efi.o += -fpic -fshort-wchar # When building for 64-bit we must remove the i386-specific flags CFLAGS_REMOVE_reloc_x86_64_efi.o += -mregparm=3 -march=i386 -m32 -CFLAGS_reloc_x86_64_efi.o += -fpic -fshort-wchar +CFLAGS_reloc_x86_64_efi.o += -fpic -fshort-wchar -m64 AFLAGS_REMOVE_crt0_x86_64_efi.o += -mregparm=3 -march=i386 -m32 -AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar +AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar -m64 extra-$(CONFIG_EFI_STUB_32BIT) += crt0_ia32_efi.o reloc_ia32_efi.o extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o diff --git a/lib/efi/Makefile b/lib/efi/Makefile index 18d081a..f1a3929 100644 --- a/lib/efi/Makefile +++ b/lib/efi/Makefile @@ -7,9 +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 -DEFI_STUB \ + $(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 -DEFI_STUB \ + $(if $(CONFIG_EFI_STUB_64BIT),-m64) extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when building the 64-bit EFI payload stub codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> --- arch/x86/cpu/Makefile | 3 ++- arch/x86/lib/Makefile | 4 ++-- lib/efi/Makefile | 6 ++++-- 3 files changed, 8 insertions(+), 5 deletions(-)