Hi Stephan,
Stephan Gerhold stephan@gerhold.net writes:
[...]
+This approach ensures that U-Boot is booted in EL2 and it is possible +to run virtualization software (like Xen or KVM) on the board. You +must understand that this approach breaks Qualcomm's boot chain. You +will not be able to call all subsequent loaders, so you will not be +able to use fastboot for example. Use this approach only if you want +to experiment with virtualization on SA8155P-ADP.
+We need to create ELF file from the u-boot binary. We can't use +existing U-Boot ELF, because it does not include appended DTB +file. Easiest way to do this is to use ``create_elf.py`` from the +following repository: `qtestsign(lorc) +https://urldefense.com/v3/__https://github.com/lorc/qtestsign/tree/create_elf__;!!GF_29dbcQIUBPA!3iokDDZXQGZNS3GK2oGM-SU5Trj8ZSmx5FY-uvFKY0LDzDLh8LSVkBNS5r9QX-LGFKObs1tNmLdELls6iGQPZ3Aq$ [github[.]com]`_: ::
- $ python ../qtestsign/create_elf.py u-boot.bin 0x85710000 u-boot.mbn
Have you tried using CONFIG_REMAKE_ELF in U-Boot? That should effectively do the same (build a new ELF based on u-boot.bin with the appended device tree). The Qualcomm DragonBoard 410c port is using that option to solve the same problem.
I didn't knew that there is a such option. Looks like this is exactly what I need, thank you. I'll include this in the V2.
But I'm glad to see that the ELF abstractions in qtestsign worked well for your purpose. :-)
Well, I was surprised that pyelf can parse ELF files but can't modify them. So your tool come in handy. I was going to make a PR that adds this create_elf.py script, but looks like we don't need it.