entity-manager: fixes for logDeviceAdded/Removed

Follow-up patch to fix issues found in comments of [1].

- Use explicit type rather than 'auto' for local variable
- Setup a return variable to avoid

entity-manager: fixes for logDeviceAdded/Removed

Follow-up patch to fix issues found in comments of [1].

- Use explicit type rather than 'auto' for local variable
- Setup a return variable to avoid duplicate initial value "Unknown"
- Fix string value read to avoid uncaught exception
- Remove unused boost include
- Add unit tests

Tested: Unit tests pass.

References:
[1] https://gerrit.openbmc.org/c/openbmc/entity-manager/+/84340

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

show more ...

Remove implicit conversions

Implicit conversions are something that nlohmann library itself is a bad
default, and 3 years ago threatened to change the default. These
implicit conversions cause a nu

Remove implicit conversions

Implicit conversions are something that nlohmann library itself is a bad
default, and 3 years ago threatened to change the default. These
implicit conversions cause a number of crashes that are hard to
reproduce, because they throw an uncaught exception.

Update the code to be able to do no more implicit conversions.

Tested: Entity-manager launches and runs. Items are detected correctly
and show up on dbus. Unit tests pass.

Change-Id: Ib23159ae58f5584641427d9be7545bc25a3619af
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

Flat map all the things

In an earlier commit, entity-manager gained required dependency
on std::flat_map. This means that EM can only compile with gcc-15,
which the project only recently moved to.

Flat map all the things

In an earlier commit, entity-manager gained required dependency
on std::flat_map. This means that EM can only compile with gcc-15,
which the project only recently moved to. Rather than move backwards,
port forward all uses of boost flat_map and flat_set to their std
equivalents.

Tested: entity-manager launches and enumerates devices on
gb200-obmc.

Change-Id: Id24803057711c60d5b00f436db80b27edbb756a3
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

fix: test: gpio presence: state

Fix compilation errors introduced in [1] which was not re-built prior to
merging. Since [1] was last built, additional test cases were introduced
in [2].

The constru

fix: test: gpio presence: state

Fix compilation errors introduced in [1] which was not re-built prior to
merging. Since [1] was last built, additional test cases were introduced
in [2].

The constructor takes a vector of parent inventory compatible, we can
just pass an empty vector for these testcases.

Sorry for any inconvenience caused.

References:
[1] 92d79814514748e0f259566ed70d5e69f5570ac7
[2] a005e3e656021be5e8291e8df86503b27942f237

Fixes: 92d79814514748e0f259566ed70d5e69f5570ac7

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

show more ...

gpio-presence: track parent inventory compatible

When detecting multiple instances of a device such as a fan module
```
{
"Exposes": [
{
"Name": "FAN1",
"PresencePinNames": [

gpio-presence: track parent inventory compatible

When detecting multiple instances of a device such as a fan module
```
{
"Exposes": [
{
"Name": "FAN1",
"PresencePinNames": [
"FAN1_PRSNT"
],
"PresencePinValues": [
1
],
"Type": "GPIODeviceDetect"
},
{
"Name": "FAN2",
"PresencePinNames": [
"FAN2_PRSNT"
],
"PresencePinValues": [
1
],
"Type": "GPIODeviceDetect"
}
],
"Name": "Minerva Fan Board 6",
"Probe": [
"xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME': 'Minerva Fan Board.*', 'PRODUCT_MANUFACTURER': 'Quanta', 'BUS': 21, 'BOARD_INFO_AM4': 'pwr-silergy'})",
"OR",
"xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME': 'Minerva Fan Board DVT', 'PRODUCT_MANUFACTURER': 'Quanta', 'BUS': 21, 'BOARD_PART_NUMBER': '3XF0MFB0030'})"
],
"Type": "Board",
"xyz.openbmc_project.Inventory.Decorator.Asset": {
"BuildDate": "$BOARD_MANUFACTURE_DATE",
"Manufacturer": "$BOARD_MANUFACTURER",
"Model": "$BOARD_PRODUCT_NAME",
"PartNumber": "$BOARD_PART_NUMBER",
"SerialNumber": "$BOARD_SERIAL_NUMBER",
"SparePartNumber": "$BOARD_INFO_AM1"
},
"xyz.openbmc_project.Inventory.Decorator.AssetTag": {
"AssetTag": "$PRODUCT_ASSET_TAG"
},
"xyz.openbmc_project.Inventory.Decorator.Compatible": {
"Names": [
"com.meta.Hardware.Minerva.FanBoard"
]
}
}
```

we want to use a single configuration file for that FRU to avoid
duplication.

```
{
"Exposes": [],
"Name": "$Name",
"Probe": [
"xyz.openbmc_project.Inventory.Source.DevicePresence({'Name': 'FAN*'})"
],
"Type": "Board",
"xyz.openbmc_project.Inventory.Decorator.Asset": {
"Manufacturer": "Unknown",
"Model": "Unknown",
"PartNumber": "Unknown",
"SerialNumber": "Unknown",
"SparePartNumber": "05-100051"
}
}
```

That creates the requirement to have `Name` property to be something
which can show up for example in the fan (or whichever) inventory.

This requirement conflicts with the requirement for `Probe` statements
to be unique and not trigger any unintended probing of unrelated
configurations.

Since `FAN 2` is a good name to use in context of a single system, but
not sufficiently unique to probe a configuration.

This patch populates a `Compatible` field on the
`xyz.openbmc_project.Inventory.Source.DevicePresence` interface which
allows to rewrite above `Probe` statement as:

```
"xyz.openbmc_project.Inventory.Source.DevicePresence({'Name': 'FAN*', 'Compatible': 'com.meta.Hardware.Minerva*'})"
```

which will be unique and not probe accidentally on other systems.

The PDI change is [4].

The value for `Compatible` field is taken from the parent inventory item
object path, which can have an optional
"xyz.openbmc_project.Inventory.Decorator.Compatible" configured.

From my perspective, entity-manager does not currently support probing
on properties which have an array type [3], so we simply take the first
value if there are multiple compatible strings on the decorator.

In case there is no such decorator, the `Compatible` string will be
empty.

Alternatives considered:

- configuring a `Compatible` property on `GPIODeviceDetect` schema.

This creates configuration bloat as all such instances are already
identified by `Name` in context of a single system.

- expanding `Probe` statement to also probe on the baseboard.

This is undesirable as currently `Probe` statement is kind of broken
[2], does not support nested expressions and also does not handle
boolean operator precedence correctly.

Tested:

Unit Tests have been adjusted.

On Tyan S8030 added following example record for some gpio.

```
{
"Name": "ExampleDevice",
"PresencePinNames": [ "BMC_SPD_SEL" ],
"PresencePinValues": [ 0 ],
"Type": "GPIODeviceDetect"
},
```

compatible decorator is not set, so compatible is empty when it detects
the Example Device.

```
xyz.openbmc_project.Inventory.Source.DevicePresence interface - - -
.Compatible property s "" emits-change writable
.Name property s "ExampleDevice" emits-change writable
```

Adding following compatible decorator
```
"xyz.openbmc_project.Inventory.Decorator.Compatible": {
"Names": [
"com.tyan.Hardware.Mainboard.S8030",
"com.tyan.Hardware.Mainboard.S8030GM"
]
}
```

And the daemon picks it up
```
Aug 22 14:43:35 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: found configuration interface at xyz.openbmc_project.EntityManager /xyz/openbmc_project/inventory/system/board/Tyan_S8030_Baseboard/ExampleDevice xyz.openbmc_project.Configuration.GPIODeviceDetect
Aug 22 14:43:35 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: Found 'Compatible' decorator on parent inventory path of /xyz/openbmc_project/inventory/system/board/Tyan_S8030_Baseboard/ExampleDevice
Aug 22 14:43:35 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: adding configuration for /xyz/openbmc_project/inventory/system/board/Tyan_S8030_Baseboard/ExampleDevice
Aug 22 14:43:36 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: found valid configuration at object path /xyz/openbmc_project/inventory/system/board/Tyan_S8030_Baseboard/ExampleDevice
Aug 22 14:43:36 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: Watching gpio events for BMC_SPD_SEL
Aug 22 14:43:36 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: GPIO line BMC_SPD_SEL went low
Aug 22 14:43:36 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: Updating dbus interface for config ExampleDevice
Aug 22 14:43:36 s8030-bmc-30303035c0c1 gpio-presence-sensor[7336]: Detected ExampleDevice as present, adding dbus interface
```

Then the Compatible string is exposed as expected
```
xyz.openbmc_project.Inventory.Source.DevicePresence interface - - -
.Compatible property s "com.tyan.Hardware.Mainboard.S8030" emits-change writable
.Name property s "ExampleDevice" emits-change writable
```

References:
[1] https://gerrit.openbmc.org/c/openbmc/entity-manager/+/82819
[2] https://github.com/openbmc/entity-manager/blob/e86be7c648b6fa6e457928b4348e561b852b79bb/src/entity_manager/perform_probe.cpp#L165
[3] https://github.com/openbmc/entity-manager/blob/e86be7c648b6fa6e457928b4348e561b852b79bb/src/utils.cpp#L116
[4] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/83061

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

show more ...

gpio-presence: add test cases for GPIO comparisons

Add test cases for the DevicePresence class, where GPIO state
is cached in a map and then decisions about device presence are
made. Add coverage o

gpio-presence: add test cases for GPIO comparisons

Add test cases for the DevicePresence class, where GPIO state
is cached in a map and then decisions about device presence are
made. Add coverage of many GPIO + cache states for the determination.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I3a11c174d6a0a8b92c446dde3e0345b195a67a9c

show more ...

Allow decoding MAC addresses in some FRUs

Some motherboards store their mac address in a zlib compressed chunk at
a known location in the FRU. Decode that section, and pull the mac
address into the

Allow decoding MAC addresses in some FRUs

Some motherboards store their mac address in a zlib compressed chunk at
a known location in the FRU. Decode that section, and pull the mac
address into the appropriate field.

This requires some refactoring so that the indexing can now have the
indexes passed through the various parse functions.

To use this functionality requires the use of libxml and zlib, which are
added as new dependencies.

Change-Id: Icb5c2e46e2a08ca83b3559892169ee2b3f319b2e
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

Remove boost::to_lower_copy

Replaced with inline std::transform lambda for lowercase conversion,
removing Boost dependency.

Tested: added UT and verified all tests passed

Change-Id: Ie875e131b2e0a

Remove boost::to_lower_copy

Replaced with inline std::transform lambda for lowercase conversion,
removing Boost dependency.

Tested: added UT and verified all tests passed

Change-Id: Ie875e131b2e0a7d5ab53288928983d640a9d1c12
Signed-off-by: George Liu <liuxiwei@ieisystem.com>

show more ...

Replace boost::replace_all and boost::ireplace_all

Replaced with custom functions using std::string_view to remove Boost
dependency and reduce template instantiation, keeping original
behavior.

Tes

Replace boost::replace_all and boost::ireplace_all

Replaced with custom functions using std::string_view to remove Boost
dependency and reduce template instantiation, keeping original
behavior.

Tested: added UT and verified all tests passed

Change-Id: I82cc238c800c7780dc50b6a40445657931bf5250
Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

Remove boost::split

Replaced boost::split with a simple std::string_view-based split to
reduce Boost dependency and template instantiation during compilation

Tested: added UT and verified all tests

Remove boost::split

Replaced boost::split with a simple std::string_view-based split to
reduce Boost dependency and template instantiation during compilation

Tested: added UT and verified all tests passed

Change-Id: Icc84794a3d5a98088bdbce032dc76055a035f0dc
Signed-off-by: George Liu <liuxiwei@ieisystem.com>

show more ...

Standardize iFindFirst

iFindFirst was added in the previous commit. Move it to using
std::ranges::subrange, withi is a direct replacement for boost, rather
than inventing a new type.

Tested: Unit

Standardize iFindFirst

iFindFirst was added in the previous commit. Move it to using
std::ranges::subrange, withi is a direct replacement for boost, rather
than inventing a new type.

Tested: Unit tests pass.
Change-Id: I6d88fc90f34ee0748b52e9fb6438635f9cdbd0a9
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...

replace boost::ifind_first with std::ranges::search

Use a custom case-insensitive search to remove Boost dependency and
reduce compilation memory usage, keeping original string replacement
behavior.

replace boost::ifind_first with std::ranges::search

Use a custom case-insensitive search to remove Boost dependency and
reduce compilation memory usage, keeping original string replacement
behavior.

Change-Id: I5778b208dfdb0082515e92f7bda335beb94c21cb
Signed-off-by: George Liu <liuxiwei@ieisystem.com>

show more ...

use phosphor-logging

Migrate all instances of std::cerr and std::cout to phosphor-logging
such as lg2::error, lg2::info, lg2::debug, ...

The use of modern logging infrastructure helps with developm

use phosphor-logging

Migrate all instances of std::cerr and std::cout to phosphor-logging
such as lg2::error, lg2::info, lg2::debug, ...

The use of modern logging infrastructure helps with development since
additional logging levels such as `debug` and `warning` are available.

Migrating the remaining logging calls helps to make the code more
readable and uniform.

Tested: Inspection, and on Tyan S8030

Restarted EM with patch applied.
Logs appear as usual.

```
Sep 15 13:52:46 s8030-bmc-30303035c0c1 entity-manager[23480]: Inventory Added: Supermicro PWS 920P SQ 0
Sep 15 13:52:46 s8030-bmc-30303035c0c1 entity-manager[23480]: Inventory Added: Supermicro PWS 920P SQ 1
Sep 15 13:52:46 s8030-bmc-30303035c0c1 entity-manager[23480]: Inventory Added: Tyan S8030 Baseboard
Sep 15 13:52:46 s8030-bmc-30303035c0c1 entity-manager[23480]: Inventory Added: MBX 1.57 Chassis
```

`busctl tree` output appears as before.

Did a power cycle to trigger a few more log prints

```
Sep 15 13:55:14 s8030-bmc-30303035c0c1 entity-manager[23480]: power match triggered
```

Created configuration file with missing fields to trigger error print.
```
{
"Exposes": [],
"Type": "error"
}
```

```
Sep 15 13:56:58 s8030-bmc-30303035c0c1 entity-manager[23659]: Finished loading json configuration in 7938ms
Sep 15 13:56:58 s8030-bmc-30303035c0c1 entity-manager[23659]: configuration file missing probe:
{"Exposes":[],"Type":"error"}
Sep 15 13:56:59 s8030-bmc-30303035c0c1 entity-manager[23659]: configuration file missing probe:
{"Exposes":[],"Type":"error"}
```

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

show more ...

Fix signed comparison warnings

Tested: unit tests pass. Unit test only change.

Change-Id: I9b105cf862b70cc788d8aea345504c7e8682eb34
Signed-off-by: Ed Tanous <etanous@nvidia.com>

fru-device: fixup fru edit commit

Adds a number of fixups to review comments and simplifications
to the flow of the previous fru-edit commit.

Tested: Edited FRU property on nvl32-obmc
```
root@nvl3

fru-device: fixup fru edit commit

Adds a number of fixups to review comments and simplifications
to the flow of the previous fru-edit commit.

Tested: Edited FRU property on nvl32-obmc
```
root@nvl32-obmc:/sys/bus/i2c/devices/4-0051# busctl introspect xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MSX4_MG1_000
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.FruDevice interface - - -
.UpdateFruField method ss b -
.ADDRESS property u 81 emits-change
.BOARD_INFO_AM1 property s "NULL" emits-change writable
.BOARD_LANGUAGE_CODE property s "0" emits-change
.BOARD_MANUFACTURER property s "Giga Computing" emits-change writable
.BOARD_MANUFACTURE_DATE property s "20250101T000800Z" emits-change
.BOARD_PART_NUMBER property s "123456789AB" emits-change writable
.BOARD_PRODUCT_NAME property s "MSX4-MG1-000" emits-change writable
.BOARD_SERIAL_NUMBER property s "S2510200007" emits-change writable
.BUS property u 4 emits-change
.CHASSIS_PART_NUMBER property s "01234567" emits-change writable
.CHASSIS_SERIAL_NUMBER property s "01234567890123456789AB" emits-change writable
.CHASSIS_TYPE property s "23" emits-change
.Common_Format_Version property s "1" emits-change
.PRODUCT_ASSET_TAG property s "01234567890" emits-change writable
.PRODUCT_LANGUAGE_CODE property s "0" emits-change
.PRODUCT_MANUFACTURER property s "Giga Computing" emits-change writable
.PRODUCT_PART_NUMBER property s "000000000001" emits-change writable
.PRODUCT_PRODUCT_NAME property s "XL44-SX2-AAS1-000" emits-change writable
.PRODUCT_SERIAL_NUMBER property s "01234567890123" emits-change writable
.PRODUCT_VERSION property s "0100" emits-change writable
root@nvl32-obmc:/sys/bus/i2c/devices/4-0051# busctl call xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MSX4_MG1_000 xyz.openbmc_project.FruDevice UpdateFruField ss "PRODUCT_ASSET_TAG" "12345678901234"
b true
root@nvl32-obmc:/sys/bus/i2c/devices/4-0051# busctl introspect xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MSX4_MG1_000
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.FruDevice interface - - -
.UpdateFruField method ss b -
.ADDRESS property u 81 emits-change
.BOARD_INFO_AM1 property s "NULL" emits-change writable
.BOARD_LANGUAGE_CODE property s "0" emits-change
.BOARD_MANUFACTURER property s "Giga Computing" emits-change writable
.BOARD_MANUFACTURE_DATE property s "20250101T000800Z" emits-change
.BOARD_PART_NUMBER property s "123456789AB" emits-change writable
.BOARD_PRODUCT_NAME property s "MSX4-MG1-000" emits-change writable
.BOARD_SERIAL_NUMBER property s "S2510200007" emits-change writable
.BUS property u 4 emits-change
.CHASSIS_PART_NUMBER property s "01234567" emits-change writable
.CHASSIS_SERIAL_NUMBER property s "01234567890123456789AB" emits-change writable
.CHASSIS_TYPE property s "23" emits-change
.Common_Format_Version property s "1" emits-change
.PRODUCT_ASSET_TAG property s "12345678901234" emits-change writable
.PRODUCT_LANGUAGE_CODE property s "0" emits-change
.PRODUCT_MANUFACTURER property s "Giga Computing" emits-change writable
.PRODUCT_PART_NUMBER property s "000000000001" emits-change writable
.PRODUCT_PRODUCT_NAME property s "XL44-SX2-AAS1-000" emits-change writable
.PRODUCT_SERIAL_NUMBER property s "01234567890123" emits-change writable
.PRODUCT_VERSION property s "0100" emits-change writable
```

Change-Id: Ic4cd7111cd4f3694faed79793e1abc98f254617b
Signed-off-by: Marc Olberding <molberding@nvidia.com>

show more ...

fru-device: Add support to dynamically add FRU fields

This patch adds the ability to dynamically add or update FRU fields
at runtime, enhancing system flexibility in managing FRU data.

Previously,

fru-device: Add support to dynamically add FRU fields

This patch adds the ability to dynamically add or update FRU fields
at runtime, enhancing system flexibility in managing FRU data.

Previously, field modification was limited to the preassigned space
available in the FRU area. Any attempt to exceed this boundary would
fail:
Example:
```busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MDA_WCU_AI xyz.openbmc_project.FruDevice CHASSIS_SERIAL_NUMBER s "1234567890123"
busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MDA_WCU_AI xyz.openbmc_project.FruDevice CHASSIS_SERIAL_NUMBER s "12345678901234"
Failed to set property CHASSIS_SERIAL_NUMBER on interface xyz.openbmc_project.FruDevice: Invalid argument
hexdump -C /sys/bus/i2c/drivers/at24/8-0051/eeprom
```
With this patch, the FRU area can extend dynamically. All FRU areas are
repacked, and the FRU common header is updated without errors:
Example:
```
busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MDA_WCU_AI xyz.openbmc_project.FruDevice CHASSIS_SERIAL_NUMBER s "1234567890123"
busctl set-property xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/MDA_WCU_AI xyz.openbmc_project.FruDevice CHASSIS_SERIAL_NUMBER s "12345678901234567890123456789"
```
Also check eeprom so that FRU areas get aligned properly.

Key changes:
- Introduced support through the `UpdateFruField` API.
- Utilizes `disassembleFruData` to parse existing FRU data into editable
fields.
- Applies field changes using `setField`, which handles updates or
additions.
- Reconstructs updated FRU binary data with `assembleFruData` before
committing it back.

TESTED=Build for Tiagopass & test on QEMU using below commands:
busctl call xyz.openbmc_project.FruDevice \
/xyz/openbmc_project/FruDevice/BMC_Storage_Module \
xyz.openbmc_project.FruDevice UpdateFruField ss \
"CHASSIS_INFO_AM10" "1234567890"

Readback:
busctl introspect xyz.openbmc_project.FruDevice \
/xyz/openbmc_project/FruDevice/BMC_Storage_Module

Change-Id: I5df2776211cb5cfd23570e479568da4717df3097
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>

show more ...

test: topology: new configurations

Add tests for the new topology schema.

New testcases:
- 2 powersupplies powering a board, PSUs and board contained by a
chassis. Similar to a Tyan S8030.
- 4 Bl

test: topology: new configurations

Add tests for the new topology schema.

New testcases:
- 2 powersupplies powering a board, PSUs and board contained by a
chassis. Similar to a Tyan S8030.
- 4 Blades, each contained by a SubChassis, all 4 SubChassis contained
by a SuperChassis. (modeled after Yv3 [1])

Tested: Topology Unit Tests Pass

References:
[1] https://www.opencompute.org/products/237/wiwynn-yosemite-v3-server

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

show more ...

entity-manager: Handle left-over template vars

With current implementations for template variable replacement, if a
variable does not exist on D-Bus, it will be left as is and will appear
in the fin

entity-manager: Handle left-over template vars

With current implementations for template variable replacement, if a
variable does not exist on D-Bus, it will be left as is and will appear
in the final configuration. However, if the string is intended to be
replaced and not handled properly after a replacement failure, the
variable itself will possibly be shown to users via Redfish/IPMI if the
consuming properties are used by those.

After performing the template variable replacement, a post-processing
step is added to check for any leftover template variables. These
leftovers may occur if the probed property is not available on D-Bus.
Any such variables are replaced with an empty string to avoid
unresolved placeholders.

The boundary of a template var is decided to be from the character "$"
to before a " " character, or the end of the keyPair's value string.
This conforms to the implicit rules currently applied to template
variable configuration that a template variable should not be
immediately followed by an arbitrary string without a space separating
them. This pattern can also be found in how the math configurations are
extracted, which looks for a math operator at the position that is one
character away from the end of the template variable [1].

The unit tests are also updated to test the new function that handles
left-over template variables.

[1]: https://github.com/openbmc/entity-manager/blob/3911d80afb6956b17c4f4b9a76c7eb45bb76e3b9/src/entity_manager/utils.cpp#L134

Tested: Unit tests pass

Tested with real configuration:

`$PRODUCT_PRODUCT_KK_NAME`, `$PRODUCT_KK_VERSION` and
`$PRODUCT_SERIAL_KK_NUMBER` are non-existent probed property on D-Bus.

```
{
"Exposes": [
...
],
"Name": "Mt.Mitchell_Motherboard",
"Probe": [
"xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME': 'MB'})",
"AND",
"FOUND('Mt.Mitchell_DCSCM_BMC')"
],
"Type": "Board",
"xyz.openbmc_project.Common.UUID": {
"UUID": "$MULTIRECORD_UUID"
},
"xyz.openbmc_project.Inventory.Decorator.Asset": {
"BuildDate": "$BOARD_MANUFACTURE_DATE",
"Manufacturer": "$PRODUCT_MANUFACTURER",
"Model": "$PRODUCT_PRODUCT_KK_NAME $PRODUCT_KK_VERSION",
"PartNumber": "$PRODUCT_PART_NUMBER",
"SerialNumber": "$PRODUCT_SERIAL_KK_NUMBER"
}
}
```

D-Bus results after the configuration is processed:

- `Model` has a space character which is the space between
`$PRODUCT_PRODUCT_KK_NAME` and `$PRODUCT_KK_VERSION` in the
configuration.

- SerialNumber is empty.

```
$ busctl introspect xyz.openbmc_project.EntityManager \
/xyz/openbmc_project/inventory/system/board/Mt_Mitchell_Motherboard

xyz.openbmc_project.Common.UUID interface - -
.UUID property s "xx-xx"
xyz.openbmc_project.Inventory.Decorator.Asset interface - -
.BuildDate property s "20221018Z"
.Manufacturer property s "NULL"
.Model property s " "
.PartNumber property s "ProductPN"
.SerialNumber property s ""

Change-Id: I4499baf3ebe9560e13932a49e324d1c8b0255623
Signed-off-by: Chau Ly <chaul@amperecomputing.com>

show more ...

topology: getAssocs param board paths view

`getAssocs` function received a parameter
```
const std::map<std::string, std::string>& boards
```
which maps object paths to board names, but only queried

topology: getAssocs param board paths view

`getAssocs` function received a parameter
```
const std::map<std::string, std::string>& boards
```
which maps object paths to board names, but only queried the object
paths. Pass an `std::view::keys` instead to minimize the API surface.

Tested: Topology Unit Tests Pass

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

show more ...

make Topology::getAssocs return association sets

Change return type:

```
-std::unordered_map<std::string, std::vector<Association>>
+std::unordered_map<std::string, std::set<Association>>
```

Reca

make Topology::getAssocs return association sets

Change return type:

```
-std::unordered_map<std::string, std::vector<Association>>
+std::unordered_map<std::string, std::set<Association>>
```

Recall
```
using Association = std::tuple<std::string, std::string, std::string>;
```

The change makes the association code more robus as adding an
association to the set multiple times is supported and cannot cause
issues later on.

Also fix the tests which assumed some ordering of the associations
returned by the function.

Tested: Topology Unit Tests pass.

There is one call site in non-test code:
```
src/entity_manager/entity_manager.cpp
91: topology.getAssocs(newBoards))
```

which only iterates the destructured map entries and creates DBus
interfaces for association definitions.

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

show more ...

fru-device: Add option to allow updating all FRU fields

This patch introduces a new meson option `fru-update-property` to enable
updating FRU properties via D-Bus. This is particularly useful during

fru-device: Add option to allow updating all FRU fields

This patch introduces a new meson option `fru-update-property` to enable
updating FRU properties via D-Bus. This is particularly useful during
lab testing to modify FRU fields as needed.

TESTED=Build for tiagopass with fru-update-property set to true.
Verify the following:
1. Run command:
`busctl introspect xyz.openbmc_project.FruDevice
/xyz/openbmc_project/FruDevice/BMC_Storage_Module`

2. Verify the FRU fields are `writable`
Example:
...
.PRODUCT_ASSET_TAG property s "XXXXXXX"
emits-change writable
.PRODUCT_FRU_VERSION_ID property s "1.0"
emits-change writable
.PRODUCT_INFO_AM1 property s "XXXXXXXXX"
emits-change writable
.PRODUCT_INFO_AM2 property s "Config A"
emits-change writable
...

3. Update FRU field:
busctl set-property xyz.openbmc_project.FruDevice
/xyz/openbmc_project/FruDevice/BMC_Storage_Module
xyz.openbmc_project.FruDevice PRODUCT_INFO_AM2 s "123"

4. Verify by reading the field:
busctl get-property xyz.openbmc_project.FruDevice
/xyz/openbmc_project/FruDevice/BMC_Storage_Module
xyz.openbmc_project.FruDevice PRODUCT_INFO_AM2
s "123"

root@tiogapass:~# hexdump /sys/bus/i2c/drivers/at24/6-0054/eeprom
0000000 0001 0100 000d f100 0c01 3600 d0e6 58c6
0000010 5858 5858 d258 4d42 2043 7453 726f 6761
0000020 2065 6f4d 7564 656c 58cd 5858 5858 5858
0000030 5858 5858 5858 58ce 5858 5858 5858 5858
0000040 5858 5858 c358 2e31 c930 5858 5858 5858
0000050 5858 d258 5858 5858 5858 5858 5858 5858
0000060 5858 5858 5858 39c1 0c01 c600 5858 5858
0000070 5858 54d2 6f69 6167 5020 7361 2073 6953
0000080 676e 656c ce32 5858 5858 5858 5858 5858
0000090 5858 5858 58c4 5858 cd32 5858 5858 5858
00000a0 5858 5858 5858 c758 5858 5858 5858 c358
00000b0 2e31 c930 5858 5858 5858 5858 c858 6f43
00000c0 666e 6769 4120 45c1 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0002000
root@tiogapass:~# busctl set-property xyz.openbmc_project.FruDevice
/xyz/openbmc_project/FruDevice/BMC_Storage_Module
xyz.openbmc_project.FruDevice PRODUCT_INFO_AM1 s "123456"
root@tiogapass:~# hexdump /sys/bus/i2c/drivers/at24/6-0054/eeprom
0000000 0001 0100 000d f100 0c01 3600 d0e6 58c6
0000010 5858 5858 d258 4d42 2043 7453 726f 6761
0000020 2065 6f4d 7564 656c 58cd 5858 5858 5858
0000030 5858 5858 5858 58ce 5858 5858 5858 5858
0000040 5858 5858 c358 2e31 c930 5858 5858 5858
0000050 5858 d258 5858 5858 5858 5858 5858 5858
0000060 5858 5858 5858 39c1 0c01 c600 5858 5858
0000070 5858 54d2 6f69 6167 5020 7361 2073 6953
0000080 676e 656c ce32 5858 5858 5858 5858 5858
0000090 5858 5858 58c4 5858 cd32 5858 5858 5858
00000a0 5858 5858 5858 c758 5858 5858 5858 c358
00000b0 2e31 c630 3231 3433 3635 43c8 6e6f 6966
00000c0 2067 c141 0000 4f00 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
*
0002000

Change-Id: Iff11d64a291e6bdb653b6c524ca90e2e16003ec3
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>

show more ...

meson: separate directory for entity-manager tests

Since entity-manager is now built with a static library, the sources do
not have to be compiled twice for testing. Link with the static library
ins

meson: separate directory for entity-manager tests

Since entity-manager is now built with a static library, the sources do
not have to be compiled twice for testing. Link with the static library
instead.

Move the test file for entity-manager into a separate directory to split
it in later patches.

Tested: Unit Tests Pass

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

show more ...

topology: Attach power assoc to downstream port

When an upstream component (e.g. a Baseboard) changes (FRU data update)
but the downstream component (e.g. a PowerSupply board) remains
unchanged, the

topology: Attach power assoc to downstream port

When an upstream component (e.g. a Baseboard) changes (FRU data update)
but the downstream component (e.g. a PowerSupply board) remains
unchanged, the topology update may fail to refresh associations because
the downstream board is not reprocessed dues to this line check [1]
which only associates the upstream entity with the downstream ones that
are in the new board list.

This commit instead attaches the powering/powered_by association to the
downstream entity. As a result:

1. If an upstream entity changes and the downstream is removed, the
association will be removed with the downstream D-Bus object.
2. If an upstream entity changes and the downstream doesn't, the
association will stay with the upstream D-Bus object (the port
topology configurations don't change after FRU updates so there's
no chance that the connection needs to be removed).
3. If a downstream entity changes, the association will be re-attached
to the downstream object.

Unit test is updated accordingly.

Tested on Mt.Jefferson:

1. Configure an upstream port in Baseboard and a downstream power port
in a PowerSupply board which connects to the mentioned upstream port.
2. Update FRU data of the Baseboard, after rescaning, the
powered_by/powering association between the 2 entities still remains.

[1]: https://github.com/openbmc/entity-manager/blob/07fdadae76000e4056afac15c24bb8e80b3c8cd8/src/entity_manager/topology.cpp#L69

Signed-off-by: Hieu Huynh <hieuh@os.amperecomputing.com>
Signed-off-by: Chau Ly <chaul@amperecomputing.com>
Change-Id: I7883ec0229a093db4a03a683baab24b176adfb7e

show more ...

meson: separate meson file for tests

Tested: Unit Tests Pass

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

Add gpio-presence-sensor

This is to implement the gpio based hw inventory design [1].

There is a new meson option 'gpio-presence' to enable/disable the
daemon.

Summary of the functionality:

- fet

Add gpio-presence-sensor

This is to implement the gpio based hw inventory design [1].

There is a new meson option 'gpio-presence' to enable/disable the
daemon.

Summary of the functionality:

- fetch configuration from EM, according to the configuration interface
- the D-Bus interface is
xyz.openbmc_project.Configuration.GPIODeviceDetect
- the configuration represents devices for which presence can be
detected based on gpio values.
- watch gpios for changes
- add/remove the xyz.openbmc_project.Inventory.Source.DevicePresence
interface on the object path based on gpio values.

References:
[1] https://github.com/openbmc/docs/blob/master/designs/inventory/gpio-based-hardware-inventory.md
[2] https://www.kernel.org/doc/html/latest/admin-guide/gpio/gpio-sim.html

Tested: using linux gpio-sim facility, see below

1. create a fake gpio via [2]
2. configure gpio-presence-sensor as per [1]
3. run the gpio-presence-sensor
4. change the value of the gpio previously configured
5. there should be log output (at debug level)
6. the dbus interfaces exposed should appear/disappear as per [1]

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

show more ...