Lines Matching +full:multi +full:- +full:functional

10 [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt)
12 1. Current code update flow is complex as it involves 3 different daemons -
23 - [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt)
24 - [Software DBus Interface](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xy…
25 - [Code Update Design](https://github.com/openbmc/docs/tree/master/architecture/code-update)
31 - Update settings shall be able to specify when to apply the image, for example
32 immediately or on device reset or on-demand.
66 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at /xyz/openbmc_project/Sof…
67 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Version<br> at /xyz/openbmc_project/So…
68 CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.Activation<br> at /xyz/openbmc_project/…
69 CU ->> CU: Create functional association <br> from Version to Inventory Item
71 CL ->> BMCW: HTTP POST: /redfish/v1/UpdateService/update <br> (Image, settings, RedfishTargetURIArr…
76 BMCW ->> CU: StartUpdate(Image, ApplyTime)
80 …CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.Activation<br> at ObjectPath with Stat…
81 CU -->> BMCW: {ObjectPath, Success}
82 CU ->> CU: << Delegate Update for asynchronous processing >>
85 …BMCW ->> BMCW: Create Matcher<br>(PropertiesChanged,<br> xyz.openbmc_project.Software.Activation,<…
86 …BMCW ->> BMCW: Create Matcher<br>(PropertiesChanged,<br> xyz.openbmc_project.Software.ActivationPr…
87 BMCW ->> BMCW: Create Task<br> to handle matcher notifications
88 BMCW -->> CL: <TaskNum>
90 BMCW --) BMCW: Process notifications<br> and update Task attributes
91 CL ->> BMCW: /redfish/v1/TaskMonitor/<TaskNum>
92 BMCW -->>CL: TaskStatus
97 CU ->> CU: Activation.Status = Invalid
98 CU --) BMCW: Notify Activation.Status change
100 CU ->> CU: Activation.Status = Ready
101 CU --) BMCW: Notify Activation.Status change
103 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Version<br> at ObjectPath
104 … CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.ActivationProgress<br> at ObjectPath
105 …CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.ActivationBlocksTransition<br> at Obj…
106 CU ->> CU: Activation.Status = Activating
107 CU --) BMCW: Notify Activation.Status change
110 CU --) BMCW: Notify ActivationProgress.Progress change
113 CU ->> CU: Activation.Status = Active
114 CU --) BMCW: Notify Activation.Status change
115 CU ->> CU: Delete Interface<br> xyz.openbmc_project.Software.ActivationBlocksTransition
116 CU ->> CU: Delete Interface<br> xyz.openbmc_project.Software.ActivationProgress
119 CU ->> CU: Update functional association to System Inventory Item
120 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at ObjectPath
129 - Each upgradable hardware type may have a separate daemon (\<deviceX\> as per
133 - Since, there would be single daemon handling the update (as compared to
135 [Issue# 1](#problem-description) and [Requirement# 4](#requirements).
137 ### Proposed D-Bus Interface
139 The DBus Interface for code update will consist of following -
142--------------------------------------------------------------------------------------------------…
143 | [xyz.openbmc_project.Software.Update](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfac…
144 | [xyz.openbmc_project.Software.Version](https://github.com/openbmc/phosphor-dbus-interfaces/blob/m…
145 | [xyz.openbmc_project.Software.Activation](https://github.com/openbmc/phosphor-dbus-interfaces/blo…
146 | [xyz.openbmc_project.Software.ActivationProgress](https://github.com/openbmc/phosphor-dbus-interf…
147 ….Software.ActivationBlocksTransition](https://github.com/openbmc/phosphor-dbus-interfaces/blob/mas…
148 | [xyz.openbmc_project.Software.RedundancyPriority](https://github.com/openbmc/phosphor-dbus-interf…
151 update invocation flow and hence addresses the [Issue# 2](#problem-description)
157 xyz.openbmc_project.Software.Version represents the current functional or
166 flash-banks and xyz.openbmc_project.Software.RedundancyPriority interface
187 update. Also, a phosphor-logging event will be created and sent back to client
206 and user-defined descriptors. This format can be utilized to package firmware
207 update images for non-PLDM devices as well. For such devices, the CodeUpdater
209 descriptors, which can include but are not limited to the following -
212---------------------: | :-------------: | :------------------------------------------------------…
213 … [IANA Enterprise Id](https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers) of …
214 …XX\>) specified by hardware vendor in [phosphor-dbus-interfaces](https://github.com/openbmc/phosph…
218 The entity manager configuration can provide firmware-related information as
220 modeling device access details. These D-Bus objects can then be consumed by the
224 [refer](https://gerrit.openbmc.org/c/openbmc/entity-manager/+/75947)
247 - `Name`: The name of the firmware entity instance.
248 - `Type`: This field is used by the CodeUpdater service to determine which
250 - `VendorIANA`: This field maps to the `IANA Enterprise ID` descriptor in PLDM
252 - `CompatibleHardware`: This field maps to the `ASCII Model` descriptor in PLDM
255 ### Multi part Images
257 A multi part image has multiple component images as part of one image package.
258 PLDM image is one such example of multi part image format. Sometimes, for multi
272 - For same type devices, extend the Dbus path to specify device instance, for
281 - Different type hardware components:
289 - Similar type hardware component:
292 different D-Bus paths pertaining to each hardware instance. For more details
293 on D-Bus paths refer to
294 [Update multiple devices of same type](#update-multiple-devices-of-same-type).
300 `ActivationBlocksTransitions` interface will be created on the specific D-Bus
323 update request. These on-demand services update the hardware and interfaces
328 - Most of the DBus interfaces gets implemented by Software Manager and vendors
331 - Under normal operating conditions (no update in flight), only Software Manager
336 - Imposes the need of a common image format as Software Manager needs to parse
338 - Limitation in the design, as there is a need to get the current running
351 - Server doesn't have to maintain a Dbus matcher
353 - Easier implementation in Server as no asynchronous handlers would be required.
357 - Server would still need maintain some info so it can map client's task status
360 - Aforementioned [issue](https://github.com/openbmc/bmcweb/issues/202) is more
363 - Currently, activation and progress interfaces are being used in
373 be changed to only support new API stack. No user-api impact as design adheres
389 - VR Update
390 - CPLD Update
395 update invocation -
398 | :------------------------------------------------------------------------------ | :--------------…
399 | [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt) | Jagpal Singh Gi…
401 | [phosphor-host-ipmid](https://github.com/openbmc/phosphor-host-ipmid) | Jagpal Singh Gi…
402 | [pldm](https://github.com/openbmc/pldm/tree/master/fw-update) | Jagpal Singh Gi…
403 | [openpower-pnor-code-mgmt](https://github.com/openbmc/openpower-pnor-code-mgmt) | Adriana Kobylak…
404 | [openbmc-test-automation](https://github.com/openbmc/openbmc-test-automation) | Adriana Kobylak…
407 [phosphor-psu-code-mgmt](https://github.com/openbmc/phosphor-psu-code-mgmt) code
414 All the functional testing of the reference implementation will be performed
420 be covered using openbmc-test-automation.