Add ELF/flat binary loading fastboot commands

[fxsheep]

trafficstars

[stephan-gh]

Thanks, this looks fairly simple! What use cases do you have in mind for this?

[fxsheep]

For loading various kinds of images, of course (xD)!

lk2nd has suffered from stock bootloader's inconvenience, that is, have to be packed into Android's bootimg format, faking itself as a kernel with DTB and has almost zero control of load addresses. As a Secondary little kernel (lk) bootloader , one of its purpose is to extend stock bl's functionality, so I hope it could give user more convenience on booting other images. It can be used to boot another aarch32 AppSBL in mbn format, specifically, the Qualcomm UEFI firmware, for example, or u-boot, or even bare metal programming practices - all without ugly abootimg container and with full control of load addresses. It's still for development purposes only (for now), since it's not accessible without fastboot. I'm thinking about integrating it into fastboot boot or maybe virtual partitions, but neither seems possible to do cleanly. It can be more complex actually, I haven't messed with switching to AArch64 and ELF64 yet, so it's still capable of booting AArch32 images only.

[stephan-gh]

It can be more complex actually, I haven't messed with switching to AArch64 and ELF64 yet, so it's still capable of booting AArch32 images only.

Right, I think this limits the usefulness of it at the moment, because U-Boot is usually 64-bit and many other things are as well. In general it shouldn't be that hard to add, the main thing that is necessary is calling scm_elexec_call() instead of jumping directly to the address.

This means however, that for the raw image type you would need even more complexity in the commands to select ARM32 vs ARM64. The entry address, ARM32 vs ARM64 is all information that is encoded in the ELF image, so I'm inclined to say that we should only consider supporting ELF additionally but not the raw type images.

It seems a bit complicated (and error prone) to use at the moment. Having just:

fastboot stage my.elf
fastboot oem boot-elf

would be already much simpler I think. What do you think?

[fxsheep]

and ELF64 yet https://github.com/msm8916-mainline/lk2nd/pull/128/commits/40b51b2ca7bf274c76615a539ff60c452022887f#diff-98e604322de9eb517fa4bbf8c15445115f362f7d1e996a33a5e616297e21a4fdR15 The ELF library from LK is designed to load (and boot) images that matches the current LK's architecture only (using compile-time macros), in our case, AArch32 ELF32 images. Thus it cannot even parse ELF64. To fix that we need to hack up the library which seems to be discouraged and indeed more complex.

[stephan-gh]

The ELF library from LK is designed to load (and boot) images that matches the current LK's architecture only (using compile-time macros), in our case, AArch32 ELF32 images. Thus it cannot even parse ELF64. To fix that we need to hack up the library which seems to be discouraged and indeed more complex.

Hmm okay that is unfortunate. :(
I think it's fine to "hack up the library" since we're extremely far away from upstream LK anyway. But I understand that it's quite complex so feel free to leave that up to future work.

Nevertheless I would still say we should only support ELF, not the raw type images.