Re: [PATCH] board: dragonboard410c: Load U-Boot directly without LK

[Stephan Gerhold <stephan@gerhold.net>]

On Sat, Jul 10, 2021 at 10:07:28PM +0300, Ramon Fried wrote:
> On Wed, Jul 7, 2021 at 12:06 PM Stephan Gerhold <stephan@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.dev@gmail.com>
> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> > ---
> >
> > Related RFC with even more detailed explanations:
> > https://lore.kernel.org/u-boot/YN2F1c926HFF+JA2@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-stephan@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