Bios upgrade from BMC

Patrick Williams patrick at stwcx.xyz
Wed Jan 22 08:50:58 AEDT 2020


Hi Vijay,

On Fri, Jan 17, 2020 at 07:04:51PM +0000, Vijay Khemka wrote:
> Hi,
> I am writing an application for Bios upgrade. Currently I have created a hook to our bmc updater which expects a systemd unit file to be run at the time of activating update. But I am thinking of adding some of this unit file functionality in updater itself and wanted to run by you all if it is common procedure used by every platform. Below are the process we use in our platform as a part of bios upgrade.
> 
> 
>   1.  Power off host server.

In the current code-update implementations, I don't believe that
powering off the Host is ever done automatically, but the expectation is
that the user has put the system into the right state first.  Then the
code-update implementation blocks any power-on until the activation is
complete [1].

I know the facebook/openbmc implementation automatically powers off, but
I think this is dangerous for general purpose commercial server.
Customers tend to get angry if a server powered off and they weren't
expecting it.

I will admit I don't know the Intel architecture well enough yet, but is
powering off the server prior to BIOS update actually required?  Is the
BIOS NOR chip always mapped into a physical address and used, or is the
BIOS at some point loaded and resident?  Are there stable points where
it is safe to perform an update?  Can we monitor POST code to know when
the BIOS is completed?

>   2.  Set ME/NM (Management engine or Node manager in x86) to recovery mode

Is this specific to the BIOS update path or is this something we should
do whenever the Host is powered off?  In either case I guess you can
make it a dependency on the systemd unit file, but it seems like it
would be nice if it were able to be generically applied to all power
on/off paths.

>   3.  Flip GPIO to access SPI flash used by host.
>   4.  Bind spi driver to access flash

This is another thing that seems like we could do generically on all
power on / power off paths?  Any time the host isn't running we can hit
the GPIO to put ownership at the BMC.  Is there any disadvantage to
that?

Is the GPIO something unique to Facebook's machines or do most other
Intel machines have the same requirements?

>   5.  Flashcp image to device.

I don't think `flashcp` is used today, or at least not in my
recollection of the previous Witherspoon implementation.  Is there any
advantage to it over `dd` to the raw mtdblock device?

>   6.  Unbind spi driver
>   7.  Flip GPIO back for host to access SPI flash
>   8.  Set ME/NM to operational mode
>   9.  Power on server.

Doesn't seem like "power on" should be a side-effect of a BIOS update.
Is this intended to be "go back to the previous power state"?

> I can have some flexibility in this sequence based on each platform configuration. Looking forward to your suggestions.
> 
> Regards
> -Vijay

[1] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200121/735550d9/attachment-0001.sig>


More information about the openbmc mailing list