Future features of phosphor-ipmi-flash

[Neeraj Ladkani]

This is great. In this case, we should be able to make use of this design for all BMC managed components ( FPGA, CPLD and PSU FW) by providing verification service, and an update service. Basically TFTP the image and then call the dbus methods

How do we specify if we want to update only kernel or rofs or rwfs? 

Neeraj

-----Original Message-----
From: openbmc <openbmc-bounces+neladk=microsoft.com at lists.ozlabs.org> On Behalf Of Lei YU
Sent: Tuesday, July 2, 2019 8:18 PM
To: Patrick Venture <venture at google.com>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Adriana Kobylak <anoo at us.ibm.com>
Subject: Re: Future features of phosphor-ipmi-flash

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