[PATCH v3 4/8] mach-snapdragon: implement capsule update support

[Sumit Garg]

On Wed, 5 Jun 2024 at 18:03, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>
> Hi Sumit,
> >> +/**
> >> + * qcom_configure_capsule_updates() - Configure the DFU string for capsule updates
> >> + *
> >> + * U-Boot is flashed to the boot partition on Qualcomm boards. In most cases there
> >> + * are two boot partitions, boot_a and boot_b. As we don't currently support doing
> >> + * full A/B updates, we only support updating the currently active boot partition.
> >> + *
> >> + * So we need to find the current slot suffix and the associated boot partition.
> >> + * We do this by looking for the boot partition that has the 'active' flag set
> >> + * in the GPT partition vendor attribute bits.
> >> + */
> >> +void qcom_configure_capsule_updates(void)
> >> +{
> >> +       struct blk_desc *desc;
> >> +       int ret = 0, partnum = -1, devnum;
> >> +       static char dfu_string[32] = { 0 };
> >> +       char name[32]; /* GPT partition name */
> >> +       char *partname = "boot";
> >> +       struct udevice *dev = NULL;
> >> +
> >> +       /*
> >> +        * There is currently no good way to check how U-Boot is booting, but we have
> >> +        * a few hueristics, like here checking if our DTB has a kaslr-seed specified
> >> +        * will tell us if we were chainloaded by another bootloader.
> >> +        * FIXME: we should do this check once and use some proper API to expose the data.
> >
> > If U-Boot is built with LINUX_KERNEL_IMAGE_HEADER enabled then we
> > should know that U-Boot is built as a replacement of Linux kernel and
> > hence chainloaded. Isn't that what you need here?
>
> Not necessarily, you can build with LINUX_KERNEL_IMAGE_HEADER and then
> pack U-Boot into XBL or flash it to hyp and it will still run (the
> kernel header is specifically written to behave like a nop slide). So we
> can't rely on this.
> >

Yeah you can build it in whatever form downstream and run as a NOP too
but I don't think we support any such combination in upstream U-Boot,
right? We should let people know that LINUX_KERNEL_IMAGE_HEADER should
only be enabled if the U-Boot image is flashed into the boot partition
as a replacement for Linux kernel image. BTW, isn't that the real
meaning for that config option? IMHO, the current DT check you have
implemented is implicit and I am unsure if we can reliably depend upon
it.

-Sumit