Age | Commit message (Collapse) | Author | Files | Lines |
|
skiboot only supports POWER8 > DD1 now, all supported platforms
should use the new SPIRA-S/H structure.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add HDIF_idata that returns the idata pointer structure, not a
pointer to the data itself.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Like other (idata) accessors already do, check the common header in
hdata child accessor calls.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Make the HDIF header check use a common function.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Grab a SPIRA-S from a booted Rainier system and plug it in.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The nest IMC (In Memory Collection) Performance Monitoring
Unit(PMU) node names are saved as "struct nest_pmus_struct"
in the "hw/imc.c" IMC code. Not all the IMC PMUs listed in
the device tree may be available. Nest IMC PMU names along with
their bit values is represented in imc availability vector.
This struct is used to remove the unavailable nodes by checking
this vector.
For power10, the imc_chip_avl_vector ie, imc availability vector
( which is a part of the IMC control block structure ), has
change in mapping of units and bit positions. Hence rename the
existing nest_pmus array to nest_pmus_p9 and add entry for power10
as nest_pmus_p10.
Also the avl_vector has another change in bit positions 11:34. These
bit positions tells the availability of Xlink/Alink/CAPI. There
are total 8 links and three bit field combination says which link
is available. Patch implements all these change to handle
nest_pmus_p10.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The nest IMC (In Memory Collection) Performance Monitoring
Unit(PMU) node names are saved in nest_pmus[] array in the
"hw/imc.c" IMC code. Not all the IMC PMUs listed in the device
tree may be available. Nest IMC PMU names along with their
bit values is represented in imc availability vector.
The nest_pmus[] array is used to remove the unavailable nodes
by checking this vector.
To check node availability, code was using "dt_find_by_substr".
But since the node names have format like: "name@offset",
dt_find_by_name doesn't return the expected result. Fix this
by using dt_find_by_name_before_addr. Also, update the char array
to use correct node names.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add a function dt_find_by_name_before_addr() that returns the child node if
it matches till first occurrence at "@" of a given name, otherwise NULL.
This is helpful for cases with node name like: "name@addr". In
scenarios where nodes are added with "name@addr" format and if the
value of "addr" is not known, that node can't be matched with node
name or addr. Hence matching with substring as node name will return
the expected result. Patch adds dt_find_by_name_before_addr() function
and testcase for the same in core/test/run-device.c
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
[arbab: Refactor the loop to fix possible memory leak]
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The Fedora images in the Docker hub container registry are updated less
frequently and lag the ones from Fedora's offical repo.
In my experience, this often leads to periods where our CI testing is
broken on rawhide due to some short-lived issue that is already fixed in
current images.
So, change our Dockerfiles to pull specifically from the upstream
registry.fedoraproject.org instead.
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
Reviewed-by: Dan HorĂ¡k <dan@danny.cz>
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
|
|
Last BMC firmware is available with a complete PLDM support on Rainier
system.
This patch allows initially to:
- Initialize the MCTP core.
- Enable the mctp binding over LPC bus interface and new wrappers to send
and receive PLDM messages over the mctp library.
- Retrieve all needed PLDM data.
- "Virtualize" the content of a BMC flash based on lid files.
Then, others mandatory support (watchdog, opal rtc, opal ipmi) are enabled.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
backend apis to support partially:
OPAL_IPMI_SEND: send an IPMI message to the service processor
OPAL_IPMI_RECV: read an ipmi message of type ``ipmi_msg`` from ipmi message
queue ``msgq`` into host OS structure ``opal_ipmi_msg``
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
OPAL_RTC_READ/WRITE are used to retrieve and write the time. PLDM stack
provides GetBiosDateTimeReq and SetBiosDateTimeReq commands to exercise.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM Event Messages are PLDM monitoring and control messages that are used
by a PLDM terminus to synchronously or asynchronously report PLDM events
to a central party called the PLDM Event Receiver.
This patch allows to send a:
- generic sensor events (events related to PLDM numeric and state sensors).
- boot progress sensor event.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetFRURecordTable command is used to get the FRU Record Table data.
This command is defined to allow the FRU Record Table data to be
transferred using a sequence of one or more command/response messages.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetFRURecordTableMetadata command is used to get the FRU Record
Table metadata information that includes the FRU Record major version,
the FRU Record minor version, the size of the largest FRU Record data,
total length of the FRU Record Table, total number of FRU Record Data
structures, and the integrity checksum on the FRU Record Table data.
Add an "IBM, skiboot" FRU Record product requested by the BMC.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPDR command is used to retrieve individual PDRs from a PDR
repository. The record is identified by the PDR recordHandle value
that is passed in the request.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The boot progress record will be used to report Opal's progress to the BMC
during the boot.
The Terminus Locator PDR forms the association between a TID and PLDM
Terminus Handle for a terminus.
This patch allows to add terminus locator record in the repository.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Encode the platform PDR repository change event message request that tells
the BMC that a specific PDR entry has changed.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add a wrapper for the libpldm api: pldm_pdr_find_record()
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The SetStateEffecterStates command is used to set the state of one or more
effecters within a PLDM State Effecter.
The field comp_effecter_count indicates the number of individual sets of
state effecter information that are accessed by this command.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetStateSensorReadings command can return readings for multiple state
sensors (a PLDM State Sensor that returns more than one set of state
information is called a composite state sensor).
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM Event Messages are sent as PLDM request messages to the Event Receiver
using the PlatformEventMessage command.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The SetEventReceiver command is used to set the address of the Event
Receiver into a terminus that generates event messages. It is also used to
globally enable or disable whether event messages are generated from the
terminus.
For the time being, only the following global event message is supported:
PLDM_EVENT_MESSAGE_GLOBAL_ENABLE_ASYNC_KEEP_ALIVE.
The Event Receiver acknowledges receiving the PLDM Event Message in the
response to this command.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Encode a PLDM platform event message to send the heartbeat to the BMC.
Watchdog is "armed" when a
PLDM_EVENT_MESSAGE_GLOBAL_ENABLE_ASYNC_KEEP_ALIVE is received.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
In the same way that ipmi-hiomap implements the PNOR access control
protocol, this patch allows to "virtualize" the content of a BMC flash
based on lid files.
Previously, flash PNOR partitions were viewed this way:
partitionXX=NAME, start address, end address, flags
The content of each partition is now stored in a lid file. In order to
continue to use the libflash library, we manually fill in the contents of
a fake flash header when accessing offset 0. This reproduces the behavior
via ipmi-hiomap of reading the flash header on the BMC.
For the reading and writing of BMC lids files, we convert the virtual
addresses of these 'fake' partitions by identifying: lid id.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This patch parses the "hb_lid_ids" string from bios tables and complete
the global list of lid files. Each entry in the list contains the name,
the id, the length of the lid file and the virtual address start access.
This virtual address is used for for PNOR Resource Provider operations.
16 MB of VMM address are reserved space per section.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Retrieve the file handle and file length based on attribute name.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Send/receive a PLDM WriteFile request message.
Due to maximum transfer size for PLDM protocol, we have to send several
write requests, if necessary.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Send/receive a PLDM ReadFile request message.
Due to maximum transfer size for PLDM protocol, we have to send several
read requests, if necessary.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The ibm/libpldm library implements IBM OEM commands support for PLDM and
specially encode and decode APIs for in-band readFile and writeFile
commands.
The GetFileTable request message is used to retrieve the file table which
contains the list of lid files available and their attributes.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Use the GetFruRecordByOptionReq command to retrieve the bmc information
with: "FRU Field Type": Version
"FRU Record Set Identifier": 1,
"FRU Record Type": "General(1)"
and update the "bmc-firmware-version" device-tree field.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Specification, defines a FRU data format that provides platform asset
information including part number, serial number and manufacturer.
Use the GetFruRecordByOptionReq command to get specific FRU (Field
Replaceable Unit) record according the Record Set Identifier, the Record
Type and the field Type.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the data structures and messages for
communicating BIOS settings, BIOS attributes, boot configurations, and
boot order settings.
Use the GetBIOSTable command to get STRING, Attribute and Attribute values
tables from the BIOS.
The contents of these tables are needed to read/write the desired lid
files located on the BMC.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the data structures and messages for
communicating BIOS settings, BIOS attributes, boot configurations, and
boot order settings.
Use the GetBIOSTable command to get STRING, Attribute and Attribute values
tables from the BIOS.
The content of these tables is useful to read/write the lid files located
on the BMC.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Set the state information of the PLDM effecter identified by:
the entity type (PLDM_ENTITY_SYSTEM_CHASSIS) and the state set
PLDM_STATE_SET_SYSTEM_POWER_STATE with the effecter state:
PLDM_STATE_SET_SYS_POWER_STATE_OFF_SOFT_GRACEFUL to request a platform off.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Set the state information of the PLDM effecter identified by:
the entity type (PLDM_ENTITY_SYS_FIRMWARE) and the state set
PLDM_STATE_SET_SW_TERMINATION_STATUS with the effecter state:
PLDM_SW_TERM_GRACEFUL_RESTART_REQUESTED to request a platform restart.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM effecters provide a general mechanism for controlling or configuring a
state or numeric setting of an entity.
The entity state and numeric setting values are written into an effecter.
PLDM commands are specified for writing the state or numeric setting to an
effecter. Effecters are identified by and accessed using an EffecterID that
is unique for each effecter within a given terminus.
PLDM State Effecters provide a regular command structure for setting state
information in order to change the state of an entity.
The SetStateEffecterStates command is used to set the state of one or more
effecters within a PLDM State Effecter.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This specification defines the functions and data structures used for
discovering, describing, initializing, and accessing sensors and effecters
within the management controllers and management devices of a platform
management subsystem using PLDM messaging.
A PDR (Platform Descriptor Record) is a set of data that is used to
provide semantic information about sensors, effecters, monitored or
controller entities, and functions and services within a PLDM
implementation.
PDRs are mostly used to support PLDM monitoring and control and platform
events.
The PDRs for a PLDM subsystem are collected into a single, central PDR
Repository. A central repository provides a single place from which PDR
information can be retrieved.
The GetPDR command is used to retrieve individual PDRs from a PDR
Repository. The record is identified by the PDR recordHandle value that is
passed in the request.
The patch dump all the PDRs within a PDR Repository.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Implement a way for sending PLDM requests for specific PLDM commands.
Send a PLDM request message. Wait for corresponding response message,
which once received, is returned to the caller.
If there's data available, return success only if data is a PLDM response
message that matches instance, pldm_type and command code.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMVersion command can be used to retrieve the PLDM base
specification versions that the PLDM terminus supports, as well as the
PLDM Type specification versions supported for each PLDM Type.
The reported version for Type 0 (PLDMbase) shall be encoded as 0xF1F1F000.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMCommands command can be used to discover the PLDM command
capabilities supported by a PLDM terminus for a specific PLDM Type and
version as a responder.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The GetPLDMTypes command can be used to discover the PLDM type capabilities
supported by a PLDM terminus and to get a list of the PLDM types that are
supported.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
A PLDM Terminus is defined as the point of communication termination for
PLDM messages and the PLDM functions associated with those messages.
Given a PLDM terminus, a mechanism is required that can uniquely identify
each terminus so that the semantic information can be bound to that
identification.
The Terminus ID (TID) is a value that identifies a PLDM terminus.
TIDs are used in PLDM messages when it is necessary to identify the PLDM
terminus that is the source of the PLDM Message.
The GetTID command is used to retrieve the present Terminus ID (TID)
setting for a PLDM Terminus.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
PLDM defines data representations and commands that abstract the platform
management hardware.
A PLDM Terminus (or responder) is defined as the point of communication
termination for PLDM messages and the PLDM functions associated with those
messages.
A PLDM terminus is not required to process more than one request at a time
(that is, it can be "single threaded" and does not have to accept and act
on new requests until it has finished responding to any previous request).
Some PLDM control and discovery requests (PLDM_TYPE = PLDM_BASE) are
mandatory a PLDM terminus has to answer.
These following mandatory PLDM command codes for PLDM messaging control
and discovery will be defined in next patches.
GetTID 0x02
GetPLDMVersion 0x03
GetPLDMTypes 0x04
GetPLDMCommands 0x05
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Enable the mctp binding over LPC bus interface and new wrappers to send
and receive PLDM messages over the mctp library.
PLDM is supported as a message type over MCTP. PLDM over MCTP binding
defines the format of PLDM over MCTP messages.
An MCTP Endpoint is the terminus for MCTP communication. A physical device
that supports MCTP may provide one or more MCTP Endpoints. Endpoints are
addressed using a logical address called the Endpoint ID, or EID. EIDs in
MCTP are analogous to IP Addresses in Internet Protocol networking.
The BMC EID default is 8.
First byte of the PLDM over MCTP Message Fields identifies the MCTP
message as carrying a PLDM message:
Message Type (7 bits) PLDM = 0x01 (000_0001b).
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The Management Component Transport Protocol (MCTP) defines a communication
model intended to facilitate communication.
This patch initialize MCTP binding over LPC Bus interface.
Several steps must be performed:
- Initialize the MCTP core (mctp_init()).
- Initialize a hardware binding as AST LPC mode host (mctp_astlpc_init()).
- Register the hardware binding with the core (mctp_register_bus()), using
a predefined EID (Host default is 9).
To transmit a MCTP message, mctp_message_tx() is used.
To receive a MCTP message, a callback need to be provided and registered
through mctp_set_rx_all().
For the transfer of MCTP messages, two basics components are used:
- A window of the LPC FW address space, where reads and writes are
forwarded to BMC memory.
- An interrupt mechanism using the KCS interface.
hw/ast-bmc/ast-mctp.c is compilated if the compiler flag CONFIG_PLDM is
set.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Add new lpc helpers for doing a bulk io to firmware space.
Reviewed-by: Abhishek Singh Tomar <abhishek@linux.ibm.com>
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
This library implements IBM OEM commands support for PLDM and specially
encode and decode APIs for in-band readFile and writeFile commands.
The source is located here:
https://github.com/openbmc/pldm/tree/master/oem/ibm/libpldm and use as is,
without any update.
The oem IBM libpldm code is integrated into the folder ./pldm/ibm/libpldm
as a set of sources, compilated if the compiler flag CONFIG_PLDM is set.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
Platform Level Data Model (PLDM) is a standard application layer
communication protocol defined by the DMTF. PLDM is an effective data and
control source. PLDM defines a method to provide efficient access to
low-level platform inventory, monitoring, control, eventing, and
data/parameters transfer functions such as temperature, fan, voltage,
event logging, and boot control.
PLDM has defined data representations and commands that abstract the
platform management hardware.
The library deals with the encoding and decoding of PLDM messages.
The source is located here:
https://github.com/openbmc/pldm/tree/master/libpldm and use as is, without
any update.
The libpldm code is integrated into the folder ./pldm/libpldm as a set of
sources, compilated if the compiler flag CONFIG_PLDM is set.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|
|
The Management Component Transport Protocol (MCTP) is a protocol defined by
the DMTF Platform Management Component Intercommunications sub-team of the
DMTF Pre-OS Workgroup. MCTP is designed to support communications between
different intelligent hardware components that make up a platform
management subsystem that is provides monitoring and control functions
inside a managed system. DMTF standard "DSP2016"
This library is intended to be a portable implementation of the Management
Component Transport Protocol (MCTP), as defined by DMTF standard "DSP0236",
plus transport binding specifications.
MCTP has been designed to carry multiple types of manageability-related
traffic across a common medium. The base MCTP specifications define
message types for supporting the initialization and configuration of MCTP
itself, and to support vendor-specific messages over MCTP.
Other message types, such as message types to support a Platform Level
Data Model (PLDM).
The source is located here: https://github.com/openbmc/libmctp and use as
is, without any update.
The libmctp code is integrated into the folder ./libmctp as a set of
sources, compiled if the compiler flag CONFIG_PLDM is set.
A config file is required. Not being generated automatically by 'configure',
it must be edited manually to match the environment.
Signed-off-by: Christophe Lombard <clombard@linux.ibm.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
|