Packaging and deploying multiple firmware image types in one

[Alexander A. Filippov]

On Tue, Nov 12, 2019 at 04:54:22PM -0600, Adriana Kobylak wrote:
> On 2019-11-12 01:49, Alexander A. Filippov wrote:
> > On Mon, Nov 11, 2019 at 01:28:11PM -0600, Adriana Kobylak wrote:
> > 
> > We use the system bundle of BMC + Host firmware on our VESNIN hardware.
> 
> How are you currently building the bundled image, do you include the Host
> firmware in the BMC rootfs, or do you have separate image files (bmc fw
> file, host fw file) in a single tarball?

We put separate image files in a single tarball.

> 
> > There are some things which cause discomfort a little bit:
> > - The uploaded system bundle isn't shown in the WebUI.
> > - The system bundle has only one version field which is common for BMC
> > and Host
> >   firmwares.
> 
> Do you think the ExtendedVersion d-bus property could help in this case? For
> example adding to the manifest "extended_version=host-v1.2."

I think, it is right only if the system bundle will be processed by its own
service, which creates corresponding objects for each part of the bundle with
their own hash, version's data and purpose.

E.g.: as you've proposed below with separate tarballs in one common tarball.

> 
> > - After rebooting BMC, which is required to complete update the BMC
> > firmware
> >   the system bundle turns to two separated instances in D-Bus which has
> > its own
> >   real versions.
> 
> Yeah, the purpose is not currently preserved across reboots. I have a change
> here for that:
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-bmc-code-mgmt/+/27045
> 

We use static filesystem layout on our VESNIN hardware. 
So, the version of active BMC is read from /etc/os-release and always has the
BMC purpose. 
The same way with the host firmware: it is read directly from the flash, which
has a special partition with version's data and always has the Host purpose.

> > 
> > Thus, I thought about putting the separate manifests for each part of
> > the
> > bundle.
> 
> If you go the route of adding a second manifest, would you have them in a
> separate tarball (bmc image + manifest) and (host image + manifest) then put
> those tarballs inside a tarball? since the manifest file name would be the
> same.
>

Yeah, it's possible.
But when I researched that, I had found that the phosphor-image-updater and the
openpower-update-manager both already have support for the system bundle. I
decided, we shouldn't create any other implementation, but follow the upstream's
way. So, it has led to the state I described earlier.

> > 
> > > 
> > > ---
> > > [1] https://lists.ozlabs.org/pipermail/openbmc/2019-June/016573.html
> > > [2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/Version.interface.yaml
> > > [3] https://github.com/openbmc/meta-openpower/blob/master/recipes-phosphor/flash/host-fw_git.bb
> > > [4] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/ExtendedVersion.interface.yaml