Hi Philippe,

On Sat, 27 Sept 2025 at 14:36, Philippe Simons
<simons.philippe@gmail.com> wrote:
>
>
>
> On Fri, Sep 26, 2025 at 1:29 PM Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Philippe,
>>
>> On Thu, 25 Sept 2025 at 15:18, Philippe Simons
>> <simons.philippe@gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Sep 24, 2025 at 5:49 PM Simon Glass <sjg@chromium.org> wrote:
>> >>
>> >> Hi Philippe,
>> >>
>> >> On Wed, 24 Sept 2025 at 06:04, Philippe Simons
>> >> <simons.philippe@gmail.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, 24 Sept 2025, 13:04 Simon Glass, <sjg@chromium.org> wrote:
>> >> >>
>> >> >> Hi Philippe,
>> >> >>
>> >> >> On Wed, 24 Sept 2025 at 04:54, Philippe Simons
>> >> >> <simons.philippe@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Wed, 24 Sept 2025, 12:50 Simon Glass, <sjg@chromium.org> wrote:
>> >> >> >>
>> >> >> >> Hi Philippe,
>> >> >> >>
>> >> >> >> On Wed, 24 Sept 2025 at 03:52, Philippe Simons
>> >> >> >> <simons.philippe@gmail.com> wrote:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Wed, 24 Sept 2025, 00:35 Simon Glass, <sjg@chromium.org> wrote:
>> >> >> >> >>
>> >> >> >> >> Hi Philippe,
>> >> >> >> >>
>> >> >> >> >> On Tue, 23 Sept 2025 at 16:24, Philippe Simons
>> >> >> >> >> <simons.philippe@gmail.com> wrote:
>> >> >> >> >> >
>> >> >> >> >> > I'm currently trying to bring a SM6115 device on Linux but... without much success...
>> >> >> >> >> > I have replaced my ABL with qcomm/abl2eps which allows me to boot an efi application.
>> >> >> >> >> >
>> >> >> >> >> > I've tried to use ARM64 EFI STUB for that but the resulting u-boot-efi-payload.efi doesn't look like an PE32+ binary....
>> >> >> >> >> >
>> >> >> >> >> > file u-boot-payload.efi
>> >> >> >> >> > u-boot-payload.efi: data
>> >> >> >> >>
>> >> >> >> >> Which board are you building here? Is this with the concept tree?
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Trying to build for the Mangmi AirX handheld, a SM6115. I'm using the concept tree yes.
>> >> >> >>
>> >> >> >> I'm actually wondering which U-Boot board (defconfig) you are using /
>> >> >> >> building? If you created something new, can you send a link to your
>> >> >> >> tree?
>> >> >> >
>> >> >> >
>> >> >> > Oh, I attached the defconfig to my first post, but maybe it didn't go through...
>> >> >> > I basically used the qcom_defconfig, added CONFIG_EFI_CLIENT, CONFIG_EFI_STUB and my device tree.
>> >> >>
>> >> >> OK...which toolchain version are you using?
>> >> >
>> >> >
>> >> > GCC 14.2, but not a specific tool chain released by a distribution... It's build from scratch (like BuildRoot)
>> >>
>> >> OK, yes this is very strange. For now the only thing I can suggest is
>> >> to revert this:
>> >>
>> >> 7fa6a68131d efi: arm: Simplify the crt0 file and update link script
>> >
>> >
>> > Same as with HEAD... the u-boot-payload.efi is not a PE32+ file...
>> > I guess some Makefile mess... I'll try to hunt it, but Makefile is not really my domain...
>> > seems like OBJCOPYFLAGS_EFI += -O binary --target=efi-app-aarch64 get lost somewhere
>>
>> It definitely works for me. I sent two patches to show this [2].
>
>
> with these patches, it's a little "better"
> $file u-boot-payload.efi
> u-boot-payload.efi: Linux kernel ARM64 boot executable Image, little-endian
>
> but abl2eps is still unable to start it, as it is expecting a PE32+ file
>
> I tried with a Ubuntu 24.04 Docker using distrib gcc cross compiler also, but result is the same

What is abl2eps? Do you get any sort of error? Have you been able to

build a PE32+ with another project or build system, so you can compare
them?

PE32+ is not quite the same as EFI, as I understand it (subsystem ID
or magic?). You might need to change the header in
arch/arm/lib/crt0_aarch64_efi.S to fit what abl2eps expects.

Regards,
Simon

>
>>
>>
>> Having said that, this is only useful for development. We'll have to
>> figure out the real solution.
>>
>> Let me know if this works.
>>
>> >
>> >>
>> >> There is a trivial conflict but you can just add the code back. There
>> >> must be some condition controlling when it emits the PE header, but
>> >> I'm not sure what it is at this point. If you are able to figure it
>> >> out, please send a patch. At some point I'm hoping to get this work
>> >> into the main tree, so having things like this figured out in concept
>> >> first will make that easier.
>> >>
>> >> >
>> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Could you help me
>> >> >> >> >>
>> >> >> >> >> The stub is only partially functional - one of the challenges is that
>> >> >> >> >> it needs device-specific knowledge, so you must create a stub for your
>> >> >> >> >> particular SoC. I did fiddle with integrating a bit more stuff into it
>> >> >> >> >> about a month ago, but it is always going to be SoC-specific.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > What do you mean by creating a stub for your particular SoC... I understood the STUB is just a EFI PE32+ that copy the real u-boot in memory and jump to it.
>> >> >> >> > My issue is that the u-boot-payload.efi is not an EFI PE32.. I tracked down the issue with the final objcopy step, which isn't using the --target argument.
>> >> >> >> > But even when doing that step manually, I couldn't start the resulting .efi
>> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> Have you tried using the app? It is efi-arm_app64_defconfig and is
>> >> >> >> >> pretty generic so should run on anything with an EFI interface.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > The EFI app works, in the sense I managed to get it running, but I couldn't get it to boot the kernel using an extlinux.conf file...
>> >> >> >> > Something with the FDT... But I don't expect this to work any better than just using grub EFI.
>> >> >> >>
>> >> >> >> Right.
>> >> >> >>
>> >> >> >> BTW there is a test for booting with extlinux (test_distro_arm_app_extlinux).
>> >> >>
>>
>> Regards,
>> SImon
>>
>> [2] https://patchwork.u-boot.org/project/uboot/list/?series=40