Future features of phosphor-ipmi-flash

[Lei YU]

On Wed, Jul 3, 2019 at 11:06 AM Patrick Venture <venture at google.com> wrote:
>
> Uploading the BIOs via phosphor-ipmi-flash is available for review,
> but it's not tied into another daemon.  One must provide a
> verification service, and an update service.
>
> I'd like to provide the option to leverage phosphor-bmc-code-mgmt.  It
> looks like in this codebase there is a notion of a signed image, but
> the signature is attached.  It also looks like, there's some version
> information that's meant to parsable and involved.  I haven't had a
> chance to play with it.
>
> With phosphor-ipmi-flash the hash file portion is optional.  Because
> phosphor-ipmi-flash doesn't define anything beyond the sequence of
> calls, one could use burn_my_bmc and send the hash down separately and
> then the verification target could trigger something that concatenates
> and triggers the bmc code mgmt signature check.
>
> It should be somewhat straightforward to tie the two codebases
> together (as an optional usage).
>
> If someone has experience with programming against
> phosphor-bmc-code-mgmt and wants to help with this or at least point
> me at what I need to know, I'd be more than happy.
>
> From reading the docs with the dbus interface definitions, I think I
> have the general idea -- drop the file into the place it expects the
> file (a configuration option) and then call the dbus methods.

Exactly, the whole process of BMC code update is:
1. Put a tarball in /tmp/images/ (via REST API, TFTP, or scp)
2. An object will be generated on DBus to represent the image;
3. Invoke a DBus call to set RequestedActivation property to "Active"
4. Reboot.

Be noted that the tarball consists of following files:

 image-u-boot
 image-kernel
 image-rofs
 image-rwfs
 MANIFEST
 publickey
 image-u-boot.sig
 image-kernel.sig
 image-rofs.sig
 image-rwfs.sig
 MANIFEST.sig
 publickey.sig