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 ...

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

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 ...

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::getSystemNa

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 ...

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

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 ...

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

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 ...

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 User

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 ...

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 prog

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 ...

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

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 ...

PEL: Print list of PELs

PelTool commands for printing a list of PELs.

PEL list sample:

{
"0x50000004": {
"SRC": "BD8D1001",

PEL: Print list of PELs

PelTool commands for printing a list of PELs.

PEL list sample:

{
"0x50000004": {
"SRC": "BD8D1001",
"PLID": "0x50000004",
"CreatorID": "BMC",
"Subsystem": "bmc_firmware",
"Commit Time": "10/24/2019 15:50:08",
"Sev": "unrecoverable",
"CompID": "0x1000"
}

}

Change-Id: Ifd864a6561c09de098689195edcf107b3fe550e3
Signed-off-by: Aatir <aatrapps@gmail.com>

show more ...

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 i

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 ...

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 <spin

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 ...

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,
wh

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 ...

PEL: Const accessors for Private/UserHeader

Change the combined non-const accessor/setter functions for the
PrivateHeader and UserHeader fields to the standard const accessors, and
h

PEL: Const accessors for Private/UserHeader

Change the combined non-const accessor/setter functions for the
PrivateHeader and UserHeader fields to the standard const accessors, and
have separate setters for the fields that need to be modified.

In addition, make the 'get PrivateHeader' and 'get UserHeader' functions
on the PEL class return a const reference.

This allows const enforcement on the PEL class, for things like:

void func(const PEL& pel)
{
auto id = pel.privateHeader().id();
}

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

show more ...

PEL: Create UserHeader from parameters

Add a constructor to the UserHeader section class so it can be built
from the message registry entry for that error along with the event log
se

PEL: Create UserHeader from parameters

Add a constructor to the UserHeader section class so it can be built
from the message registry entry for that error along with the event log
severity.

This will be used when creating PELs from OpenBMC event logs.

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

show more ...

PEL: Move PEL section IDs into a header file

These will eventually need to be known to a piece of code that
unflattens a PEL into the appropriate section class objects based on the
s

PEL: Move PEL section IDs into a header file

These will eventually need to be known to a piece of code that
unflattens a PEL into the appropriate section class objects based on the
section ID field in the PEL data.

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

show more ...

PEL: Add a flatten() to Section base class

To prepare for supporting PEL sections that can be in any order,
which will probably be stored in a std::vector<unique_ptr<Section>>,
add a

PEL: Add a flatten() to Section base class

To prepare for supporting PEL sections that can be in any order,
which will probably be stored in a std::vector<unique_ptr<Section>>,
add a pure virtual function in the Section base class so this list
of sections can just be iterated on and have every object in it
flattened.

This flatten() call replaces the operator<<(Stream&, <object>)
functions currently in use, so also convert the operator>> to
unflatten() to make things consistent.

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

show more ...

PEL: Add UserHeader class

The second section in a PEL is always the 'User Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is

PEL: Add UserHeader class

The second section in a PEL is always the 'User Header' section. This
commit adds a class to represent that. Right now, the only constructor
available is filling in its data fields from a PEL stream.

Several of the fields in this section have predefined values that are
defined by the PEL specification. Defining any constants or enums for
those will be left to future commits where they will actually be used.

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

show more ...