#
075c7923 |
| 16-Aug-2024 |
Patrick Williams <patrick@stwcx.xyz> |
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 ...
|
#
5bc26533 |
| 10-Apr-2024 |
Arya K Padman <aryakpadman@gmail.com> |
PEL: Changing the remaining traces to lg2 style
Some of the logging traces of PEL files still uses old style of logging.
Changing the remaining traces in PEL files to lg2 style of logging.Some of t
PEL: Changing the remaining traces to lg2 style
Some of the logging traces of PEL files still uses old style of logging.
Changing the remaining traces in PEL files to lg2 style of logging.Some of the traces in phosphor logging code which use the old style is also considered.
Change-Id: I0daf9589af443881cb61730047c23db17fdec2c3 Signed-off-by: Arya K Padman <aryakpadman@gmail.com>
show more ...
|
#
1aa90d49 |
| 13-Sep-2023 |
Jayanth Othayoth <ojayanth@in.ibm.com> |
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 ...
|
#
b832aa5e |
| 21-Mar-2023 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Print component names in peltool
Every PEL section has a 2 byte component ID field in its header that peltool prints. Currently, it just prints the hex version, like "0x1000".
There are JSON
PEL: Print component names in peltool
Every PEL section has a 2 byte component ID field in its header that peltool prints. Currently, it just prints the hex version, like "0x1000".
There are JSON files in the flash already that contain mappings of component IDs to to component names, and this commit starts looking up the component names from those files and using those in the peltool output.
An example of a file is: /usr/share/phosphor-logging/pels/O_component_ids.json: { "1000": "bmc common function", "2000": "bmc error logging", ... }
Where the 'O' in the filename is the creator ID field of the PEL. There is also a file for hostboot, which is B_component_ids.json.
Also, for PELs with a PHYP creator ID, just convert the ID to two characters, like 0x4552 - > "ER" as that is what they are.
peltool output examples: "Created by": "bmc error logging", "Created by": "hostboot: errl", "Created by": "IO",
This matches what is already done by the python peltool.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Id616739e1b7ca67c85dc7efa85dc34acf6aca9b5
show more ...
|
#
8ac20500 |
| 04-Jan-2023 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Put validation fail details into journal msg
In the PEL section classes, move some journal fields from the journal metadata section into the journal message itself, to make debug slightly easie
PEL: Put validation fail details into journal msg
In the PEL section classes, move some journal fields from the journal metadata section into the journal message itself, to make debug slightly easier.
Specifically, this is just for when unflattening or validating the sections fail.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I6d5661015b5ce5c07ed2fd6eb7ce864d0c620092
show more ...
|
#
2544b419 |
| 04-Oct-2022 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: update with latest
Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Change-Id: I329396457b83bb2eb8740629b4ac1fbe9106bced
|
#
be952d2e |
| 01-Jul-2022 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Fix more cppcheck warnings
This is the second of two commits to fix most of the cppcheck warnings in the PEL code. It doesn't fix all of them because some are false positives and some are just
PEL: Fix more cppcheck warnings
This is the second of two commits to fix most of the cppcheck warnings in the PEL code. It doesn't fix all of them because some are false positives and some are just suggestions.
It's broken up into two commits to make them smaller.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Id9f462386df85fd25d09529d6b410115ff4ccba8
show more ...
|
#
23970b0d |
| 25-Feb-2022 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Support 'PossibleSubsystems' in msg registry
Add a 'PossibleSubsystems' field to the message registry schema where someone can list which subsystems they might pass into the PEL_SUBSYSTEM Addit
PEL: Support 'PossibleSubsystems' in msg registry
Add a 'PossibleSubsystems' field to the message registry schema where someone can list which subsystems they might pass into the PEL_SUBSYSTEM AdditionalData property field when creating a PEL.
The PossibleSubsystems value will be used by a off-BMC script that generates field documentation for SRCs, so it knows what all SRC ASCII string values are possible for that entry since the subsystem is part of them. For example, if that field was ['processor', 'memory'], then that means the possible SRCs are BD10AAAA and BD20AAAA for reason code 'AAAA'.
The Subsystem and PossibleSubsystems fields are mutually exclusive in the message registry, so code changes had to be made to support the subsystem field now being optional.
There is now a chance that even though the subsystem is supposed to be passed in using PEL_SUBSYSTEM, it isn't. In that case, the 'Other' subsystem will be used, since it seems fairly generic.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Ic8087fc46b2a192459b7287186f8972610e84730
show more ...
|
#
50bfa69a |
| 06-Jan-2022 |
Sumit Kumar <sumit_kumar@in.ibm.com> |
PEL: Pass in subsystem to use with additional data
There is a requirement to pass in the subsystem to use with the additional data field. In the process update the user header code and SRC with the
PEL: Pass in subsystem to use with additional data
There is a requirement to pass in the subsystem to use with the additional data field. In the process update the user header code and SRC with the passed-in subsystem value instead from the message registry.
Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com> Change-Id: I08c8c3bab100fec581df9043f4bb27b28cb556e1
show more ...
|
#
2fb10211 |
| 22-Aug-2021 |
Vijay Lobo <vijaylobo@gmail.com> |
PEL.Entry - Add managementSystemAck property
Add managementSystemAck property to PEL.Entry interface to support HMC acknowledgement of event receipt.
Tested: 1. Created a PEL log using busctl and s
PEL.Entry - Add managementSystemAck property
Add managementSystemAck property to PEL.Entry interface to support HMC acknowledgement of event receipt.
Tested: 1. Created a PEL log using busctl and set-property managementSystemAck to true. Verified that the flag is set by using peltool Result:(output of peltool) "Host Transmission": "Not Sent", "HMC Transmission": "Acked" Restarted phosphor-log-manager and verified that the flag is true.
2. Generated PEL using RAWPEL and verified all the steps as in 1.
Change-Id: Ifa06cca0063c6c609317192f9c18bb2524e2f292 Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>
show more ...
|
#
3b8ed7f2 |
| 18-May-2021 |
Sumit Kumar <sumit_kumar@in.ibm.com> |
PEL: Support MfgSeverity & MfgAction flags PEL reg fields
This is specifically for manufacturing mode. Look for mfgSeverity and mfgAction flags being set in incoming PELs and if it is then check for
PEL: Support MfgSeverity & MfgAction flags PEL reg fields
This is specifically for manufacturing mode. Look for mfgSeverity and mfgAction flags being set in incoming PELs and if it is then check for dbus property for QuiesceOnHwError and if it is found then override the severity value with mfg value.
Signed-off-by: Sumit Kumar <sumit_kumar@in.ibm.com> Change-Id: Icd590b0e2732df8aa9c2935078528dda8fd4f996
show more ...
|
#
6b3f345b |
| 15-Apr-2021 |
Vijay Lobo <vijaylobo@gmail.com> |
PEL: Support user supplied flag to indicate a fatal/terminating
User can supply SEVERITY_DETAIL=SYSTEM_TERM as part of AdditionalData entry in the event log to set the severity level in User Header
PEL: Support user supplied flag to indicate a fatal/terminating
User can supply SEVERITY_DETAIL=SYSTEM_TERM as part of AdditionalData entry in the event log to set the severity level in User Header of PEL
Tested: I ran unit test using docker. Also tested manually by setting D-bus event log
Change-Id: I9205c084c32576734c2b5b4c79c273f8defde9d4 Signed-off-by: Vijay Lobo <vijaylobo@gmail.com>
show more ...
|
#
1ab6696f |
| 29-Oct-2020 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Use the real system names property
There is now a 'Names' property on the new xyz.openbmc_project.Configuration.IBMCompatibleSystem interface that the DataInterface::getSystemNames function wil
PEL: Use the real system names property
There is now a 'Names' property on the new xyz.openbmc_project.Configuration.IBMCompatibleSystem interface that the DataInterface::getSystemNames function will read. The existing code was mostly a placeholder until the actual interface showed up on D-Bus.
Since the path that holds the interface is system specific, and the PEL code should only rarely need this, the code was changed to read it on demand instead of at caching it startup.
Since getSystemNames() no longer returns a cached value, the signature was changed slightly to remove the reference from the returned std::vector<std::string> value.
The UserHeader constructor used to make a call to getSystemNames every time, and that was changed to only call it when actually necessary, which is when there is a severity value defined in the message registry that depends on the system name.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I1d4f307ef38287b631f94dae2b8929307d129029
show more ...
|
#
1f93c590 |
| 10-Sep-2020 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Don't fix user specified action flags
Previously, the PEL object would never trust the action flags field specified in the PEL registry and would always set some of the flags in it itself based
PEL: Don't fix user specified action flags
Previously, the PEL object would never trust the action flags field specified in the PEL registry and would always set some of the flags in it itself based on a set of rules.
It turns out there are some cases where what the user needs doesn't match the rules, so now only fix up the action flags if they weren't specified in the registry and leave the flags alone if they were.
Most PELs in the registry should be able to leave out the action flags field and let the PEL code set them.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I80263d779c842acac042023c468b7e979ec7158c
show more ...
|
#
6ea4d5f7 |
| 20-May-2020 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Read the compatible system names property
The chassis object in the inventory has (or rather at the time of this writing: will have) a Names property that contains a list of the compatible syst
PEL: Read the compatible system names property
The chassis object in the inventory has (or rather at the time of this writing: will have) a Names property that contains a list of the compatible system types for the current system. An example is: ["company-systemA-4G", "company-systemA", "company"].
Add this to the DataInterface class, and remove the previous 'getSystemType' API that was there but was still stubbed out.
Also change all the calls from getSystemType() to the new call getSystemNames(), and check against all entries in that array to see if the desired name applies to the current system.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I86aa0c15c564153fea612f407c161dfe9041fce6
show more ...
|
#
aadccc85 |
| 10-Apr-2020 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Msg registry sev now based on sys type
The PEL severity field in the UserHeader section can now be defined in the message registry to be based on system type.
When the UserHeader object is bei
PEL: Msg registry sev now based on sys type
The PEL severity field in the UserHeader section can now be defined in the message registry to be based on system type.
When the UserHeader object is being created from the message registry, it will now query the system type and use that to find the correct severity value.
The Registry class was updated to handle the new JSON format, which is an array of system type/severity value objects.
The original severity format of a simple string is still valid.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I0fe0ada7193c57adc42e82afdc30e687eea63eb9
show more ...
|
#
bebeb948 |
| 12-Mar-2020 |
Harisuddin Mohamed Isa <harisuddin@gmail.com> |
PEL: peltool: Add const strings for section header
Added "Section Version", "Sub-section type" and "Created by" constant strings.
Updated all getJSON() functions to use the new constants.
Signed-o
PEL: peltool: Add const strings for section header
Added "Section Version", "Sub-section type" and "Created by" constant strings.
Updated all getJSON() functions to use the new constants.
Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com> Change-Id: I434192afed929972845c3cfb8876cc5ef784eec2
show more ...
|
#
455587e5 |
| 15-Jan-2020 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Print host trans state in peltool
In the UserHeader section, add an entry into peltool's JSON output for the host transmission state.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id
PEL: Print host trans state in peltool
In the UserHeader section, add an entry into peltool's JSON output for the host transmission state.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Ie906a447859e30175652d291ef2f929e8a7077f6
show more ...
|
#
600d15af |
| 19-Dec-2019 |
Harisuddin Mohamed Isa <harisuddin@gmail.com> |
PEL: Print action flags into JSON aligned
"User Header": { "Section Version": "1", "Sub-section type": "0", "Log Committed by": "0x4552", "Subsystem":
PEL: Print action flags into JSON aligned
"User Header": { "Section Version": "1", "Sub-section type": "0", "Log Committed by": "0x4552", "Subsystem": "System Hypervisor Firmware", "Event Scope": "Entire Platform", "Event Severity": "Informational Event", "Event Type": "Miscellaneous, Informational Only", "Action Flags": [ "Report Externally" ] }
Testing: Manually run peltool and verified output Signed-off-by: Harisuddin Mohamed Isa <harisuddin@gmail.com> Change-Id: Ie8376953b5f1baa093fc0aa9564d50cd4208564e
show more ...
|
#
eb111447 |
| 07-Nov-2019 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Store transmission states in UserHeader
Use a reserved word in the UserHeader section to store some PEL states:
* Host Transmission State: - States involving the progression of a PEL being s
PEL: Store transmission states in UserHeader
Use a reserved word in the UserHeader section to store some PEL states:
* Host Transmission State: - States involving the progression of a PEL being sent to the operating system.
* HMC Transmission State: - States involving the progression of a PEL being sent to the hardware management console, if there is one attached.
- Usually, an HMC refers to a specific set of hardware and software sold by IBM that connects to OpenPower systems which has specific software to deal with receiving PELs.
It is possible that there is an implementation that won't need to send PELs to either of these entities, in which case these states will just be unused and left at zero.
This is the same location that other service processor implementations have stored transmission states.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I6a2bfee15336dbd564aeaded88effa55ede0d6c4
show more ...
|
#
c1489351 |
| 09-Dec-2019 |
Aatir <aatrapps@gmail.com> |
PEL: Remove userHeader::getValue
getValue function is now being used to get field values for all the different sections. Therefore, it makes sense to remove the older implementation of this function
PEL: Remove userHeader::getValue
getValue function is now being used to get field values for all the different sections. Therefore, it makes sense to remove the older implementation of this function from userHeader class.
Change-Id: I041b8c5e0548e9f7ee354f21d2e248ed946df5ec Signed-off-by: Aatir <aatrapps@gmail.com>
show more ...
|
#
ad0e0476 |
| 07-Oct-2019 |
Aatir Manzur <aatrapps@gmail.com> |
PEL: user header in JSON
The PELTool application is able to convert sections to JSON. This commit takes care of converting the user header section to JSON.
user header section in JSON sample:
"Use
PEL: user header in JSON
The PELTool application is able to convert sections to JSON. This commit takes care of converting the user header section to JSON.
user header section in JSON sample:
"User Header":[ {"Section Version": "1"}, {"Sub-section type": "0"}, {"Log Committed by": "0x2000"}, {"Subsystem": "bmc_firmware"}, {"Event Scope": "entire_platform"}, {"Event Severity":"unrecoverable"}, {"Event Type": "na"} ]
Signed-off-by: Aatir Manzur <aatrapps@gmail.com> Change-Id: I0dca1d87019b9e62d711ee6d034f2e8bc0574c2e
show more ...
|
#
0688545b |
| 06-Nov-2019 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Make PEL::flatten() const
This includes making the flatten() method const in the PEL section base class and in all of its derived classes.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Chan
PEL: Make PEL::flatten() const
This includes making the flatten() method const in the PEL section base class and in all of its derived classes.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I6be787962c6d7dfa01bdced2f9024564e6ac1b08
show more ...
|
#
f1e85e20 |
| 01-Nov-2019 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Validate the Action Flags field
According to the PEL spec, the Action Flags and Event Type fields in the User Header section must be in agreement with the Severity field. So, when a PEL is bein
PEL: Validate the Action Flags field
According to the PEL spec, the Action Flags and Event Type fields in the User Header section must be in agreement with the Severity field. So, when a PEL is being created from an OpenBMC event log, check those values for correctness and fix them up if required.
In addition, as those fields are optional in the message registry, this code will also just set these two fields to valid values if they were left out.
The rules being followed are documented in the PEL readme.
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: Iad88de5080ba79a9ff31f962ef99bfc11994b9ed
show more ...
|
#
711d51d8 |
| 06-Nov-2019 |
Matt Spinler <spinler@us.ibm.com> |
PEL: Add license prologue to source files
Signed-off-by: Matt Spinler <spinler@us.ibm.com> Change-Id: I31b12f509d32b79064a8a427af35e6a310273051
|