On Sat, Sep 27, 2025 at 10:43 PM Simon Glass <sjg@chromium.org> wrote:
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
https://github.com/qualcomm/abl2esp it's a very simple ABL that tries to launch a /EFI/BOOT/BOOTAA64.EFI
build a PE32+ with another project or build system, so you can compare them?
I'm able to build and launch a grub EFI, or u-boot as an EFI app
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.
I'll check that
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