common: add GPIO controller function

The CPLD update process requires toggling a GPIO pin to control the
debug card mux. BIOS and EEPROM updates use the same logic, so refactor
the duplicated code i

common: add GPIO controller function

The CPLD update process requires toggling a GPIO pin to control the
debug card mux. BIOS and EEPROM updates use the same logic, so refactor
the duplicated code into a common GPIO controller function. Update BIOS,
EEPROM, and CPLD code paths to use the new helper.

Tested:
- Verified CPLD update with GPIO mux toggling
- Verified BIOS update with GPIO mux toggling

Verified CPLD update with GPIO mux toggling
```
Dec 18 18:33:35 bmc phosphor-cpld-software-update[1064]: Requesting chip gpiochip0, GPIO line debug-card-mux to 1
Dec 18 18:33:35 bmc phosphor-cpld-software-update[1064]: Updating Lattice CPLD firmware
Dec 18 18:33:45 bmc phosphor-cpld-software-update[1064]: [48K blob data]
Dec 18 18:34:14 bmc phosphor-cpld-software-update[1064]: [48K blob data]
Dec 18 18:34:31 bmc phosphor-cpld-software-update[1064]: Successfully updated CPLD
Dec 18 18:34:31 bmc phosphor-cpld-software-update[1064]: Requesting chip gpiochip0, GPIO line debug-card-mux to 0
```

Verified BIOS update with GPIO mux toggling
```
Dec 18 18:45:53 bmc phosphor-bios-software-update[1063]: Requesting chip gpiochip0, GPIO line FM_MUX1_SEL_R to 1
Dec 18 18:46:24 bmc phosphor-bios-software-update[2158]: [14.8K blob data]
Dec 18 18:46:30 bmc phosphor-bios-software-update[2158]: [47.9K blob data]
Dec 18 18:46:37 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:46:44 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:46:51 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:46:58 bmc phosphor-bios-software-update[2158]: [47.9K blob data]
Dec 18 18:46:58 bmc phosphor-bios-software-update[2158]: [4.5K blob data]
Dec 18 18:47:01 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:47:04 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:47:07 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:47:10 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:47:13 bmc phosphor-bios-software-update[2158]: [48K blob data]
Dec 18 18:47:15 bmc phosphor-bios-software-update[2158]: [20.5K blob data]
Dec 18 18:47:17 bmc phosphor-bios-software-update[1063]: Successfully updated SPI flash
Dec 18 18:47:17 bmc phosphor-bios-software-update[1063]: Requesting chip gpiochip0, GPIO line FM_MUX1_SEL_R to 0
```

Change-Id: I8d3c128951fd833a0cd25e1440236f82d37b776f
Signed-off-by: Henry Wu <Henry_Wu@quantatw.com>

show more ...

common: Add getBusName function

Add this function as 'protected' to be able to call it from test code.

The alternative would be to reconstruct the bus name in test code based
on the unique suffix,

common: Add getBusName function

Add this function as 'protected' to be able to call it from test code.

The alternative would be to reconstruct the bus name in test code based
on the unique suffix, duplicating the code.

Tested: Inspection only.

Change-Id: Iafed55b5869850f8e1d547e580bdaffd5cfbb6eb
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: host power utility: add host-state-transition-timeout option

Introduce a configurable host-state-transition-timeout to control
how long the utility waits for a host state change. The previou

common: host power utility: add host-state-transition-timeout option

Introduce a configurable host-state-transition-timeout to control
how long the utility waits for a host state change. The previous 12s
timeout was insufficient for a graceful power off, leading to false
timeout errors.

This option is used by the bios-software-update service to control
the host state transition timeout when turning the host off and on
before and after a BIOS update.

Change-Id: I9209d8f06f55eaf181235198c20c32c93861f841
Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>

show more ...

TPM code updater

This commit introduces a TPM code updater that currently supports
reading the firmware version for both Infineon and Nuvoton TPM 2.0.
Support for firmware updates will be introduced

TPM code updater

This commit introduces a TPM code updater that currently supports
reading the firmware version for both Infineon and Nuvoton TPM 2.0.
Support for firmware updates will be introduced in a future patch.

The updater's configuration are managed by the EM [1].
[1] https://gerrit.openbmc.org/c/openbmc/entity-manager/+/82416

Tested on Yosemite5 with the following steps:

1. Display the fw inventory:
```
curl --silent $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{...},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/Yosemite5_TPM_4945"
},
{...}
],
"Members@odata.count": 4,
"Name": "Software Inventory Collection"
}
```

2. Query TPM version:
```
curl --silent $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory/Yosemite5_TPM_4945
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/Yosemite5_TPM_4945",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "Yosemite5_TPM_4945",
"Name": "Software Inventory",
"Status": {
"Health": "Warning",
"HealthRollup": "OK",
"State": "Disabled"
},
"Updateable": false,
"Version": "15.23"
}
```

Change-Id: I42568242356d55fe005ba1f41ddf8aaf9f682fc8
Signed-off-by: Kevin Tung <kevin.tung.openbmc@gmail.com>

show more ...

common: update: fix error handling

An empty string is not a valid object path [1].

Handle the error by throwing a generated exception as per the
example [3]. This should result in bmcweb receiving

common: update: fix error handling

An empty string is not a valid object path [1].

Handle the error by throwing a generated exception as per the
example [3]. This should result in bmcweb receiving the error.

The exception is generated from [2] and caught in a wrapper function to
set the error.

Tested: on Tyan S8030

First, apply patch to disallow the `OnReset` apply time.

Then trigger the update with a tiny pldm package.

```
curl -k --insecure --user root:root -H Content-Type:multipart/form-data -X POST -F 'UpdateParameters={"Targets":["/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_4102"],"@Redfish.OperationApplyTime":"OnReset"};type=application/json' -F 'UpdateFile=@pldm-package-s8030-host-fake.bin;type=application/octet-stream' ${bmc}/redfish/v1/UpdateService/update-multipart
```

Instead of a task we now get
```
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The request failed due to an internal service error. The service is still operational.",
"MessageArgs": [],
"MessageId": "Base.1.19.InternalError",
"MessageSeverity": "Critical",
"Resolution": "Resubmit the request. If the problem persists, consider resetting the service."
}
],
"code": "Base.1.19.InternalError",
"message": "The request failed due to an internal service error. The service is still operational."
}
}
```

The updater log is

```
Aug 11 14:16:43 s8030-bmc-30303035c0c1 phosphor-bios-software-update[1101]: the selected apply time xyz.openbmc_project.Software.ApplyTime.RequestedApplyTimes.OnReset is not allowed by the device
Aug 11 14:16:43 s8030-bmc-30303035c0c1 phosphor-bios-software-update[1101]: The system component has a software version which is incompatible with the new image or the image is not meant for the system component.
```

The bmcweb log is

```
Aug 11 14:16:43 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:876] Found 2 software version paths
Aug 11 14:16:43 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:894] Found software version path /xyz/openbmc_project/software/HostSPIFlash_4102 serviceName xyz.openbmc_project.Software.BIOS
Aug 11 14:16:43 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:831] error_code = Input/output error [generic:5]
Aug 11 14:16:43 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:832] error msg = Input/output error
Aug 11 14:16:43 s8030-bmc-30303035c0c1 bmcwebd[431]: [error_messages.cpp:1250] Internal Error ../git/redfish-core/lib/update_service.hpp(833:32) `void redfish::handleStartUpdate(const std::shared_ptr<bmcweb::AsyncResp>&, task::Payload, const std::string&, const boost::system::error_code&, const sdbusplus::message::object_path&)`:
```

Now testing the second case, started an immediate update with a real fw
image which will be running for some time.

```
curl -k --insecure --user root:root -H Content-Type:multipart/form-data -X POST -F 'UpdateParameters={"Targets":["/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_4102"],"@Redfish.OperationApplyTime":"Immediate"};type=application/json' -F 'UpdateFile=@pldm-package-s8030-host-v4.03.bin;type=application/octet-stream' ${bmc}/redfish/v1/UpdateService/update-multipart
```

get following task

```
{
"@odata.id": "/redfish/v1/TaskService/Tasks/1",
"@odata.type": "#Task.v1_4_3.Task",
"HidePayload": false,
"Id": "1",
"Messages": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '1' has started.",
"MessageArgs": [
"1"
],
"MessageId": "TaskEvent.1.0.TaskStarted",
"MessageSeverity": "OK",
"Resolution": "None."
}
],
"Name": "Task 1",
"Payload": {
"HttpHeaders": [],
"HttpOperation": "POST",
"TargetUri": "/redfish/v1/UpdateService/update-multipart"
},
"PercentComplete": 0,
"StartTime": "2025-08-11T14:27:25+00:00",
"TaskMonitor": "/redfish/v1/TaskService/TaskMonitors/1",
"TaskState": "Running",
"TaskStatus": "OK"
}
```

and bmcweb logs
```
Aug 11 14:31:24 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:876] Found 2 software version paths
Aug 11 14:31:24 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:894] Found software version path /xyz/openbmc_project/software/HostSPIFlash_4102 serviceName xyz.openbmc_project.Software.BIOS
Aug 11 14:31:24 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:838] Call to StartUpdate on /xyz/openbmc_project/software/HostSPIFlash_4102 Success, retPath = /xyz/openbmc_project/software/HostSPIFlash_2903
```

Now quickly start a second update to get following logs

Redfish response:
```
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The request failed due to an internal service error. The service is still operational.",
"MessageArgs": [],
"MessageId": "Base.1.19.InternalError",
"MessageSeverity": "Critical",
"Resolution": "Resubmit the request. If the problem persists, consider resetting the service."
}
],
"code": "Base.1.19.InternalError",
"message": "The request failed due to an internal service error. The service is still operational."
}
}
```

Updater:
```
Aug 11 14:31:24 s8030-bmc-30303035c0c1 phosphor-bios-software-update[1101]: An update is already in progress, cannot update.
Aug 11 14:31:24 s8030-bmc-30303035c0c1 phosphor-bios-software-update[1101]: The service is temporarily unavailable.
```

bmcweb logs:
```
Aug 11 14:31:25 s8030-bmc-30303035c0c1 bmcwebd[431]: [error_messages.cpp:1250] Internal Error ../git/redfish-core/lib/update_service.hpp(833:32) `void redfish::handleStartUpdate(const std::shared_ptr<bmcweb::Asyn
cResp>&, task::Payload, const std::string&, const boost::system::error_code&, const sdbusplus::message::object_path&)`:
Aug 11 14:31:25 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:832] error msg = Input/output error
Aug 11 14:31:25 s8030-bmc-30303035c0c1 bmcwebd[431]: [update_service.hpp:831] error_code = Input/output error [generic:5]
```

So in both error cases both daemons stay running, but the error
reporting to the user can be improved in bmcweb to let them know the
failure reason.

References:

[1] https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-marshaling-object-path
[2] https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Software/Update.interface.yaml
[3] https://github.com/openbmc/sdbusplus/blob/7413ccc1740397239eee9ba79973c285bf6b3e5d/example/calculator-aserver.cpp#L28

Change-Id: I292687652dbeefb15a150757289aebe8fd763482
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: make Software::objectPath const

Software::objectPath is initialized in the constructor and should not be
modified later on.

Can also be protected instead of public.

Tested: Inspection only

common: make Software::objectPath const

Software::objectPath is initialized in the constructor and should not be
modified later on.

Can also be protected instead of public.

Tested: Inspection only.

Change-Id: I9404fc46b6d039d7a7e96ebb232e34ee0aa978e8
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: split inventory association function

Create Software::createInventoryAssociation to split the
object mapper call from actually creating the association.

This makes unit testing the function

common: split inventory association function

Create Software::createInventoryAssociation to split the
object mapper call from actually creating the association.

This makes unit testing the functions easier and provides a clean
separation between the logic provided by common code versus the external
information we are fetching.

Tested: Inspection only.

Change-Id: I0147480219b9c9fbc709699b9e50411fb11bea6e
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: fix Software::getPurpose error path

'version' cannot be dereferenced if it is not initialized.

Change the API to return an std::optional and handle in the caller.

Change-Id: Iac7badf145dad

common: fix Software::getPurpose error path

'version' cannot be dereferenced if it is not initialized.

Change the API to return an std::optional and handle in the caller.

Change-Id: Iac7badf145dad64e21ede5e81f0b4b761ff6c89d
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: fix: add emit_added calls

Add these calls to make bmcweb and mapper aware of our DBus interfaces.

Adding emit_added() should be safe to do since the interface already
exists and the functio

common: fix: add emit_added calls

Add these calls to make bmcweb and mapper aware of our DBus interfaces.

Adding emit_added() should be safe to do since the interface already
exists and the function is idempotent.

Also set the activation status of the current software version to
'Active' after 'initDevice' returns.

Tested: on Tyan S8030

Restarting BIOS sw manager without this patch yields

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_7868",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_7868",
"Name": "Software Inventory",
"Status": {
"Health": "Warning",
"HealthRollup": "OK",
"State": "Disabled"
},
"Updateable": true,
"Version": "Unknown"
}
```

which is wrong since there is currently a sw version enabled.

First testing update process without this patch

```
curl -k --insecure --user root:root -H Content-Type:multipart/form-data -X POST -F 'UpdateParameters={"Targets":["/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_7868"],"@Redfish.OperationApplyTime":"Immediate"};type=application/json' -F 'UpdateFile=@pldm-package-s8030-host-v4.01.bin;type=application/octet-stream' https://${bmc}/redfish/v1/UpdateService/update-multipart
```

yields

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_5637",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_5637",
"Name": "Software Inventory",
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
},
"Updateable": true,
"Version": "mycompversion"
}
```

BIOS update process completes and bmcweb shows fw inventory as expected

Starting the update process (with this patch):
```
curl -k --insecure --user root:root -H Content-Type:multipart/form-data -X POST -F 'UpdateParameters={"Targets":["/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_8460"],"@Redfish.OperationApplyTime":"Immediate"};type=application/json' -F 'UpdateFile=@pldm-package-s8030-host-v4.01.bin;type=application/octet-stream' https://${bmc}/redfish/v1/UpdateService/update-multipart
```

Task returned from starting update process
```
{
"@odata.id": "/redfish/v1/TaskService/Tasks/2",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "2",
"TaskState": "Running",
"TaskStatus": "OK"
}
```

After update:
```
curl --insecure --user root:root https://${bmc}/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_918
```

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_918",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_918",
"Name": "Software Inventory",
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
},
"Updateable": true,
"Version": "mycompversion"
}
```

So we concluded that the fw inventory is correct even without the patch
but on initial start of the BIOS sw manager the fw inventory is not
correct.

After restarting the BIOS sw manager with this patch:

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_2291",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_2291",
"Name": "Software Inventory",
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
},
"Updateable": true,
"Version": "Unknown"
}
```

Change-Id: I3aee245311b30e1ceba50d16598f940bb87626b0
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: create initial associations

Associations to the inventory item were created during the update
process but not for the initial software version.

```
common/src/device.cpp
206: co_awai

common: create initial associations

Associations to the inventory item were created during the update
process but not for the initial software version.

```
common/src/device.cpp
206: co_await softwarePending->createInventoryAssociations(true);
212: co_await softwarePending->createInventoryAssociations(false);
```

Fix this in the common code.

Also reorder the calls there so the interfaces added signal gets emitted
with the correct property value.

Tested: on Tyan S8030. Association appears as expected.
Re-Tested for Patchset 3, same result.

```
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: [Software] enabling update of /xyz/openbmc_project/software/HostSPIFlash_3216 (adding the update interface)
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: HostSPIFlash_3216: set version Unknown
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: HostSPIFlash_3216: setting association definitions
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: inventory item at path /xyz/openbmc_project/inventory/system/board/chassis
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: found associated inventory item for HostSPIFlash: /xyz/openbmc_project/inventory/system/board/chassis
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: HostSPIFlash_3216: creating 'running' association to /xyz/openbmc_project/inventory/system/board/chassis
Jul 23 12:19:08 s8030-bmc-30303035c0c1 phosphor-bios-software-update[32158]: Done with initial configuration
```

```
busctl get-property xyz.openbmc_project.Software.BIOS /xyz/openbmc_project/software/HostSPIFlash_3216 xyz.openbmc_project.Association.Definitions Associations
a(sss) 1 "running" "ran_on" "/xyz/openbmc_project/inventory/system/board/chassis"
```

The signal is emitted correctly for object mapper as well
```
object path "/xyz/openbmc_project/software/HostSPIFlash_3216"
array [
dict entry(
string "xyz.openbmc_project.Association.Definitions"
array [
dict entry(
string "Associations"
variant array [
struct {
string "running"
string "ran_on"
string "/xyz/openbmc_project/inventory/system/board/chassis"
}
]
)
]
)
]
```

Change-Id: Ie3d76d3bdf445a53c578c3a827b90950fa4bda0a
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: move asyncSystem() to common

asyncSystem() is shared across updaters, so moved to common.

Change-Id: I3545d34ecc1f1bf8a226d020267ae00bcf42c5f9
Signed-off-by: Kevin Tung <Kevin.Tung@quantatw

common: move asyncSystem() to common

asyncSystem() is shared across updaters, so moved to common.

Change-Id: I3545d34ecc1f1bf8a226d020267ae00bcf42c5f9
Signed-off-by: Kevin Tung <Kevin.Tung@quantatw.com>

show more ...

common: use aserver property constructor

Since PDI gen code now [1] supports constructing DBus interfaces with
property values, simplify the common code to use that API.

Tested: Unit Tests Pass

Re

common: use aserver property constructor

Since PDI gen code now [1] supports constructing DBus interfaces with
property values, simplify the common code to use that API.

Tested: Unit Tests Pass

References:
[1] https://gerrit.openbmc.org/c/openbmc/sdbusplus/+/78790

Change-Id: Ic29531b391f8609377105dbcbac2e8a55b29746c
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

clang-tidy: remove some NOLINTS

Since readability-static-accessed-through-instance check has been
disabled in [1], the NOLINTs can be removed.

References:

[1] https://gerrit.openbmc.org/c/openbmc/

clang-tidy: remove some NOLINTS

Since readability-static-accessed-through-instance check has been
disabled in [1], the NOLINTs can be removed.

References:

[1] https://gerrit.openbmc.org/c/openbmc/phosphor-bmc-code-mgmt/+/80392

Change-Id: If7e80a0bc447bfbd054b6c007d230c2d14a54f41
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
Signed-off-by: Jagpal Singh Gill <paligill@gmail.com>

show more ...

fw update: common: Update software_config regex patterns

Update regex patterns in software_config.cpp to match
the latest hardware compatible scheme.

Test on Harma:
EM settings:
``` json
{
"Add

fw update: common: Update software_config regex patterns

Update regex patterns in software_config.cpp to match
the latest hardware compatible scheme.

Test on Harma:
EM settings:
``` json
{
"Address": "0x61",
"Bus": 28,
"FirmwareInfo": {
"CompatibleHardware":
"com.meta.Hardware.Harma.VR.ISL69269_vcore0",
"VendorIANA": 40981
},
"Name": "Harma_MB_vr_cpu0_vcore0",
"Type": "ISL69269Firmware"
},
{
"Address": "0x62",
"Bus": 28,
"FirmwareInfo": {
"CompatibleHardware":
"com.meta.Hardware.Harma.VR.ISL69269_vcore1",
"VendorIANA": 40981
},
"Name": "Harma_MB_vr_cpu0_vcore1",
"Type": "ISL69269Firmware"
},
{
"Address": "0x63",
"Bus": 28,
"FirmwareInfo": {
"CompatibleHardware":
"com.meta.Hardware.Harma.VR.ISL69269_pvdd11",
"VendorIANA": 40981
},
"Name": "Harma_MB_vr_cpu0_pvdd11",
"Type": "ISL69269Firmware"
}
```
Harma updater log
``` bash
root@bmc:~#
/usr/libexec/phosphor-code-mgmt/phosphor-i2cvr-software-update
<7> requesting dbus name xyz.openbmc_project.Software.I2CVR
<7> Initialized SoftwareManager
<7> [config] looking for dbus interface ...XDPE1X2XXFirmware
<7> [config] looking for dbus interface ...ISL69269Firmware
<7> Found configuration interface at xyz.openbmc_project.EntityManager,
/.../board/Harma_MB/Harma_MB_vr_cpu0_pvdd11
<7> [config] Voltage regulator device type:
ISL69269Firmware on Bus: 28 at Address: 99
<7> Harma_MB_vr_cpu0_pvdd11_3351: created dbus interfaces on path
/xyz/openbmc_project/software/Harma_MB_vr_cpu0_pvdd11_3351
<7> Harma_MB_vr_cpu0_pvdd11_3351: set version 4294049940
<7> [Software] enabling update of
/.../Harma_MB_vr_cpu0_pvdd11_3351 (adding the update interface)
<7> Found configuration interface at xyz.openbmc_project.EntityManager,
/.../board/Harma_MB/Harma_MB_vr_cpu0_vcore0
<7> [config] Voltage regulator device type:
ISL69269Firmware on Bus: 28 at Address: 97
<7> Harma_MB_vr_cpu0_vcore0_916: created dbus interfaces on path
/xyz/openbmc_project/software/Harma_MB_vr_cpu0_vcore0_916
<7> Harma_MB_vr_cpu0_vcore0_916: set version 4283812141
<7> [Software] enabling update of
/.../Harma_MB_vr_cpu0_vcore0_916 (adding the update interface)
<7> Found configuration interface at xyz.openbmc_project.EntityManager,
/.../board/Harma_MB/Harma_MB_vr_cpu0_vcore1
<7> [config] Voltage regulator device type:
ISL69269Firmware on Bus: 28 at Address: 98
<7> Harma_MB_vr_cpu0_vcore1_3742: created dbus interfaces on path
/xyz/openbmc_project/software/Harma_MB_vr_cpu0_vcore1_3742
<7> Harma_MB_vr_cpu0_vcore1_3742: set version 4292870292
<7> [Software] enabling update of
/.../Harma_MB_vr_cpu0_vcore1_3742 (adding the update interface)
<7> Done with initial configuration
```

Change-Id: I2d3155733d6c65e76f4ea6dd9814e6b51b83c228
Signed-off-by: Daniel Hsu <Daniel-Hsu@quantatw.com>

show more ...

common: Add emit_added for Software Update intf

The 'InterfacesAdded' signal is needed for the object mapper to know of
the dbus interface.

```
root@s8030-bmc-30303035c0c1:~# busctl tree xyz.openbm

common: Add emit_added for Software Update intf

The 'InterfacesAdded' signal is needed for the object mapper to know of
the dbus interface.

```
root@s8030-bmc-30303035c0c1:~# busctl tree xyz.openbmc_project.Software.BIOS
`- /xyz
`- /xyz/openbmc_project
`- /xyz/openbmc_project/software
`- /xyz/openbmc_project/software/HostSPIFlash_5592
```

But the object mapper does not find the object path

```
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper GetSubTreePaths sias /xyz/openbmc_project 0 1 xyz.openbmc_project.Software.Update
as 2 "/xyz/openbmc_project/software/269f96b7" "/xyz/openbmc_project/software/bios_active"
```

meanwhile it finds the version interface, since there we already emit
the signal.

```
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper GetSubTreePaths sias /xyz/openbmc_project 0 1 xyz.openbmc_project.Software.Version
as 7 "/xyz/openbmc_project/logging/entry/1" "/xyz/openbmc_project/logging/entry/2" "/xyz/openbmc_project/logging/entry/3" "/xyz/openbmc_project/logging/entry/4" "/xyz/openbmc_project/software/269f96b7" "/xyz/openbmc_project/software/HostSPIFlash_5592" "/xyz/openbmc_project/software/bios_active"
```

Tested: Since the interface is emitted, object mapper now knows of the
object path.

```
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper GetSubTreePaths sias /xyz/openbmc_project 0 1 xyz.openbmc_project.Software.Update
as 3 "/xyz/openbmc_project/software/269f96b7" "/xyz/openbmc_project/software/HostSPIFlash_2523" "/xyz/openbmc_project/software/bios_active"
```

The software appears as updatable in the fw inventory.

```
curl --insecure --user root:root https://${bmc}/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_2523
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_2523",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_2523",
"Name": "Software Inventory",
"Status": {
"Health": "Warning",
"HealthRollup": "OK",
"State": "Disabled"
},
"Updateable": true,
"Version": "Unknown"
}
```

Change-Id: Ibb7f9a5d122e991048b3513c6b9448e105173ca5
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: handle match for config intf added/removed

When the configuration interface for any device is added or removed as
part of dynamic configuration (via EM) the software manager has to
handle th

common: handle match for config intf added/removed

When the configuration interface for any device is added or removed as
part of dynamic configuration (via EM) the software manager has to
handle the dbus match and add or remove devices as necessary.

When an update is in progress, the device is not removed,
even if the configuration was removed.

Tested: On Tyan S8030 with bios software updater

For testing add/remove of configuration interfaces, the configuration
was probed on the powersupply FRU.

In case of InterfacesAdded:

```
May 26 14:54:00 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: [config] found configuration interface at xyz.openbmc_project.EntityManager, /xyz/openbmc_project/inventory/system/board/HostSPIFlash/HostSPIFlash
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: Missing property Name on path /xyz/openbmc_project/inventory/system/board/HostSPIFlash/HostSPIFlash, interface xyz.openbmc_project.Configuration.SPIFlash.MuxOutputs1
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: Missing property Polarity on path /xyz/openbmc_project/inventory/system/board/HostSPIFlash/HostSPIFlash, interface xyz.openbmc_project.Configuration.SPIFlash.MuxOutputs1
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: SPI device: 1:0
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: Found SPI Address 1e630000.spi
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: SPI Device HostSPIFlash at 1:0 initialized successfully
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: HostSPIFlash_5930: created dbus interfaces on path /xyz/openbmc_project/software/HostSPIFlash_5930
May 26 14:54:09 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: [Software] enabling update of /xyz/openbmc_project/software/HostSPIFlash_5930 (adding the update interface)
```

```
busctl tree xyz.openbmc_project.Software.BIOS
`- /xyz
`- /xyz/openbmc_project
`- /xyz/openbmc_project/software
`- /xyz/openbmc_project/software/HostSPIFlash_5930
```

In case of InterfacesRemoved:

```
May 26 14:58:23 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: detected interface xyz.openbmc_project.Configuration.SPIFlash removed on /xyz/openbmc_project/inventory/system/board/HostSPIFlash/HostSPIFlash
May 26 14:58:23 s8030-bmc-30303035c0c1 phosphor-bios-software-update[9530]: removing device at /xyz/openbmc_project/inventory/system/board/HostSPIFlash/HostSPIFlash
```

```
busctl tree xyz.openbmc_project.Software.BIOS
`- /xyz
`- /xyz/openbmc_project
`- /xyz/openbmc_project/software
```

Change-Id: I4faeb8e0144408b57767783ba2c5c4f3561f4021
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: extract handleInterfaceAdded

The function is extracted from initDevices to decouple it from iterating
over the object mapper response.

Code is only moved and not changed.

Tested: Unit Test

common: extract handleInterfaceAdded

The function is extracted from initDevices to decouple it from iterating
over the object mapper response.

Code is only moved and not changed.

Tested: Unit Tests Pass

Change-Id: I5d776818ca1bd7fb335bc540b07ff12993c1125e
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: break out fetching common configuration

Since SoftwareConfig is holding the common configuration, create a
static function on that class to fetch it from dbus.

This helps to keep that logic

common: break out fetching common configuration

Since SoftwareConfig is holding the common configuration, create a
static function on that class to fetch it from dbus.

This helps to keep that logic contained and decouple it from iterating
over the response returned by the mapper.

The code is only moved and unchanged otherwise.

Tested: Unit Tests Pass

Change-Id: Ic0786e3bb1be4f139321dc2515218c40f13e9597
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

SPI device code updater

This code updater is for updating spi flash devices.
It can for example update the host firmware on different server boards
and has following features:

- power down the host

SPI device code updater

This code updater is for updating spi flash devices.
It can for example update the host firmware on different server boards
and has following features:

- power down the host before update
- set mux gpios to access spi flash
- (very limited) communication with ME (Management Engine)
- use flashrom to utilize fw with IFD (Intel Flash Descriptor)
- otherwise directly write to the flash chip.

The behavior of this code updater can be configured via EM.

Tested: on Tyan S8030 and Tyan S5549 Board. Steps below.

1. Display the fw inventory

```
curl --silent $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory
```

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/717f6f4d"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_4950"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bios_active"
}
],
"Members@odata.count": 3,
"Name": "Software Inventory Collection"
}
```

2. Query BIOS version.
The version is "unknown" here since currently there is no interface
enabled via which to query it.

```
curl $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_4950
```

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_4950",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_4950",
"Name": "Software Inventory",
"Status": {
"Health": "Warning",
"HealthRollup": "OK",
"State": "Disabled"
},
"Updateable": true,
"Version": "unknown"
}
```

3. Trigger the fw update via redfish.

```
curl -k ${creds} \
-H "Content-Type:multipart/form-data" \
-X POST \
-F UpdateParameters="{\"Targets\":[\"/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_6041\"],\"@Redfish.OperationApplyTime\":\"Immediate\"};type=application/json" \
-F "UpdateFile=@${fwpath};type=application/octet-stream" \
https://${bmc}/redfish/v1/UpdateService/update
```

4. Task is returned

```
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "0",
"TaskState": "Running",
"TaskStatus": "OK"
}
```

5. Query Task status
```
curl --silent $creds https://$bmc/redfish/v1/TaskService/Tasks/0
```

```
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"EndTime": "2025-02-18T14:05:46+00:00",
"HidePayload": false,
"Id": "0",
"Messages": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has started.",
"MessageArgs": [
"0"
],
"MessageId": "TaskEvent.1.0.TaskStarted",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 10 percent complete.",
"MessageArgs": [
"0",
"10"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 20 percent complete.",
"MessageArgs": [
"0",
"20"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 70 percent complete.",
"MessageArgs": [
"0",
"70"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 100 percent complete.",
"MessageArgs": [
"0",
"100"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has completed.",
"MessageArgs": [
"0"
],
"MessageId": "TaskEvent.1.0.TaskCompletedOK",
"MessageSeverity": "OK",
"Resolution": "None."
}
],
"Name": "Task 0",
"Payload": {
"HttpHeaders": [],
"HttpOperation": "POST",
"JsonBody": "null",
"TargetUri": "/redfish/v1/UpdateService/update"
},
"PercentComplete": 90,
"StartTime": "2025-02-18T14:04:47+00:00",
"TaskMonitor": "/redfish/v1/TaskService/TaskMonitors/0",
"TaskState": "Completed",
"TaskStatus": "OK"
}
```

6. Display the fw inventory with newly updated fw.
```
curl --silent $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory
```

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/717f6f4d"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_8728"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bios_active"
}
],
"Members@odata.count": 3,
"Name": "Software Inventory Collection"
}
```

7. Query the new fw version.

The version is 'mycompversion' since that's what has been set in the
pldm fw update package for testing.

```
curl $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_8728
```

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_8728",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Unknown image",
"Id": "HostSPIFlash_8728",
"Name": "Software Inventory",
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
},
"Updateable": false,
"Version": "mycompversion"
}
```

Change-Id: I27803b7fded71af2364c2f55fad841a410603dec
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

fix object manager path and emit interfaces added

- move object manager to the correct path
- setup the bus name in constructor
- emit 'InterfacesAdded' signal for object manager to find our
softw

fix object manager path and emit interfaces added

- move object manager to the correct path
- setup the bus name in constructor
- emit 'InterfacesAdded' signal for object manager to find our
software version

Since properties can be uninitialized in the generated bindings,
we have to initialize each property like version and version purpose.

Since object mapper relies on 'InterfacesAdded' signal, emit that
signal such that our version is found in the firmware inventory.

Tested: on Tyan S8030 board with bios code updater

Using dbus-monitor, verify that the signal was emitted for initial
version.

```
dbus-monitor --system "sender='xyz.openbmc_project.Software.BIOS',member='InterfacesAdded'"

signal time=1740740306.586571 sender=:1.266 -> destination=(null destination) serial=21 path=/xyz/openbmc_project/software; interface=org.freedesktop.DBus.ObjectManager; member=InterfacesAdded
object path "/xyz/openbmc_project/software/HostSPIFlash_1520"
array [
dict entry(
string "xyz.openbmc_project.Software.Version"
array [
dict entry(
string "Version"
variant string "v1.03"
)
dict entry(
string "Purpose"
variant string "xyz.openbmc_project.Software.Version.VersionPurpose.Other"
)
]
)
]
```

Using object mapper, verify that it has picked up our initial version:

```
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper GetSubTree sias /xyz/openbmc_project/ 0 1 xyz.openbmc_project.Software.Version
```

Not showing output here since it gets verbose.

Checking the firmware inventory, the version also shows up:
```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/5e6297dd"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_1520"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bios_active"
}
],
"Members@odata.count": 3,
"Name": "Software Inventory Collection"
}
```

Checking the specific entry:
```
curl $creds https://$bmc/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_1520
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_1520",
"@odata.type": "#SoftwareInventory.v1_1_0.SoftwareInventory",
"Description": "Other image",
"Id": "HostSPIFlash_1520",
"Name": "Software Inventory",
"Status": {
"Health": "Warning",
"HealthRollup": "OK",
"State": "Disabled"
},
"Updateable": false,
"Version": "v1.03"
}
```

Now, running an update:

```
curl -k --insecure --user root:root -H Content-Type:multipart/form-data -X POST -F 'UpdateParameters={"Targets":["/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_1520"],"@Redfish.OperationApplyTime":"Immediate"};type=application/json' -F 'UpdateFile=@pldm-package.bin;type=application/octet-stream' https://${bmc}/redfish/v1/UpdateService/update
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"Id": "0",
"TaskState": "Running",
"TaskStatus": "OK"
}
```

Checking the task status:
```
curl --silent --insecure --user root:root https://${bmc}/redfish/v1/TaskService/Tasks/0
{
"@odata.id": "/redfish/v1/TaskService/Tasks/0",
"@odata.type": "#Task.v1_4_3.Task",
"EndTime": "2025-02-28T11:10:55+00:00",
"HidePayload": false,
"Id": "0",
"Messages": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has started.",
"MessageArgs": [
"0"
],
"MessageId": "TaskEvent.1.0.TaskStarted",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 10 percent complete.",
"MessageArgs": [
"0",
"10"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 20 percent complete.",
"MessageArgs": [
"0",
"20"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 70 percent complete.",
"MessageArgs": [
"0",
"70"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has changed to progress 100 percent complete.",
"MessageArgs": [
"0",
"100"
],
"MessageId": "TaskEvent.1.0.TaskProgressChanged",
"MessageSeverity": "OK",
"Resolution": "None."
},
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The task with Id '0' has completed.",
"MessageArgs": [
"0"
],
"MessageId": "TaskEvent.1.0.TaskCompletedOK",
"MessageSeverity": "OK",
"Resolution": "None."
}
],
"Name": "Task 0",
"Payload": {
"HttpHeaders": [],
"HttpOperation": "POST",
"JsonBody": "null",
"TargetUri": "/redfish/v1/UpdateService/update"
},
"PercentComplete": 100,
"StartTime": "2025-02-28T11:10:28+00:00",
"TaskMonitor": "/redfish/v1/TaskService/TaskMonitors/0",
"TaskState": "Completed",
"TaskStatus": "OK"
}
```

Successfully applied this update and the firmware inventory is changed
as expected

```
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory",
"@odata.type": "#SoftwareInventoryCollection.SoftwareInventoryCollection",
"Members": [
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/5e6297dd"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/HostSPIFlash_1149"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/bios_active"
}
],
"Members@odata.count": 3,
"Name": "Software Inventory Collection"
}
```

Checking the object mapper, it is also aware of the new version.

Change-Id: If45158be3ae486e94ae2feb37ce8163b5f795054
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: use state interface object path from pdi

The base path is already available in the generated code, use that.

Change-Id: Ic9de8251a0d1f46890743c4b3390b51c6473a6a2
Signed-off-by: Alexander Ha

common: use state interface object path from pdi

The base path is already available in the generated code, use that.

Change-Id: Ic9de8251a0d1f46890743c4b3390b51c6473a6a2
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: host power utility

Create this utility class to abstract host power operation with a single
function call.

This was refactored out of [1] (BIOS Code Updater)

Tested: Has been tested as par

common: host power utility

Create this utility class to abstract host power operation with a single
function call.

This was refactored out of [1] (BIOS Code Updater)

Tested: Has been tested as part of [1]

References:

[1] https://gerrit.openbmc.org/c/openbmc/phosphor-bmc-code-mgmt/+/76101

Change-Id: I97dc8b1824f70f0aeede3b39683c2ee4ef9ca3c9
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: fetch nested configuration

Config for a code updater is provided via dbus, the common
'FirmwareInfoDef' becomes a nested dbus interface.

For BIOS code updater, it looks like this:
```
xyz.o

common: fetch nested configuration

Config for a code updater is provided via dbus, the common
'FirmwareInfoDef' becomes a nested dbus interface.

For BIOS code updater, it looks like this:
```
xyz.openbmc_project.Configuration.BIOS.FirmwareInfo
```

Update the common code to query this configuration from the nested dbus
interface.

Tested: BIOS code updater can query its configuration with following
EM config json fragment:

```
{
"Name": "HostSPIFlash",
"SPIControllerIndex": 1,
"SPIDeviceIndex": 0,
"HasME": false,
"Layout": "Flat",
"Tool": "None",
"MuxOutputs": ["BMC_SPI_SEL"],
"MuxGPIOValues": [1],
"FirmwareInfo": {
"VendorIANA": "6653",
"CompatibleHardware": "com.tyan.Hardware.S8030.SPI.Host"
},
"Type": "BIOS"
},
```

Change-Id: I1d7241537b759ee74ce4a1f932b5597ac7d95e52
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: constrain object mapper call

Fix this call site where we are fetching configuration to call
'GetSubTree' with our configuration interfaces as argument.

resolves [1]

Tested: With SPI device

common: constrain object mapper call

Fix this call site where we are fetching configuration to call
'GetSubTree' with our configuration interfaces as argument.

resolves [1]

Tested: With SPI device code updater. Configuration is fetched as
expected.

```
<7> [config] looking for dbus interface xyz.openbmc_project.Configuration.BIOS
```

```
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper GetSubTree sias /xyz/openbmc_project/ 0 1 xyz.openbmc_project.Configuration.BIOS
a{sa{sas}} 1 "/xyz/openbmc_project/inventory/system/board/chassis/HostSPIFlash" 1 "xyz.openbmc_project.EntityManager" 1 "xyz.openbmc_project.Configuration.BIOS"
```

References:

[1] https://gerrit.openbmc.org/c/openbmc/phosphor-bmc-code-mgmt/+/74893/comment/8c7c7e83_20f92624/

Change-Id: Iea6211aebd01c4b777b13dc02120be92c347824a
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

common: allow update to Version interface

Change 'setVersion' to change the 'Version' property on
xyz.openbmc_project.Software.Version

Tested: 'Version' property is updated an error is no longer pr

common: allow update to Version interface

Change 'setVersion' to change the 'Version' property on
xyz.openbmc_project.Software.Version

Tested: 'Version' property is updated an error is no longer printed.

Change-Id: I684b9feb5465239aae5cfae846179782d579678c
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...