Lines Matching full:update
1 # Code Update Design
12 1. Current code update flow is complex as it involves 3 different daemons -
13 Image Manager, Image Updater and Update Service.
14 2. Update invocation flow has no explicit interface but rather depends upon the
25 - [Code Update Design](https://github.com/openbmc/docs/tree/master/architecture/code-update)
29 1. Able to start an update, given a firmware image and update settings.
31 - Update settings shall be able to specify when to apply the image, for example
34 2. Able to retrieve the update progress and status.
38 a firmware update.
39 5. Update request shall respond back immediately, so client can query the status
40 while update is in progress.
42 7. Able to support update for different type of hardware components such as
45 9. Able to update multiple hardware components of same type running different
49 10. Able to update multiple components in parallel.
51 update while the code update is in flight.
66 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at /xyz/openbmc_project/Sof…
71 CL ->> BMCW: HTTP POST: /redfish/v1/UpdateService/update <br> (Image, settings, RedfishTargetURIArr…
82 CU ->> CU: << Delegate Update for asynchronous processing >>
90 BMCW --) BMCW: Process notifications<br> and update Task attributes
94 and << Asynchronous Update in Progress >>
108 note over CU: Start Update
112 note over CU: Finish Update
119 CU ->> CU: Update functional association to System Inventory Item
120 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at ObjectPath
130 above flow) handling its update process and would need to implement the
133 - Since, there would be single daemon handling the update (as compared to
139 The DBus Interface for code update will consist of following -
143 …Update](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/65738) …
147 …erface.yaml) | Existing | Signifies barrier for state transitions while update is in progress |
150 Introduction of xyz.openbmc_project.Software.Update interface streamlines the
151 update invocation flow and hence addresses the [Issue# 2](#problem-description)
183 xyz.openbmc_project.Software.Update.StartUpdate return value will propagate any
185 Any asynchronous errors which happen during the update process will be notified
187 update. Also, a phosphor-logging event will be created and sent back to client
204 [Firmware Update Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP026…
207 update images for non-PLDM devices as well. For such devices, the CodeUpdater
263 update, the client may target the logical firmware device which further knows
264 how to update the corresponding child components for supplied component images.
265 The user can also update the specific component by providing the image package
270 ### Update multiple devices of same type
275 returned from xyz.openbmc_project.Software.Update.StartUpdate.
285 components with common features, for example, PLDMd may handle update for
291 BMCWeb will trigger xyz.openbmc_project.Software.Update.StartUpdate on
294 [Update multiple devices of same type](#update-multiple-devices-of-same-type).
301 path for a version update which will help to block any interruptions from
313 case scenario when device is busy, for example, due to update in progress.
322 various hardware update services within the system and start them based on
323 update request. These on-demand services update the hardware and interfaces
331 - Under normal operating conditions (no update in flight), only Software Manager
340 to start each update daemon at system startup to get the running version.
346 model where Update interface can have get methods for status and progress (for
366 current proposal, the only change will be in update invocation flow.
372 stacks. As all the code update daemons gets moved to the new flow, Servers would
389 - VR Update
390 - CPLD Update
395 update invocation -
402 | [pldm](https://github.com/openbmc/pldm/tree/master/fw-update) | Jagpal Singh Gi…