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

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