Re: [PATCHv2 4/5] fwu: DeveloperBox: add support for FWU

Jassi Brar
2022-10-04T02:00:54Z

On Mon, Oct 3, 2022 at 8:06 PM AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> On Mon, Oct 03, 2022 at 04:51:32PM +0300, Ilias Apalodimas wrote:
> > Hi Jassi,
> >
> > On Mon, 3 Oct 2022 at 16:40, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > >
> > > On Mon, Oct 3, 2022 at 6:04 AM AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > >
> > > > > diff --git a/board/socionext/developerbox/developerbox.c b/board/socionext/developerbox/developerbox.c
> > > > > index f5a5fe0121..a0db26eaf3 100644
> > > > > --- a/board/socionext/developerbox/developerbox.c
> > > > > +++ b/board/socionext/developerbox/developerbox.c
> > > > > @@ -20,6 +20,13 @@
> > > > >
> > > > > #if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
> > > > > struct efi_fw_image fw_images[] = {
> > > > > +#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
> > > > > + {
> > > > > + .image_type_id = DEVELOPERBOX_FIP_IMAGE_GUID,
> > > > > + .fw_name = u"DEVELOPERBOX-FIP",
> > > > > + .image_index = 1,
> > > > > + },
> > > > > +#else
> > > >
> > > > From curiosity, why do you want to use different capsule formats
> > > > for multi-bank update and normal case?
> > > >
> > > normal/legacy layout has one image for each component - uboot, tfa and
> > > optee, whereas the new layout contains everything in one fip image.
>
> Yes, that is exactly what I understand here.
>
> > > So I thought it would be better to make the image_index consistent by
> > > making the fip's as 1.
> >
> > FWIW this does make a lot of sense. Since the SCP firmware is not
> > included in the capsule and that SCP firmware is needed to transition
> > from old -> new layout, I think we are better off having those in
> > different GUIDs. On top of that those GUIDs can be used in LVFS if we
> > ever decide to upload firmwares there.
> >
> > Not having discrete GUIDs means there's a chance to brick the board on
> > old -> new update, unless the SCP is explicitly updated.
>
> SCP? I don't care.
> My question is why you use a single capsule (FIP) in A/B update while you use
> three separate capsule files in normal case.
>
We think it is cleaner to not tie up boot binaries at fixed offsets in
storage, so all CA53 boot assets are now in one parseable FIP image.
Secondly, and personally, I think there is no real usecase of more
than one image per bank - that will be too fragile and complicated to
manage.

cheers.