docs/designs/firmware-update-via-blobs.md

1 # In-Band Update of BMC Firmware (and others) using OEM IPMI Blob Transport
5 Created: 2018-10-18
15 BMC hardware provides at a minimum some interface for sending and receiving IPMI
19 update mechanism that can be done in-band between the host and the BMC.
21 In-band here refers to a communications channel that is directly connected
25 1.  IPMI over LPC
26 1.  IPMI over i2c
27 1.  LPC Memory-Mapped Region
32 Please read the IPMI BLOB protocol design as primer
33 [here](https://github.com/openbmc/phosphor-ipmi-blobs/blob/master/README.md).
39 - Any update mechanism must provide support for UBI tarballs and legacy (static
43 - Any update mechanism must allow for triggering an image verification step
46 - Any update mechanism must allow implementing the data staging via different
47   in-band mechanisms.
49 - Any update mechanism must provide a handshake or equivalent protocol for
54 - Any update mechanism must attempt to maintain security, insomuch as not
67 [phosphor-ipmi-flash design](https://github.com/openbmc/phosphor-ipmi-flash/blob/master/README.md)
68 through a BLOB handler. This is meant to supplant `phosphor-ipmi-flash`'s
83 identify the mechanism selected by the client-side. The stat command will return
89 | ---------------- | --------------- |
106 | ------------- | ------------------------------- |
110 attempts to send a firmware image down over IPMI BlockTransfer, it won't allow
128 | --------------- | ------------------------ |
146 | --------------- | ------------------------ |
171 | ---------------- | ------------------------- |
176 Similarly to the OEM IPMI Flash protocol, the flash image will be staged in a
177 compile-time configured location.
278     bt = (1 << 8),   /* Expect to send contents over IPMI BlockTransfer. */
309 ##### If BT
338 will happen at present. It will return a no-op success.
341 at present. It will return a no-op success.
345 doing this, if the transport mechanism is not IPMI BT, it'll shut down the
390     uint32_t size; /* 0 - it's set to zero when there's no session */
397 If called pre-commit, it'll return the following information:
408 If it's called and the data transport mechanism is P2A, it'll return a 32-bit
424 If called post-commit on the verify file session, it'll return:
444 If called post-commit on the update file session, it'll return:
470 configuration data to the BMC for the in-band update. Currently that is only
486 There is currently another implementation in-use by Google that leverages the
501 the entire process has individual unit-tests that verify flags are checked, as
522 [Secure Flash Update Mechanism](https://github.com/openbmc/phosphor-ipmi-flash/blob/master/README.m…