Lines Matching +full:redfish +full:- +full:mapping
1 # Firmware update over Redfish
5 Created: 2019-02-11
9 OpenBMC is moving to [Redfish][1] as its standard for out of band management.
10 Redfish has its own API's and methods for updating firmware on a system and
15 OpenBMC's existing firmware update implementation over to Redfish.
23 The Redfish schema for firmware update can be found in the [DMTF schemas][3].
28 Some differences between the Redfish API and OpenBMC's existing API:
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
51 A lot of companies that are implementing Redfish have chosen to create OEM
54 Redfish firmware update within OpenBMC has already started within [bmcweb][7]
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
70 Redfish API's (/redfish/v1/UpdateService)
71 - Note that after further discussion with the DMTF, the existing UpdateService
74 supported within the Redfish specification so the OpenBMC 2.7 release will
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
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
112 HttpPushUri = GET https://${bmc}/redfish/v1/UpdateService
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
140 provide status of inventory items back to the user. Here is the mapping of
141 [phosphor activation states][13] to [Redfish Status States][14].
144 NotReady -> Disabled
145 Invalid -> Disabled
146 Ready -> Disabled
147 Activating -> Updating
148 Active -> Enabled
149 Failed -> Disabled
155 still be pseudo support for this using Redfish. The first image will be uploaded
158 still exists in flash chip 0 and could be re-activated by the user.
161 the Redfish Settings object to allow the user to select the image to activate
171 As noted above, Redfish supports a SimpleUpdate object under the UpdateService.
174 that is all that will be supported via Redfish on OpenBMC.
176 The Redfish API takes a parameter, ImageURI, which contains both the server
185 GET https://${bmc}/redfish/v1/UpdateService
189 UpdateService/HttpPushUriOptions->HttpPushUriApplyTime object
193 POST https://${bmc}/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate
218 Could simply create Redfish OEM api's that look like OpenBMC's current custom
220 any standard Redfish API's. Other vendors have done this but the Redfish DMTF is
228 This will be using the existing D-Bus API's for firmware update internally so
233 the D-Bus API's behind the [Software Version Management][8] implementation.
239 D-Bus API's mocked to ensure proper code coverage.
241 [1]: https://redfish.dmtf.org/
243 …https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md#steps-to-update
244 [3]: http://redfish.dmtf.org/schemas/v1/UpdateService.json
246 http://redfish.dmtf.org/schemas/v1/UpdateService.v1_4_0.json#/definitions/UpdateService
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
255 [10]: https://github.com/DMTF/Redfish/issues/3357
256 [11]: https://github.com/DMTF/Redfish/pull/3296
257 [12]: https://github.com/DMTF/Redfish/pull/3420
259 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/…
260 [14]: http://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/Status