1# Code Update Design 2 3Author: Jagpal Singh Gill <paligill@gmail.com> 4 5Other contributors: 6 7- Deepak Kodihalli <deepak.kodihalli.83@gmail.com> @dkodihal 8- Tom Joseph <rushtotom@gmail.com> @tomjose 9 10Created: 4th August 2023 11 12Last Updated: Aug 29, 2025 13 14## Problem Description 15 16This section covers the limitations discovered with 17[phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt). 18 191. Current code update flow is complex as it involves 3 different daemons - 20 Image Manager, Image Updater and Update Service. 212. Update invocation flow has no explicit interface but rather depends upon the 22 discovery of a new file in /tmp/images by Image Manager. 233. Images POSTed via Redfish are downloaded by BMCWeb to /tmp/images which 24 requires write access to filesystem. This poses a security risk. 254. Current design doesn't support parallel upgrades for different firmware 26 ([Issue](https://github.com/openbmc/bmcweb/issues/257)). 27 28## Background and References 29 30- [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt) 31- [Software DBus Interface](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/Software) 32- [Code Update Design](https://github.com/openbmc/docs/tree/master/architecture/code-update) 33- [PLDM for Firmware Update Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf) 34- [Redfish Firmware Update White Paper](https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.2.pdf) 35 36## Requirements 37 381. Able to start an update, given a firmware image and update settings. 39 - Update settings shall be able to specify when to apply the image, for 40 example immediately or on device reset or on-demand. 41 422. Able to retrieve the update progress and status. 433. Able to produce an interface complaint with 44 [Redfish UpdateService](https://redfish.dmtf.org/schemas/v1/UpdateService.v1_11_3.json) 454. Unprivileged daemons with access to DBus should be able to accept and perform 46 a firmware update. 475. Update request shall respond back immediately, so client can query the status 48 while update is in progress. 496. All errors shall propagate back to the client. 507. Able to support update for different type of hardware components such as 51 CPLD, NIC, BIOS, BIC, PCIe switches, etc. 528. Design shall impose no restriction to choose any specific image format. 539. Able to update multiple hardware components of same type running different 54 firmware images, for example, two instances of CPLDx residing on the board, 55 one performing functionX and other performing functionY and hence running 56 different firmware images. 5710. Able to update multiple components in parallel. 5811. Able to restrict critical system actions, such as reboot for entity under 59 update while the code update is in flight. 6012. Able to update the components with a multi part image when no Targets are 61 specified. 6213. Able to order component updates to a device as defined in the multi part 63 image format. 64 65## Proposed Design 66 67### Proposed End to End Flow 68 69```mermaid 70sequenceDiagram; 71participant CL as Client 72participant BMCW as BMCWeb 73participant CU as <deviceX>CodeUpdater<br> ServiceName: xyz.openbmc_project.Software.<deviceX> 74 75% Bootstrap Action for CodeUpdater 76note over CU: Get device access info from<br> /xyz/openbmc_project/inventory/system/... path 77note over CU: Swid = <DeviceX>_<RandomId> 78CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at /xyz/openbmc_project/Software/<SwId> 79CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Version<br> at /xyz/openbmc_project/Software/<SwId> 80CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.Activation<br> at /xyz/openbmc_project/Software/<SwId> <br> with Status = Active 81CU ->> CU: Create functional association <br> from Version to Inventory Item 82 83CL ->> BMCW: HTTP POST: /redfish/v1/UpdateService/update <br> (Image, settings, RedfishTargetURIArray) 84 85loop For every RedfishTargetURI 86 note over BMCW: Map RedfishTargetURI /redfish/v1/UpdateService/FirmwareInventory/<SwId> to<br> Object path /xyz/openbmc_project/software/<SwId> 87 note over BMCW: Get serviceName corresponding to the object path <br>from mapper. 88 BMCW ->> CU: StartUpdate(Image, ApplyTime) 89 90 note over CU: Swid = <DeviceX>_<RandomId> 91 note over CU: ObjectPath = /xyz/openbmc_project/Software/<SwId> 92 CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.Activation<br> at ObjectPath with Status = NotReady 93 CU -->> BMCW: {ObjectPath, Success} 94 CU ->> CU: << Delegate Update for asynchronous processing >> 95 96 par BMCWeb Processing 97 BMCW ->> BMCW: Create Matcher<br>(PropertiesChanged,<br> xyz.openbmc_project.Software.Activation,<br> ObjectPath) 98 BMCW ->> BMCW: Create Matcher<br>(PropertiesChanged,<br> xyz.openbmc_project.Software.ActivationProgress,<br> ObjectPath) 99 BMCW ->> BMCW: Create Task<br> to handle matcher notifications 100 BMCW -->> CL: <TaskNum> 101 loop 102 BMCW --) BMCW: Process notifications<br> and update Task attributes 103 CL ->> BMCW: /redfish/v1/TaskMonitor/<TaskNum> 104 BMCW -->>CL: TaskStatus 105 end 106 and << Asynchronous Update in Progress >> 107 note over CU: Verify Image 108 break Image Verification FAILED 109 CU ->> CU: Activation.Status = Invalid 110 CU --) BMCW: Notify Activation.Status change 111 end 112 CU ->> CU: Activation.Status = Ready 113 CU --) BMCW: Notify Activation.Status change 114 115 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Version<br> at ObjectPath 116 CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.ActivationProgress<br> at ObjectPath 117 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.ActivationBlocksTransition<br> at ObjectPath 118 CU ->> CU: Activation.Status = Activating 119 CU --) BMCW: Notify Activation.Status change 120 note over CU: Start Update 121 loop 122 CU --) BMCW: Notify ActivationProgress.Progress change 123 end 124 note over CU: Finish Update 125 CU ->> CU: Activation.Status = Active 126 CU --) BMCW: Notify Activation.Status change 127 CU ->> CU: Delete Interface<br> xyz.openbmc_project.Software.ActivationBlocksTransition 128 CU ->> CU: Delete Interface<br> xyz.openbmc_project.Software.ActivationProgress 129 alt ApplyTime == Immediate 130 note over CU: Reset Device 131 CU ->> CU: Update functional association to System Inventory Item 132 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at ObjectPath 133 note over CU: Delete all interfaces on previous ObjectPath 134 else 135 note over CU: Create active association to System Inventory Item 136 end 137 end 138end 139``` 140 141- Each upgradable hardware type may have a separate daemon (\<deviceX\> as per 142 above flow) handling its update process and would need to implement the 143 proposed interfaces in next section. This satisfies the 144 [Requirement# 6](#requirements). 145- Since, there would be single daemon handling the update (as compared to 146 three), less hand shaking would be involved and hence addresses the 147 [Issue# 1](#problem-description) and [Requirement# 4](#requirements). 148 149### Proposed D-Bus Interface 150 151The DBus Interface for code update will consist of following - 152 153| Interface Name | Existing/New | Purpose | 154| :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------: | :---------------------------------------------------------------------------------------------------------: | 155| [xyz.openbmc_project.Software.Update](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/65738) | New | Provides update method | 156| [xyz.openbmc_project.Software.MultipartUpdate](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/78905) | New | Interface to identify the multi part updater which can do code update based on the multi-part image format. | 157| [xyz.openbmc_project.Software.Version](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/Version.interface.yaml) | Existing | Provides version info | 158| [xyz.openbmc_project.Software.Activation](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/Activation.interface.yaml) | Existing | Provides activation status | 159| [xyz.openbmc_project.Software.ActivationProgress](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/ActivationProgress.interface.yaml) | Existing | Provides activation progress percentage | 160| [xyz.openbmc_project.Software.ActivationBlocksTransition](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/ActivationBlocksTransition.interface.yaml) | Existing | Signifies barrier for state transitions while update is in progress | 161| [xyz.openbmc_project.Software.RedundancyPriority](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/RedundancyPriority.interface.yaml) | Existing | Provides the redundancy priority for the version interface | 162| [xyz.openbmc_project.Software.Asset](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/Software/Asset.interface.yaml) | New | Provides Manufacturer and Release Date information | 163 164Introduction of xyz.openbmc_project.Software.Update interface streamlines the 165update invocation flow and hence addresses the [Issue# 2](#problem-description) 166and [Requirement# 1 & 2](#requirements). 167 168#### Association 169 170`running` : A `running` association from xyz.openbmc_project.Inventory.Item to 171xyz.openbmc_project.Software.Version represents the current functional or 172running software version for the associated inventory item. The `ran_on` would 173be the corresponding reverse association. 174 175`activating` : An `activating` association from 176xyz.openbmc_project.Inventory.Item to xyz.openbmc_project.Software.Version 177represents the activated (but not yet run) software version for the associated 178inventory item. There could be more than one active versions for an inventory 179item, for example, in case of A/B redundancy models there are 2 associated 180flash-banks and xyz.openbmc_project.Software.RedundancyPriority interface 181defines the priority for each one. 182 183For A/B redundancy model with staging support, the 184xyz.openbmc_project.Software.Activation.Activations.Staged will help to define 185which software version is currently staged. 186 187The `activated_on` would be the corresponding reverse association. 188 189### Keep images in memory 190 191Images will be kept in memory and passed to \<deviceX>CodeUpdater using a file 192descriptor rather than file path. Implementation needs to monitor appropriate 193memory limits to prevent parallel updates from running BMC out of memory. 194 195### Propagate errors to client 196 197xyz.openbmc_project.Software.Update.StartUpdate return value will propagate any 198errors related to initial setup and image metadata/header parsing back to user. 199Any asynchronous errors which happen during the update process will be notified 200via failed activation status which maps to failed task associated with the 201update. Also, a phosphor-logging event will be created and sent back to client 202via 203[Redfish Log Service](https://redfish.dmtf.org/schemas/v1/LogService.v1_4_0.json). 204 205Another alternative could be to use 206[Redfish Event Services](https://redfish.dmtf.org/schemas/v1/EventService.v1_10_0.json). 207 208### Firmware Image Format 209 210Image parsing will be performed in \<deviceX>CodeUpdater and since 211\<deviceX>CodeUpdater may be a device specific daemon, vendor may choose any 212image format for the firmware image. This fulfills the 213[Requirement# 7](#requirements). 214 215#### PLDM Image Packaging 216 217The PLDM for 218[Firmware Update Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0267_1.3.0.pdf) 219provides a standardized packaging format for images, incorporating both standard 220and user-defined descriptors. This format can be utilized to package firmware 221update images for non-PLDM devices as well. For such devices, the CodeUpdater 222will parse the entity manager configuration to identify applicable PLDM 223descriptors, which can include but are not limited to the following - 224 225| PLDM Package Descriptor | Decsriptor Type | Description | 226| :---------------------: | :-------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | 227| IANA Enterprise ID | Standard | [IANA Enterprise Id](https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers) of the hardware vendor | 228| ASCII Model | Standard | Compatible hardware name (com.\<vendor\>.Hardware.\<XXX\>) specified by hardware vendor in [phosphor-dbus-interfaces](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/com). | 229 230#### Entity Manager Configuration 231 232The entity manager configuration can provide firmware-related information as 233part of board configurations, which can be utilized for firmware validation and 234modeling device access details. These D-Bus objects can then be consumed by the 235CodeUpdater service to manage updates for the relevant firmware entities. 236 237For common firmware info definition 238[refer](https://gerrit.openbmc.org/c/openbmc/entity-manager/+/75947) 239 240The following example is one such instance of this definition for an i2c CPLD 241device firmware. 242 243```json 244"Exposes": [ 245 ... 246 { 247 "Name": "MB_LCMX02_2000HC", 248 "Type": "CPLDFirmware", 249 ... 250 "FirmwareInfo" : 251 { 252 "VendorIANA": 0000A015, 253 "CompatibleHardware": "com.meta.Hardware.Yosemite4.MedusaBoard.CPLD.LCMX02_2000HC" 254 } 255 ... 256 }, 257 ... 258] 259``` 260 261- `Name`: The name of the firmware entity instance. 262- `Type`: This field is used by the CodeUpdater service to determine which 263 firmware EM configurations it should process. 264- `VendorIANA`: This field maps to the `IANA Enterprise ID` descriptor in PLDM 265 package header. 266- `CompatibleHardware`: This field maps to the `ASCII Model` descriptor in PLDM 267 package header. 268 269### Pre and Post Update Conditions 270 271Certain device updates may necessitate specific configurations or actions to be 272executed before or after the update process. One such example of a post update 273action is the device reset. While these actions can be integrated into the 274update process for some updaters, it is often ideal to define them as structured 275hooks within the firmware update process. This section aims to establish such 276hooks for applicable updaters. 277 278#### JSON schema for Configuration 279 280The Code Updater daemon can be configured to execute platform-specific pre and 281post update systemd targets, as defined by the JSON schema definition below: 282 283```json 284{ 285 "$schema": "http://json-schema.org/draft-04/schema#", 286 "type": "array", 287 "items": [ 288 { 289 "description": "The definition for the pre and post update targets", 290 "type": "object", 291 "properties": { 292 "Identifier": { 293 "type": "string", 294 "description": "The unique identifier for a device or a component." 295 }, 296 "PreUpdateTarget": { 297 "type": "string", 298 "decsription": "The systemd target service that should be run before starting an update." 299 }, 300 "PostUpdateTarget": { 301 "type": "string", 302 "description": "The systemd target service that should be run after an update has finished successfully." 303 } 304 }, 305 "additionalProperties": false 306 } 307 ] 308} 309``` 310 311- `Identifier` maps to `DeviceX` defined in the preceding sections. 312 313#### Example Configuration 314 315```json 316[ 317 { 318 "Identifier": "Device1", 319 "PostUpdateTarget": "ABC_PostUpdate.service" 320 }, 321 { 322 "Identifier": "Device2_ComponentX", 323 "PreUpdateTarget": "XYZ_PreUpdate.service", 324 "PostUpdateTarget": "XYZ_PostUpdate.service" 325 }, 326 { 327 "Identifier": "Device3_ComponentY", 328 "PreUpdateTarget": "JKL_PreUpdate.service", 329 "PostUpdateTarget": "JKL_PostUpdate.service" 330 } 331] 332``` 333 334#### Executing Pre/Post Update Services 335 336If no pre or post service is specified for an `Identifier`, it will be skipped. 337However, if a service is specified, it will be triggered and if the start fails, 338error handling procedures shall be executed accordingly. 339 340To start these services, the CodeUpdater uses the 341[StartUnit](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html) 342method from org.freedesktop.systemd1.Manager interface exposed by systemd 343service. 344 345#### Handling Pre/Post Update Service Completion 346 347For a triggered pre/post update service, the CodeUpdater waits for completion by 348registering for the 349[JobRemoved](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html) 350signal for org.freedesktop.systemd1.Manager interface. Depending on the returned 351status, the CodeUpdater decides to fail or proceed further and updates the 352activation status accordingly. 353 354#### Handling Hanging Tasks 355 356To handle ever-hanging tasks, pre and post update services can specify 357`RuntimeMaxSec`, which helps terminate the hanging service and deliver the 358designated state via the JobRemoved signal. 359 360### Multi part Images 361 362A multi part image has multiple component images as part of one image package. 363PLDM image is one such example of multi part image format. Sometimes, for multi 364part devices there is no concrete physical firmware device but firmware device 365itself consists of multiple phsyical components, each of which may have its own 366component image. In such a scenario, \<deviceX>CodeUpdater can create a logical 367inventory item for the firmware device. While performing the firmware device 368update, the client may target the logical firmware device which further knows 369how to update the corresponding child components for supplied component images. 370The user can also update the specific component by providing the image package 371with component as head node. The \<deviceX>CodeUpdater can implement the 372required logic to verify if the supplied image is targeted for itself (and child 373components) or not. 374 375### Multi part image handling w/o Targets 376 377A service intended to process firmware updates via a multi-part image, without 378explicit update targets, is required to implement the 379xyz.openbmc_project.Software.MultipartUpdate interface. The system permits only 380a single instance of this interface. If no targets are provided, bmcweb searches 381for the service exposing this interface and invokes the StartUpdate method at 382the associated object path. 383 384The PLDM package is an example of multi-part image format. At the application 385layer, the pldmd daemon implements both 386xyz.openbmc_project.Software.MultipartUpdate and 387xyz.openbmc_project.Software.Update D-Bus interfaces. Upon receiving a PLDM 388package, pldmd parses the content, applies the component-matching algorithm as 389defined by the PLDM Type 5 specification, and initiates firmware updates for 390relevant PLDM devices, also ensuring component updates are ordered per firmware 391device. This implementation does not cover scenario where PLDM package can be 392used to update PLDM and Non-PLDM devices. 393 394pldmd implements standard interfaces: 395 396- `xyz.openbmc_project.Software.MultipartUpdate` 397- `xyz.openbmc_project.Software.Update` 398- `xyz.openbmc_project.Software.Activation` 399- `xyz.openbmc_project.Software.ActivationProgress` 400 401```mermaid 402 graph TD 403 subgraph bmcweb["bmcweb"] 404 end 405 406 subgraph PLDM["pldmd"] 407 direction TB 408 P1["libpldm"] 409 end 410 411 bmcweb <--> |MultipartUpdate D-Bus Intf<br>StartUpdate D-Bus Intf| PLDM 412 PLDM <--> |MCTP| F[PLDM endpoints] 413 414 415 classDef bmcweb fill:#f8f0ff,stroke:#333,stroke-width:1px; 416 classDef manager fill:#fff3e0,stroke:#333,stroke-width:1px; 417 classDef pldm fill:#e3f2fd,stroke:#333,stroke-width:1px; 418 classDef endpoints fill:#ffffff,stroke:#333,stroke-width:1px; 419 classDef libpldm fill:#ffcdd2,stroke:#333,stroke-width:1px; 420 421 class bmcweb bmcweb; 422 class PLDM pldm; 423 class F endpoints; 424 class P1 libpldm; 425``` 426 427### Update multiple devices of same type 428 429- For same type devices, extend the Dbus path to specify device instance, for 430 example, /xyz/openbmc_project/Software/\<deviceX>\_\<InstanceNum>\_\<SwId>. 431 All the corresponding interfaces can reside on this path and same path will be 432 returned from xyz.openbmc_project.Software.Update.StartUpdate. 433 434This fulfills the [Requirement# 9](#requirements). 435 436### Parallel Upgrade 437 438- Different type hardware components: 439 440 Upgrade for different type hardware components can be handled either by 441 different `<deviceX>CodeUpdater` daemons or by a single daemon for hardware 442 components with common features, for example, PLDMd may handle update for 443 devices using PLDM specification. Such updates can be invoked in parallel from 444 BMCWeb and tracked via different tasks. 445 446- Similar type hardware component: 447 448 BMCWeb will trigger xyz.openbmc_project.Software.Update.StartUpdate on 449 different D-Bus paths pertaining to each hardware instance. For more details 450 on D-Bus paths refer to 451 [Update multiple devices of same type](#update-multiple-devices-of-same-type). 452 453This fulfills the [Requirement# 9](#requirements). 454 455### Uninterrupted Updates 456 457`ActivationBlocksTransitions` interface will be created on the specific D-Bus 458path for a version update which will help to block any interruptions from 459critical system actions such as reboots. This interface can in turn start and 460stop services such as Boot Guard Service to prevent such interruptions. 461 462Moreover, when a device is being upgraded the sensor scanning for that device 463might need to be disabled. To achieve this, the sensor scanning flow can check 464for existence of `ActivationBlocksTransitions` interface on associated `Version` 465DBus path for the inventory item. If such interface exists, the sensor scanning 466for that device can be skipped by returning back relevant error (such as 467`EBUSY`) to the client. Another alternative is to check for existence of 468`ActivationBlocksTransitions` interface only if sensor scanning times out. This 469won't impact average case performance for sensor scanning but only the worst 470case scenario when device is busy, for example, due to update in progress. 471 472## Alternatives Considered 473 474### Centralized Design with Global Software Manager 475 476Single SoftwareManager which communicates with the BCMWeb, hosts all the 477interfaces such as Version, Activation, Progress for all hardware components 478within the system on different DBus paths. Software Manager keeps list of 479various hardware update services within the system and start them based on 480update request. These on-demand services update the hardware and interfaces 481hosted by Software Manager and exits. 482 483#### Pros 484 485- Most of the DBus interfaces gets implemented by Software Manager and vendors 486 would need to write minimal code to change properties for these interfaces 487 based on status and progress. 488- Under normal operating conditions (no update in flight), only Software Manager 489 will be running. 490 491#### Cons 492 493- Imposes the need of a common image format as Software Manager needs to parse 494 and verify the image for creating interfaces. 495- Limitation in the design, as there is a need to get the current running 496 version from the hardware at system bring up. So, Software Manager would need 497 to start each update daemon at system startup to get the running version. 498 499### Pull model for Status and Progress 500 501The proposed solution uses a push model where status and progress updates are 502asynchronously pushed to BMCWeb. Another alternative would be to use a pull 503model where Update interface can have get methods for status and progress (for 504example, getActivationStatus and getActivationProgress). 505 506#### Pros 507 508- Server doesn't have to maintain a Dbus matcher 509 ([Issue](https://github.com/openbmc/bmcweb/issues/202)). 510- Easier implementation in Server as no asynchronous handlers would be required. 511 512#### Cons 513 514- Server would still need maintain some info so it can map client's task status 515 request to Dbus path for `/xyz/openbmc_project/Software/<deviceX>` for calling 516 getActivationStatus and getActivationProgress. 517- Aforementioned [issue](https://github.com/openbmc/bmcweb/issues/202) is more 518 of an implementation problem which can be resolved through implementation 519 changes. 520- Currently, activation and progress interfaces are being used in 521 [lot of Servers](#organizational). In future, harmonizing the flow to single 522 one will involve changing the push to pull model in all those places. With the 523 current proposal, the only change will be in update invocation flow. 524 525## Impacts 526 527The introduction of new DBus API will temporarily create two invocation flows 528from Server. Servers (BMCWeb, IPMI, etc) can initially support both the code 529stacks. As all the code update daemons gets moved to the new flow, Servers would 530be changed to only support new API stack. No user-api impact as design adheres 531to Redfish UpdateService. 532 533## Organizational 534 535### Does this design require a new repository? 536 537Yes. There will be a device transport level repositories and multiple 538\<deviceX>CodeUpdater using similar transport layer can reside in same 539repository. For example, all devices using PMBus could have a common repository. 540 541### Who will be the initial maintainer(s) of this repository? 542 543Meta will propose repositories for following devices and `Jagpal Singh Gill` & 544`Patrick Williams` will be the maintainer for them. 545 546- VR Update 547- CPLD Update 548 549### Which repositories are expected to be modified to execute this design? 550 551Requires changes in following repositories to incorporate the new interface for 552update invocation - 553 554| Repository | Modification Owner | 555| :------------------------------------------------------------------------------ | :----------------- | 556| [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt) | Jagpal Singh Gill | 557| [BMCWeb](https://github.com/openbmc/bmcweb) | Jagpal Singh Gill | 558| [phosphor-host-ipmid](https://github.com/openbmc/phosphor-host-ipmid) | Jagpal Singh Gill | 559| [pldm](https://github.com/openbmc/pldm/tree/master/fw-update) | Jagpal Singh Gill | 560| [openpower-pnor-code-mgmt](https://github.com/openbmc/openpower-pnor-code-mgmt) | Adriana Kobylak | 561| [openbmc-test-automation](https://github.com/openbmc/openbmc-test-automation) | Adriana Kobylak | 562 563NOTE: For 564[phosphor-psu-code-mgmt](https://github.com/openbmc/phosphor-psu-code-mgmt) code 565seems unused, so not tracking for change. 566 567## Testing 568 569### Unit Testing 570 571All the functional testing of the reference implementation will be performed 572using GTest. 573 574### Integration Testing 575 576The end to end integration testing involving Servers (for example BMCWeb) will 577be covered using openbmc-test-automation. 578