clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

Change-Id: Iac96affe709a51dd865117d006cb033cf5c624b1
Signed-off-by: Patrick Williams <p

clang-format: update latest spec and reformat

Copy the latest format file from the docs repository and apply.

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

show more ...

openpower-pels: Fix libguard initialization

The initialization of libguard was being skipped because the device tree
was not set up during the initial phosphor-logging phase. As a result,
all guard

openpower-pels: Fix libguard initialization

The initialization of libguard was being skipped because the device tree
was not set up during the initial phosphor-logging phase. As a result,
all guard library calls failed, preventing the creation of system guards
in the event of an error.

To address this, the libguard initialization has been moved to the point
where guard creation occurs. Since libguard initialization is
lightweight, this change has no noticeable impact on performance.

The fix has been tested, and guards are now correctly created as
expected.

```
root@p10bmc:~# putscom pu.c 20018600 8000000000000000 -n0 -p0 -cft
pu.c k0:n0:s0:p00:c0
/usr/bin/edbg putscom pu.c 20018600 8000000000000000 -n0 -p0 -cft

root@p10bmc:~# guard -l
ID | ERROR | Type | Path
0x00000001 | 0x50000a78 | unrecoverable | physical:sys-0/node-0/proc-0/eq-0/fc-0/core-0
```
Change-Id: I8c718be4638743dc1015d0f4f327a4f65c9d9c2d
Signed-off-by: deepakalak <deepakala.karthikeyan@ibm.com>

show more ...

openpower-pels: Create guard using libguard

Replace CreateWithEntityPath D-Bus method with guard library calls for
creating guard entries, as CreateWithEntityPath is not an approved dbus
method.

Te

openpower-pels: Create guard using libguard

Replace CreateWithEntityPath D-Bus method with guard library calls for
creating guard entries, as CreateWithEntityPath is not an approved dbus
method.

Tested and the guard record is created with the corresponding PEL id

```
before injecting the error
root@p10bmc:~# guard -l
No unresolved records to display

After injecting error, the guard is created using the PEL ID
root@p10bmc:~# guard -l
ID | ERROR | Type | Path
0x00000001 | 0x5000592b | unrecoverable | physical:sys-0/node-0/proc-0/eq-1/fc-0/core-0
root@p10bmc:~# peltool -l
{
"0x5000592B": {
"SRC": "BD13E510",
"Message": "Error Signature: 0x20DA0020 0x00000001 0x4D740407",
"PLID": "0x5000592B",
"CreatorID": "BMC",
"Subsystem": "Processor Unit (CPU)",
"Commit Time": "10/17/2024 09:54:22",
"Sev": "Unrecoverable Error",
"CompID": "bmc hw diags"
}
}
```

Change-Id: I7531bce403206beaa119aea0a621e6b47d28ffd0
Signed-off-by: deepakala-k <deepakala.karthikeyan@ibm.com>

show more ...

PEL: Remove dump status bits from PELs

Stop filling in the bits in the PEL that say there are un-offloaded
dumps. These require calls to the dump daemon that can be slow and even
time out if the du

PEL: Remove dump status bits from PELs

Stop filling in the bits in the PEL that say there are un-offloaded
dumps. These require calls to the dump daemon that can be slow and even
time out if the dump daemon is busy.

These aren't parsed out in the peltool output anyway, and there are
other ways to determine if there are dumps - someone could just look at
the dump D-Bus directly.

This isn't a direct revert of the commit that introduced it because of
all the merge conflicts trying to do a revert entailed.

Tested:
Can still create PELs.

Change-Id: I975f06ebf3638b39315fdea49393d1941a6f5216
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

PEL: Prevent deletion if it's associated with HWIsolation

- This ensures that PELs linked to HWIsolation records are protected
from accidental deletion.
- Shows error message of "Call failed: The se

PEL: Prevent deletion if it's associated with HWIsolation

- This ensures that PELs linked to HWIsolation records are protected
from accidental deletion.
- Shows error message of "Call failed: The service is temporarily
unavailable.", when attempting to delete such a PEL individually.
- If trying to Delete all, will skip such PELs without showing any
message.

Tested:
Sample output:
```bash
$ busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/
logging xyz.openbmc_project.Collection.DeleteAll DeleteAll

$ busctl call xyz.openbmc_project.Logging /xyz/openbmc_project/
logging/entry/2 xyz.openbmc_project.Object.Delete Delete
Call failed: The service is temporarily unavailable.

```
Change-Id: I2d28de91bbb0fbc2a991e3d5e5631814d41fe044
Signed-off-by: Harsh Agarwal <Harsh.Agarwal@ibm.com>

show more ...

PEL: DRAM Fix: Reset JobRemoved signal watcher

It is observed in journal traces that that the phosphor-log-manager is
receiving error trace as 'Failed to unsubscribe from JobRemoved
systemd signal'

PEL: DRAM Fix: Reset JobRemoved signal watcher

It is observed in journal traces that that the phosphor-log-manager is
receiving error trace as 'Failed to unsubscribe from JobRemoved
systemd signal' during host factory reset

Root cause:
- It is observed that the systemd service
`openpower-update-bios-attr-table.service` is starting again during
host factory reset which is responsible for the PNOR symlink creation
and update.
- In the existing code `JobRemoved` signal is subscribed for
`openpower-update-bios-attr-table.service`
- In systemd signal , if at least one client is subscribed for a
signal, most of the signals will sent out to the clients even if the
current client unsubscribed.
- Since many other service including phosphor-state-manager is also
subscribed for the signal and is not unsubscribed. Hence
Phosphor-logging is getting `JobRemoved` again even if it is
unsubscribed after PHAL initialization.

Fix proposed:
- The issue is fixed by resetting the JobRemoved signal watcher

Other changes as part of this commit:
- Removing an unwanted comma in 2 lg2 traces in the file
`data_interface.cpp`
- The PHAL initialization point is changed so that `Unsubscribe`
method will invoke after PHAL initialization.

Tested:

Tested the approach and verified that no further JobRemoved signals
are receiving by monitoring journal traces.

```
systemd[1]: Starting Update BIOS attr table with host firmware
well-known names...
systemd[1]: openpower-update-bios-attr-table.service:
Deactivated successfully.
systemd[1]: Finished Update BIOS attr table with host firmware
well-known names.
pldmd[1104]: BIOS attribute 'hb_lid_ids' updated to value
systemd[1]: Starting OpenPOWER Host HardwareIsolation...
systemd[1]: Started OpenPOWER Host HardwareIsolation.
```

Change-Id: Ib273397c7303a0473ca12e3879d154a39138de02
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...

PEL: DRAM: Fixing the missed comma in lg2 trace

Root Cause: In commit afba316, two traces in the lg2 logging missed a
comma, leading to a compilation error.

Solution: The lg2 traces have been corre

PEL: DRAM: Fixing the missed comma in lg2 trace

Root Cause: In commit afba316, two traces in the lg2 logging missed a
comma, leading to a compilation error.

Solution: The lg2 traces have been corrected by adding the missing
comma. Additionally, the systemd signal subscription and
unsubscription logic has been moved outside of the PEL_ENABLE_PHAL
flag, as it is not dependent on PHAL.

Change-Id: Ib8b17af95be356c6649c7804e4e46704498f3f3d
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...

PEL: DRAM: Remove the Debug Section for PHAL Errors

In commit 8ae618, when the system attempts to call out FRUs, PEL is
designed to include DRAM manufacturer details if the FRU being
identified is a

PEL: DRAM: Remove the Debug Section for PHAL Errors

In commit 8ae618, when the system attempts to call out FRUs, PEL is
designed to include DRAM manufacturer details if the FRU being
identified is a DIMM. The FRU type is determined using the PHAL API
"getFRUType", and if this fails, the corresponding PHAL error message
is added to the PEL debug section to aid in debugging.

However, there are cases where some FRUs, such as Planar, Fan, Power
Supply, etc., are not represented in the PHAL device tree. The PHAL
device tree primarily serves CEC (Central Electronic Complex)
hardware, which is crucial for booting the host processor. For these
unmodeled FRUs, PHAL returns 'Location code not found,' which is then
recorded in the PEL debug section.

Since these failures are expected, the PHAL error messages should be
removed from the PEL debug section to prevent confusion, as errors for
non-modeled FRUs in the PHAL device tree are expected.

The downside is that this removal could reduce debuggability for real
errors, such as a valid location code not being found or the need for
updates to the PHAL predefined FRU list. The expectation is that the
PHAL API "getFRUType" should have sufficient trace information for
debugging such issues. The phosphor-logging is not designed to capture
traces for PHAL error scenarios because of the limitations with the
PHAL device tree mentioned above.

Signed-off-by: Arya K Padman <aryakpadman@gmail.com>
Change-Id: I9a0011252667173f9e5f6aecbab2e7cd76174afa

show more ...

PEL: Init PHAL once the PNOR partition symlink is setup

As part of commit 8ae618, PHAL initialization was moved to pelstartup
to avoid multiple initialization calls. However, this change caused an
i

PEL: Init PHAL once the PNOR partition symlink is setup

As part of commit 8ae618, PHAL initialization was moved to pelstartup
to avoid multiple initialization calls. However, this change caused an
issue where the phosphor-logging service was pointing to the default
PHAL device tree, which lacks necessary attributes.

Root cause:
At the time the phosphor-logging service starts, the PNOR partition
symlink (which should point to the correct PHAL device tree) is not
yet created. This absence causes phosphor-logging service map to the
default device tree. The underlying issue is that the
openpower-update-bios-attr-table service, responsible for creating all
symlinks, starts after phosphor-logging due to a dependency on
phosphor-logging from a dependent service of
openpower-update-bios-attr-table service..

Proposed solution:
The phosphor-logging service will now subscribe to the 'JobRemoved'
DBUS signal from systemd service after the successful execution of
openpower--update-bios-attr-table service. Upon receiving this signal,
phosphor-logging will init PHAL, ensuring that PHAL initialization
occurs only after all symlinks have been set up.

Tested :

Before fix, journal traces has the error from dtb file open as below:
```
p10b systemd[1]: Starting OpenPower Software Update Manager...
p10b systemd[1]: Starting Phosphor Log Manager...
p10b systemd[1]: Started OpenPower Software Update Manager.
p10b systemd[1]: Started Phosphor Log Manager.
p10b phosphor-log-manager[409]: Unable to open dtb file
'/var/lib/phosphor-software-manager/pnor/rw/DEVTREE'
p10b systemd[1]: Starting Update BIOS attr table with host
firmware well-known names...
```

After fix, system is starting able to start the services without dtb
file open error.
```
p10b systemd[1]: Starting Phosphor Log Manager...
p10b phosphor-log-manager[408]: The send PELs to host setting changed
to False
p10b systemd[1]: Started Phosphor Log Manager.
p10b systemd[1]: Starting Set POWER host firmware well-known names...
p10b systemd[1]: openpower-process-host-firmware.service: Deactivated
successfully.
p10b systemd[1]: Finished Set POWER host firmware well-known names.
p10b systemd[1]: Starting Update BIOS attr table with host firmware
well-known names...
p10b systemd[1]: openpower-update-bios-attr-table.service: Deactivated
successfully.
p10b systemd[1]: Finished Update BIOS attr table with host firmware
well-known names.
```

Change-Id: I96b06581ebbc9afd6f8020f3540ed71bf06e5c19
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...

PEL: Add the DRAM manufacturer info of DIMM callout in UD section

Add the called out DIMMs DRAM manufacturer info to the user data
section of the PEL to assist the service engineers in identifying t

PEL: Add the DRAM manufacturer info of DIMM callout in UD section

Add the called out DIMMs DRAM manufacturer info to the user data
section of the PEL to assist the service engineers in identifying the
manufacturer of the faulty DRAMs packaged within the DIMM module
directly from the logs, aiding in quick resolution.

The changes also moves the pdbg target and libekb initialization to
the PEL startup which avoids the need of multiple initialization as
the existing design.

When a PEL calls out a DIMM FRU, the DRAM manufacturer ID and the
expanded location code of those DIMMs are added to the SysInfo user
data section of the generated PEL in JSON format under the key 'DIMMs
Additional Info'.

In case of any errors occur during the collection or processing of
the manufacturer data, the error messages will be logged in the 'PEL
Internal Debug Data' section as a JSON array under the key 'DIMMs Info
Fetch Error' as a separate user data section.

Tested :

Below is a portion of PEL(callout section and User Data section are
shown) which callout the DIMM P0-C32.

```
"Hex Word 9": "00000000",
"Callout Section": {
"Callout Count": "1",
"Callouts": [{
"FRU Type": "Normal Hardware FRU",
"Priority": "Mandatory, replace all with this
type as a unit",
"Location Code": "UXXX.YYY.WWW004A-P0-C32",
"Part Number": "7777777",
"CCIN": "1234",
"Serial Number": "YYYYYY"
}]
}
```
"User Data": {
"Section Version": "1",
"Sub-section type": "1",
"Created by": "bmc error logging",
"BMCLoad": "0.65 0.69 0.64",
"BMCState": "Ready",
"BMCUptime": "0y 0d 0h 17m 43s",
"BootState": "Unspecified",
"ChassisState": "Off",
"DIMMs Additional Info": [
{
"DRAM Manufacturer ID": [
"0x88",
"0xAA"
]
"Location Code": "UXXX.YYY.WWW004A-P0-C32",
}
],
"FW Version ID": "fw1060.20-4-1060.2432.20240729a (NL1060_068)",
"HostState": "Off",
"System IM": "50001001"
}
```

Change-Id: I2ff81c66e63b99e8e84378ec78f586fb9b6322d7
Signed-off-by: Arya K Padman <aryakpadman@gmail.com>

show more ...

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

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

show more ...

PEL: Use new Compatible interface

Code previously looked at an IBMCompatible interface provided by
entity-manager to get the system type in order to find the device
callouts file when necessary.

EM

PEL: Use new Compatible interface

Code previously looked at an IBMCompatible interface provided by
entity-manager to get the system type in order to find the device
callouts file when necessary.

EM now also puts the xyz.openbmc_project.Inventory.Decorator.Compatible
on D-Bus with the same Names property.

Change the code to use this new interface so it isn't using an IBM
specific one.

Tested:
With the dev_callouts file renamed in /usr/share:
```
/usr/share/phosphor-logging/pels# ls *Rainier2U*
com.ibm.Hardware.Chassis.Model.Rainier2U_dev_callouts.json
```

and with entity-manager hosting the new interface:

```
busctl get-property xyz.openbmc_project.EntityManager
/xyz/openbmc_project/inventory/system/chassis/Rainier_2U_Chassis \
xyz.openbmc_project.Inventory.Decorator.Compatible Names \
as 2
"com.ibm.Hardware.Chassis.Model.Rainier2U"
"com.ibm.Hardware.Chassis.Model.Rainier"
```

Creating a PEL with a device path callout:
```
CALLOUT_DEVICE_PATH /sys/bus/i2c/devices/7-0052
```

Leads to PEL callouts of:
```
"Callout Section": {
"Callout Count": "3",
"Callouts": [{
"FRU Type": "Normal Hardware FRU",
"Priority": "Mandatory, replace all with this type as a unit",
"Location Code": "U78DA.ND0.1234567-P0-C5",
"Part Number": "F191014",
"CCIN": "6B58",
"Serial Number": "YL6B58010000"
}, {
"FRU Type": "Normal Hardware FRU",
"Priority": "Mandatory, replace all with this type as a unit",
"Location Code": "U78DA.ND0.1234567-P0-T10",
"Part Number": "F191014",
"CCIN": "2E2D",
"Serial Number": "YL2E2D010000"
}, {
"FRU Type": "Normal Hardware FRU",
"Priority": "Lowest priority replacement",
"Location Code": "U78DA.ND0.1234567-P0",
"Part Number": "F191014",
"CCIN": "2E2D",
"Serial Number": "YL2E2D010000"
}]
}
```

which matches what's in the file.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I42b71ba184c9526ec3d29360b062c2a335dca343

show more ...

PEL: Removed unused constants in DataInterface

clangd flagged some unused constants and includes.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I82affc530f6ec5601053e9682c01e91ab86079

PEL: Removed unused constants in DataInterface

clangd flagged some unused constants and includes.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I82affc530f6ec5601053e9682c01e91ab8607990

show more ...

PEL: Use 'Notify' when setting Functional prop

Use phosphor-inventory-manager's Notify method when setting the
Functional property based on PEL callouts.

Using the method will have PIM persist the

PEL: Use 'Notify' when setting Functional prop

Use phosphor-inventory-manager's Notify method when setting the
Functional property based on PEL callouts.

Using the method will have PIM persist the functional value so it isn't
lost after a reboot, unlike a regular property set call.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If94f788a91fa4668b1297e2d265beb72318d4666

show more ...

Remove SDBUSPP_REMOVE_DEPRECATED_NAMESPACE

Fix the code to support new sdbusplus error without
SDBUSPP_REMOVE_DEPRECATED_NAMESPACE.

Change-Id: I12713ec1757d3835e1acf07c7abf409ff97615e1
Signed-off-b

Remove SDBUSPP_REMOVE_DEPRECATED_NAMESPACE

Fix the code to support new sdbusplus error without
SDBUSPP_REMOVE_DEPRECATED_NAMESPACE.

Change-Id: I12713ec1757d3835e1acf07c7abf409ff97615e1
Signed-off-by: Willy Tu <wltu@google.com>

show more ...

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

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

show more ...

PEL: switch fmt::format to use std::format

fmt::format is supported in the c++ std. This will
help to remove fmt package dependency.

Change-Id: I89f0a5b67bbfe54168a20e93c989a1ae87f54503
Signed-

PEL: switch fmt::format to use std::format

fmt::format is supported in the c++ std. This will
help to remove fmt package dependency.

Change-Id: I89f0a5b67bbfe54168a20e93c989a1ae87f54503
Signed-off-by: Jayanth Othayoth <ojayanth@in.ibm.com>

show more ...

PEL: Ignore hotplugged FRUs owned by PLDM

When the code is watching for newly plugged fans or power supplies, it
can ignore ones hosted by the PLDM daemon because those are in IO
expansion drawers a

PEL: Ignore hotplugged FRUs owned by PLDM

When the code is watching for newly plugged fans or power supplies, it
can ignore ones hosted by the PLDM daemon because those are in IO
expansion drawers and nothing needs to be done when those are added.

In fact, calling into PLDM to get the location code can cause a D-Bus
deadlock because when this code runs it can be in the middle of PLDM
calling into the logging daemon to create event logs.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0ebb4811a2d115692acfa3301aa53e6d19e635de

show more ...

PEL: Use lg2 in DataInterface files

Modernize it a bit and it makes it easier to see debug traces which can
be done by just running the daemon from the command line.

Signed-off-by: Matt Spinler <sp

PEL: Use lg2 in DataInterface files

Modernize it a bit and it makes it easier to see debug traces which can
be done by just running the daemon from the command line.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ic0416222e29be0c6687b6d31cb6ca4feae2ad619

show more ...

PEL: Trace less when watching Present changes

The fans and power supplies in IO expansion drawers are also in the
inventory, hosted by PLDM, and have their Present property set to true
at least once

PEL: Trace less when watching Present changes

The fans and power supplies in IO expansion drawers are also in the
inventory, hosted by PLDM, and have their Present property set to true
at least once every boot after the hypervisor starts and tells PLDM
they are present. This causes multiple traces every boot from the PEL
code watching for fan and power supply hot plugs. Also, one of the
times the items become present, the call to get its location code from
PLDM fails which causes another trace.

Since the PEL code doesn't care about fans and PSs in IO drawers, just
change these traces to debug ones so that no traces show up on normal
boots. There will still be a trace if the code does end up clearing the
deconfig flag from a PEL with a plugged local fan/PS as a callout.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I18cf95e6adfc6aa5700fe33a74c18014b36d0b9d

show more ...

PEL: Watch for fan/PS hotplugs

Code is going to need to know when a fan or power supply (the only
hotpluggable redundant FRUs) are added or replaced so that it can clear
a flag in PELs that have tha

PEL: Watch for fan/PS hotplugs

Code is going to need to know when a fan or power supply (the only
hotpluggable redundant FRUs) are added or replaced so that it can clear
a flag in PELs that have that HW as a callout. This is so other code
that is doing degraded mode notifications will not do any notifications
for PELs calling out HW that has been replaced.

To enable this functionality, add support to the DataInterface class to
tell subscribers via a function callback when a fan or power supply
becomes present, as indicated by the Present property.

Code will watch the Present property of fan and power supplies to change
via the PropertiesChanged signal, as well as watch for InterfacesAdded
to catch when they show up on D-Bus in the first place.

It won't start any of these watches until the BMC gets to ready state so
that the inventory has a chance to be populated first.

On the first boot when the inventory was previously empty there will be
a round of inventory InterfacesAdded signals that will wake up the
daemon when PLDM receives the processor core presence information from
hostboot, but it just checks and sees it's the wrong interface and
returns, and I'm not sure how it can be avoided.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I93d0727c3082677826db4a4a02c1a30986f6099b

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

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

show more ...

PEL: remove OSStart as indication host is running

This logic is checking whether PHYP is at standby or runtime. The
OSStart was never implemented by PHYP so it should not be looked at to
determine t

PEL: remove OSStart as indication host is running

This logic is checking whether PHYP is at standby or runtime. The
OSStart was never implemented by PHYP so it should not be looked at to
determine this state. The hostboot team is going to utilize this
BootProgress to indicate when they are starting PHYP.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I580703f739be9fe04f49ae00eb51f485e554287f

show more ...

PEL: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may ha

PEL: Handle multiple inv paths per loc code

DataInterface::getInventoryFromLocCode() was only returning a single
inventory path from GetFRUsByExpandedLocationCode() even though multiple
paths may have been returned.

Mostly that was fine, except when a processor on a DCM was called out.
That would lead to only one processor on the DCM being set to not
functional by service_indicators.cpp, so on the web UI the actual CPU
called out may not have been marked as unhealthy (health status critical
in Redfish).

This commit changes getInventoryFromLocCode() to return all the paths
that GetFRUsByExpandedLocationCode() returns, and then makes the
corresponding changes in service_indicators.cpp to be able to handle
multiple inventory paths per location code when setting them to not
functional and creating a critical association.

The other code that was calling this function can just use the first
path returned, since in those cases it's just needed to get the VPD
information for the PEL, and all the paths would return the same info
anyway since they had the same location code.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia16f50881e4a4f84c171ae20b7a99eddcc98ad4f

show more ...

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to

PEL: Add boot progress code to SRC hex data

Add the first 8 characters from the ASCII string field of the current
progress SRC, taken from the xyz.openbmc_project.State.Boot.Raw D-Bus
interface, to SRC hex word 4 when creating a PEL.

This is how the field is defined in the PEL spec, and is to help with
debug so that one can know which part of the boot was occurring when
the PEL was created. Note that at this point most progress codes are
sent down from one of the host firmware subsystems and not created by
the BMC.

The field is only inserted into the SRC if those characters are present
and represent a valid 4 byte number, such as "C7004000". This is then
represented as 0xC7004000 in the SRC word. Otherwise, the word is left
at a value of zero.

For example:
...
"Valid Word Count": "0x09",
"Reference Code": "BD8D1001",
"Hex Word 2": "00080455",
"Hex Word 3": "2E2D0010",
"Hex Word 4": "C7004000", <---Progress code
"Hex Word 5": "00000000",
"Hex Word 6": "00000005",
"Hex Word 7": "00000000",
"Hex Word 8": "00000000",
"Hex Word 9": "00000000"
...

Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Iba41e88626c0e081e5759b994e3630ef8b12daf4

show more ...