On Sat, Jul 10, 2021 at 10:07:28PM +0300, Ramon Fried wrote: > On Wed, Jul 7, 2021 at 12:06 PM Stephan Gerhold <step...@gerhold.net> wrote: > > > > At the moment the U-Boot port for the DragonBoard 410c is designed > > to be loaded as an Android boot image after Qualcomm's Little Kernel (LK) > > bootloader. This is simple to set up but LK is redundant in this case, > > since everything done by LK can be also done directly by U-Boot. > > > > Dropping LK entirely has at least the following advantages: > > - Easier installation/board code (no need for Android boot images) > > - (Slightly) faster boot > > - Boot directly in 64-bit without a round trip to 32-bit for LK > > > > So far this was not possible yet because of unsolved problems: > > > > 1. Signing tool: The firmware expects a "signed" ELF image with extra > > (Qualcomm-specific) ELF headers, usually used for secure boot. > > The DragonBoard 410c does not have secure boot by default but the > > extra ELF headers are still required. > > > > 2. PSCI bug: There seems to be a bug in the PSCI implementation > > (part of the TrustZone/tz firmware) that causes all other CPU cores > > to be started in 32-bit mode if LK is missing in the boot chain. > > This causes Linux to hang early during boot. > > > > There is a solution for both problems now: > > > > 1. qtestsign (https://github.com/msm8916-mainline/qtestsign) > > can be used as a "signing" tool for U-Boot and other firmware. > > > > 2. A workaround for the "PSCI bug" is to execute the TZ syscall when > > entering U-Boot. That way PSCI is made aware of the 64-bit switch > > and starts all other CPU cores in 64-bit mode as well. > > > > Simplify the dragonboard410c board by removing all the extra code that > > is only used to build an Android boot image that can be loaded by LK. > > This allows dropping the custom linker script, special image magic, > > as well as most of the special build/installation instructions. > > > > CONFIG_REMAKE_ELF is used to build a new ELF image that has both U-Boot > > and the appended DTB combined. The resulting u-boot.elf can then be > > passed to the "signing" tool (e.g. qtestsign). > > > > The PSCI workaround is placed in the "boot0" hook that is enabled > > with CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK. The extra check for EL1 allows > > compatibility with custom firmware that enters U-Boot in EL2 or EL3, > > e.g. qhypstub (https://github.com/msm8916-mainline/qhypstub). > > > > As a first step these changes apply only to DragonBoard410c. > > Similar changes could likely also work for the DragonBoard 820c. > > > > Note that removing LK wouldn't be possible that easily without a lot of > > work already done three years ago by Ramon Fried. A lot of missing > > initialization, pinctrl etc was already added back then even though > > it was not strictly needed yet. > > > > Cc: Ramon Fried <rfried....@gmail.com> > > Signed-off-by: Stephan Gerhold <step...@gerhold.net> > > --- > > > > Related RFC with even more detailed explanations: > > https://lore.kernel.org/u-boot/yn2f1c926hff+...@gerhold.net/ > > > > In my tests both U-Boot and Linux are fully functional with this patch. > > However, I would appreciate further testing, since my testing does > > likely not represent a typical usage scenario for the DragonBoard 410c. > > > > When testing, please pick the following pending patch additionally: > > https://lore.kernel.org/u-boot/20210705121847.48432-1-step...@gerhold.net/ > > on top of u-boot/master. > > > > --- > > [...] > > Thanks Stephan, it looks very good. > I started testing it, it builds correctly and I flashed and everything > seems to work. > I do have a problem with my TFTP setup, so I didn't boot Linux yet, > but I will get to it, if it will boot successfully we can merge this > one. > > U-boot doesn't know how to boot qcom android kernel partitions, I'm > not sure this is something I even want to start supporting in U-boot.
It's probably not too hard to support this (I actually boot the same Android boot images on both LK and U-Boot via "fastboot boot", because this is the workflow I'm used to). But I agree that anything else (i.e. reading the images from partitions) is not worth the effort. > Nico, do you think you can change the format of the BOOT partition to > host a u-boot FIT image ? > Is a "boot" partition with a binary image even useful at all? I would expect that all typical Linux distributions except Android have a separate boot partition with a file system, so setting something up that works with the generic distro configuration (doc/README.distro) would be probably best. This would also avoid having to re-build the image just to change the cmdline for example. Stephan