architecture/code-update/firmware-update-over-redfish.md

5 Created: 2019-02-11
14 The goal of this design document is to lay out the required changes of moving
30 - Redfish has a single upload and update API. OpenBMC has a concept of uploading
32 - Redfish does not support multiple firmware images being associated with the
36   - OpenBMC has the concept of a priority that allows a user to chose an image
40 - Redfish does not support deleting a firmware image (this happens by default
42 - Redfish does support the ability to update multiple targets with the same
44 - Redfish has support via a SimpleUpdate action which allows the user to pass in
47 - Redfish has the ability to schedule when a firmware update is applied
55 and this design will be proposing enhancements to that as a base.
66 - Support FirmwareInventory definition for BMC and BIOS under UpdateService
67   - Support FirmwareVersion under Managers/BMC
68   - Support BiosVersion under Systems/system
69 - Support firmware update for all supported targets (BMC, BIOS) using existing
71   - Note that after further discussion with the DMTF, the existing UpdateService
76   - Must provide status to user on their image during an update
77 - Support a subset of ApplyTime (Immediate, OnReset)
78 - Support a TFTP based SimpleUpdate
79   - This must be configurable (enable/disable) via compile option within bmcweb
84 will be required post 2.7 release. An update to this design document will be
86 nothing in the base design would inhibit the ability to implement these later.
88 - Support new concept defined in [PR 3420][12] to be able to support multiple
90 - Support new UpdateService firmware update implementation defined in [Issue
92 - Support firmware update for other targets (power supplies, voltage regulators,
94 - Support to update multiple targets with the same firmware image at once
95 - Support scheduling of when update occurs (Maintenance windows)
96 - Support remaining TransferProtocolTypes in UpdateService (CIFS, FTP, SFTP,
98   - TODO: Any update mechanism that doesn't have transport security on its own,
101 - Support the Task schema to provide progress to user during upload and
104 ## Proposed Design
114   UpdateService/HttpPushUriOptions->HttpPushUriApplyTime object
119 This will cause the following on the back-end:
121 - Receive the image
122 - Copy it internally to the required location in the filesystem (/tmp/images)
123 - Wait for the InterfacesAdded signal from /xyz/openbmc_project/software
124 - Activate the new image
125 - If ApplyTime is Immediate, reboot the BMC or Host
126 - If ApplyTime is OnReset, do nothing (user will need to initiate host or bmc
138 the full status of an image during upload and activate. Using the Status object
144 NotReady   -> Disabled
145 Invalid    -> Disabled
146 Ready      -> Disabled
147 Activating -> Updating
148 Active     -> Enabled
149 Failed     -> Disabled
158 still exists in flash chip 0 and could be re-activated by the user.
189   UpdateService/HttpPushUriOptions->HttpPushUriApplyTime object
228 This will be using the existing D-Bus API's for firmware update internally so
232 implemented different implementations. To be clear, this design will be using
233 the D-Bus API's behind the [Software Version Management][8] implementation.
239 D-Bus API's mocked to ensure proper code coverage.
243 …https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md#steps-to-update
249 …https://github.com/dell/iDRAC-Redfish-Scripting/blob/master/Redfish%20Python/DeviceFirmwareDellUpd…
251   https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/update_service.hpp
253 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/…
254 [9]: https://github.com/openbmc/openbmc-test-automation
259 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/…