On 11.06.18 04:34, Bin Meng wrote: > On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf <ag...@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...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
