| /openbmc/docs/designs/mctp/ |
| H A D | mctp.md | 1 # OpenBMC platform communication channel: MCTP & PLDM
8 BMC. This is primarily IPMI-based, but also includes a few hardware-specific
9 side-channels, like hiomap. On OpenPOWER hardware at least, we've definitely
21 Separating the "transport" and "messaging protocol" parts of the current stack
27 attempted, but not in a cross-implementation manner so far. This does not
40 
43 physical layer bindings; this means that an MCTP "stack" may be using either a
45 stack needing to be aware of the hardware implementation. These higher levels
48 that communicates over MCTP - for example, the host device, the BMC, or any
49 other system peripheral - static or hot-pluggable.
[all …]
|
| H A D | mctp-userspace.md | 1 # OpenBMC platform communication channel: MCTP & PLDM in userspace
20 provides a socket-based interface for other processes to send and receive
24 handling local MCTP-stack configuration, like local EID assignments.
28 1. the core MCTP stack
30 2. one or more binding implementations (eg, MCTP-over-serial), which interact
33 3. an interface to handler applications over a unix-domain socket.
38 - an "upper" messaging transmit/receive interface, for tx/rx of a full message
41 - a "lower" hardware binding for transmit/receive of individual packets,
45 The lower interface would be plugged in to one of a number of hardware-specific
47 tree, but others can be plugged-in too, perhaps where the physical layer
[all …]
|
| /openbmc/pldm/ |
| H A D | meson.options | 1 # PLDM daemon options
26 'transport-implementation',
28 choices: ['mctp-demux', 'af-mctp'],
29 description: 'transport via af-mctp or mctp-demux',
32 # As per PLDM spec DSP0240 version 1.1.0, in Timing Specification for PLDM messages (Table 6),
35 # value to 5 seconds we ensure that PLDM does not wait for a response from a dbus call even after
37 # PLDM daemon will timeout after 5 seconds.
39 'dbus-timeout-value',
44 description: '''The amount of time pldm waits to get a response for a dbus
49 'heartbeat-timeout-seconds',
[all …]
|
| /openbmc/libbej/include/libbej/ |
| H A D | bej_decoder_core.h | 26 * @brief These stack entries are needed to implement the decoding
27 * non-recursively.
137 * @brief Stack for holding BejStackProperty types. Decoder core is not
138 * responsible for creating or deleting stack memory. User of the decoder
139 * core is responsible for creating and deleting stack memory.
146 * @brief Return true if the stack is empty.
151 * @brief View the object at the top of the stack. If the stack is
157 * @brief Removes the top most object from the stack. Client of the
164 * @brief Push an object into the stack. Returns 0 if the operation is
188 * @brief Decodes a PLDM block. Maximum encoded stream size the decoder
[all …]
|
| H A D | bej_decoder_json.hpp | 20 * @brief Decode the encoded PLDM block.
22 * @param[in] dictionaries - dictionaries needed for decoding.
23 * @param[in] encodedPldmBlock - encoded PLDM block.
40 std::vector<BejStackProperty> stack; member in libbej::BejDecoderJson
|
| H A D | bej_common.h | 152 // Value end-offset with respect to the begining of the encoded stream.
159 * @brief bejEncoding PLDM data type header.
179 * @brief Callbacks to a stack that can store pointers.
184 * @brief A context for the stack.
189 * @brief Return true if the stack is empty.
194 * @brief View the pointer at the top of the stack. If the stack is
200 * @brief Returns and removes the top most pointer from the stack. The
208 * @brief Push a pointer into the stack. Returns 0 if the operation is
215 * @brief Delete the stack.
223 * @param[in] bytes - valid pointer to a byte stream in little-endian
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/PLDM/ |
| H A D | Requester.interface.yaml | 2 Implement to provide features needed to build a PLDM Request message. This
3 API would be used by PLDM requester apps on the BMC.
6 xyz.openbmc_project.PLDM.Requester on /xyz/openbmc_project/pldm.
8 PLDM stands for Platform Level Data Model. More information about PLDM (and
12 - name: GetInstanceId
14 Obtain a new PLDM instance id, for the input MCTP EID, to be used in a
15 PLDM request message. Instance ids help distinguish PLDM response
16 messages when a PLDM requester sends out multiple request messages,
17 without waiting for a response message. Refer the PLDM specification
19 https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md#Requester.
[all …]
|
| /openbmc/openbmc/meta-ibm/recipes-phosphor/pldm/ |
| H A D | pldm_%.bbappend | 1 # Force the mctp-demux to be used until machine is ready to use in-kernel MCTP
2 PACKAGECONFIG:append = " transport-mctp-demux oem-ibm system-specific-bios-json"
5 PACKAGECONFIG:remove:huygens = " oem-ibm"
8 -Dsoftoff-timeout-seconds=2700 \
11 #5 second timeout defined inside PLDM has seen issues during reset reload
12 #so increasing that to 10 seconds here.IBMs custom firmware stack can tolerate
13 #PLDM timeouts of up to 20 seconds, so using timeout value of 10 seconds is safe.
15 -Ddbus-timeout-value=10 \
18 SYSTEMD_SERVICE:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'oem-ibm', \
19 'pldm-create-phyp-nvram.service \
[all …]
|
| /openbmc/libpldm/include/libpldm/ |
| H A D | base.h | 1 /* SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later */
19 /** @brief PLDM Types
32 /** @brief PLDM Commands
47 /** @brief PLDM base codes
81 /** @brief PLDM transport protocol type
90 * The different message types supported by the PLDM specification.
93 PLDM_RESPONSE, //!< PLDM response
94 PLDM_REQUEST, //!< PLDM request
96 PLDM_ASYNC_REQUEST_NOTIFY, //!< Unacknowledged PLDM request messages
126 /** @brief Minimum length of response for a optional PLDM command
[all …]
|
| /openbmc/docs/designs/ |
| H A D | pldm-stack.md | 1 # PLDM stack on OpenBMC
5 Created: 2019-01-22
9 On OpenBMC, in-band IPMI is currently the primary industry-standard means of
16 This design aims to employ Platform Level Data Model (PLDM), a standard
17 application layer communication protocol defined by the DMTF. PLDM draws inputs
18 from IPMI, but it overcomes most of the latter's limitations. PLDM is also
21 channels, by defining hardware bindings. The solution of PLDM over MCTP also
24 PLDM's purpose is to enable all sorts of "inside the box communication": BMC -
25 Host, BMC - BMC, BMC - Network Controller and BMC - Other (for e.g. sensor)
30 PLDM is designed to be an effective interface and data model that provides
[all …]
|
| H A D | boot-progress.md | 12 phosphor D-Bus properties, IPMI sensors, PLDM sensors, and Redfish properties to
18 [phosphor-state-manager][1] implements D-Bus properties which track the state of
28 phosphor-state-manager implements some other D-Bus properties that represent the
31 - [xyz.openbmc_project.State.Boot.Progress][3]
32 - [xyz.openbmc_project.State.OperatingSystem.Status][4]
34 These two D-Bus properties are very IPMI-centric. They were defined based on two
37 PLDM also has a boot progress sensor. Search for "Boot Progress" in this
38 [doc][5]. A subset of this maps fairly well to the IPMI sensors above. This PLDM
44 following mapping for phosphor-state-manager to the Redfish System
47 - `xyz.openbmc_project.State.Host.HostState.Running` : `Enabled`
[all …]
|
| H A D | bmc-reset-with-host-up.md | 18 A good portion of this is explained in the phosphor-state-manager [README][1].
21 dealing with both IPMI and PLDM communication to the host as well as desired
28 - /run/openbmc/chassis@0-on
29 - /run/openbmc/host@0-on
31 It should be noted that although full support is not in place for multi-chassis
32 and multi-host systems, the framework is there to build on.
33 `op-reset-chassis-running@.service` is a templated service, checking pgood in
35 /run/openbmc/chassis@%i-on, to indicate power is on for that instance. Similar
36 implementation is done for the host via `phosphor-reset-host-check@.service` and
37 the file /run/openbmc/host@%i-on.
[all …]
|
| H A D | power-systems-memory-preserving-reboot.md | 15 don't have access to a non-volatile storage to store this content after a
18 explains the high-level flow of warm reboot and extraction of the resulting dump
23 - **Boot**: The process of initializing hardware components in a computer system
26 - **Hostboot**: The firmware runs on the host processors and performs all
28 [read more](https://github.com/open-power/docs/blob/master/hostboot/HostBoot_PG.md)
30 - **Self Boot Engine (SBE)**: A microcontroller built into the host processors
35 - **Master Processor**: The processor which gets initialized first to execute
38 - **POWER Hardware Abstraction Layer (PHAL)**: A software component on the BMC
41 - **Hypervisor**: A hypervisor (or virtual machine monitor, VMM) is a computer
45 - **System Dump**: A dump of main memory and hardware states for debugging the
[all …]
|
| H A D | dump-manager.md | 20 - **System Dump**: A dump of the Host's main memory and processor registers.
22 - **Memory Preserving Reboot(MPR)**: A method of reboot with preserving the
24 - **PLDM**: An interface and data model to access low-level platform inventory,
26 [ReadMore](https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md)
27 - **Machine Check Exception**: A severe error inside a processor core that
29 - **BMCWeb**: An embedded webserver for OpenBMC.
84 …es - Users are examples, not a mandatory part of implementation](https://user-images.githubusercon…
88 - Create a dump: Initiate the creation of the dump, based on an error condition
90 - List the dumps: List all dumps present in the BMC.
91 - Get a dump: Offload the dump to an external entity.
[all …]
|
| H A D | code-update.md | 10 [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt)
12 1. Current code update flow is complex as it involves 3 different daemons -
23 - [phosphor-bmc-code-mgmt](https://github.com/openbmc/phosphor-bmc-code-mgmt)
24 - [Software DBus Interface](https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xy…
25 - [Code Update Design](https://github.com/openbmc/docs/tree/master/architecture/code-update)
31 - Update settings shall be able to specify when to apply the image, for example
32 immediately or on device reset or on-demand.
66 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Update<br> at /xyz/openbmc_project/Sof…
67 CU ->> CU: Create Interface<br> xyz.openbmc_project.Software.Version<br> at /xyz/openbmc_project/So…
68 CU ->> CU: Create Interface<br>xyz.openbmc_project.Software.Activation<br> at /xyz/openbmc_project/…
[all …]
|
| /openbmc/pldm/libpldmresponder/ |
| H A D | fru.cpp | 7 #include <systemd/sd-journal.h>
9 #include <phosphor-logging/lg2.hpp>
14 #include <stack>
18 namespace pldm namespace
53 std::stack<std::string> tmpObjPaths{}; in updateAssociationTree()
56 auto obj = pldm::utils::findParent(path); in updateAssociationTree()
60 obj = pldm::utils::findParent(obj); in updateAssociationTree()
63 std::stack<std::string> tmpObj = tmpObjPaths; in updateAssociationTree()
69 // Update pldm entity to association tree in updateAssociationTree()
152 objects = pldm::utils::DBusHandler::getInventoryObjects< in buildFRUTable()
[all …]
|
| /openbmc/pldm/pldmtool/ |
| H A D | README.md | 3 pldmtool is a client tool that acts as a PLDM requester which runs on the BMC.
8 pldmtool supports the subcommands for PLDM types such as base, platform, bios,
9 fru, and oem-ibm.
11 - Source files are implemented in C++.
12 - Consumes pldm/libpldm encode and decode functions.
13 - Communicates with pldmd daemon running on BMC.
14 - Enables writing functional test cases for PLDM stack.
16 please refer the [DMTF PLDM specifications](https://www.dmtf.org/) with respect
17 to the pldm types.
21 Source files in pldmtool repository are named with respect to the PLDM type.
[all …]
|
| /openbmc/openbmc/meta-phosphor/recipes-phosphor/pldm/ |
| H A D | pldm_git.bb | 1 HOMEPAGE = "https://github.com/openbmc/pldm"
2 LICENSE = "Apache-2.0"
4 SRC_URI = "git://github.com/openbmc/pldm;branch=master;protocol=https"
7 SUMMARY = "PLDM Stack"
8 DESCRIPTION = "Implementation of the PLDM specifications"
12 DEPENDS += "phosphor-dbus-interfaces"
13 DEPENDS += "nlohmann-json"
16 DEPENDS += "phosphor-logging"
27 PACKAGECONFIG[transport-mctp-demux] = "-Dtransport-implementation=mctp-demux"
28 PACKAGECONFIG[transport-af-mctp] = "-Dtransport-implementation=af-mctp"
[all …]
|
| /openbmc/libpldm/docs/checklists/ |
| H A D | changes.md | 5 - [Good Practices in Library Design, Implementation, and Maintenance - Ulrich
10 - [How Do I Make This Hard to Misuse? - Rusty Russell][rusty-api-scale-good]
12 [rusty-api-scale-good]: https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
14 - [What If I Don't Actually Like My Users? - Rusty Russell][rusty-api-scale-bad]
16 [rusty-api-scale-bad]: https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
18 - [Red flags that indicate questionable quality - Lennart
19 Poettering][poettering-library-red-flags]
21 [poettering-library-red-flags]:
24 - [Not sure if this is a gcc bug or some weird corner of UB or what... - Andrew
25 Zonenberg][azonenberg-packed-struct]
[all …]
|
| /openbmc/pldm/oem/ibm/libpldmresponder/ |
| H A D | oem_ibm_handler.cpp | 10 #include <libpldm/pldm.h>
12 #include <phosphor-logging/lg2.hpp>
17 using namespace pldm::pdr;
18 using namespace pldm::utils;
20 namespace pldm namespace
26 int pldm::responder::oem_ibm_platform::Handler::
28 pldm::pdr::EntityType entityType, EntityInstance entityInstance, in getOemStateSensorReadingsHandler()
54 sensorOpState = slotHandler->fetchSlotSensorState(key); in getOemStateSensorReadingsHandler()
70 int pldm::responder::oem_ibm_platform::Handler::
95 codeUpdate->setCodeUpdateProgress(true); in oemSetStateEffecterStatesHandler()
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/MCTP/ |
| H A D | Endpoint.interface.yaml | 6 MCTP-capable management controllers and managed devices.
9 - name: NetworkId
13 network within a platform. The network IDs are used by the MCTP stack
17 - name: EID
29 - name: SupportedMessageTypes
35 types are MCTP Control(0x00), PLDM(0x01), NC-SI over MCTP(0x02),
44 - name: configured_by
51 - xyz.openbmc_project.Configuration.MCTPDevice
|
| /openbmc/libbej/src/ |
| H A D | bej_decoder_core.c | 16 * not do anything. If the callback function returns a non-zero value, this will
17 * cause the caller to return with the non-zero status.
35 * @param[in] bytes - valid pointer to a byte stream in little-endian format.
36 * @param[in] numOfBytes - number of bytes belongs to the value. Maximum value
49 uint64_t mask = (uint64_t)1 << (uint8_t)(bitsInVal - 1); in bejGetIntegerValue()
50 return (int64_t)((value ^ mask) - mask); in bejGetIntegerValue()
56 * @param[in] enSegment - a valid pointer to a start of a SFLV bejTuple.
57 * @param[out] offsets - this will hold the local offsets.
63 // [Number of bytes need to represent the sequence number] - uint8_t in bejGetLocalBejSFLVOffsets()
64 // [SequenceNumber] - multi byte in bejGetLocalBejSFLVOffsets()
[all …]
|
| /openbmc/openbmc-test-automation/ |
| H A D | README.md | 5 - DMTF Redfish
6 - Out-of-band IPMI
7 - SSH to BMC and Host OS
8 - [Legacy REST](https://github.com/openbmc/openbmc-test-automation/releases/tag/v4.0-stable)
12 - Power on/off
13 - Reboot Host
14 - Reset BMC
15 - Code update BMC and host
16 - Power management
17 - Fan controller
[all …]
|
| /openbmc/libmctp/tests/fuzz/ |
| H A D | i2c-fuzz.c | 13 #include "libmctp-i2c.h"
14 #include "libmctp-sizes.h"
15 #include "libmctp-alloc.h"
59 buf->pos = 0; in fuzz_buf_new()
60 buf->len = len; in fuzz_buf_new()
61 buf->data = data; in fuzz_buf_new()
67 if (buf->pos + len > buf->len) { in fuzz_buf_extract()
71 const void *ret = &buf->data[buf->pos]; in fuzz_buf_extract()
72 buf->pos += len; in fuzz_buf_extract()
95 const uint8_t *v = fuzz_buf_extract(ctx->ctrl, sizeof(uint8_t)); in fuzz_chance()
[all …]
|
| /openbmc/openbmc-test-automation/lib/ |
| H A D | utils.robot | 174 ... Set Variable echo ${os_password} | sudo -S reboot
197 ... Set Variable echo ${os_password} | sudo -S shutdown${time_string}
273 # prior call to this function or via a -v parm), this keyword will simply
281 # -v boot_prog_method:Old to force old behavior on such builds.
506 ... cpu -
525 …${resp}= Get Matches ${list} regexp=^.*[0-9a-z_].${endpoint}\[_0-9a-z]*$ case_insensitive=${Tr…
590 # 0 - indicates chip select is current side.
591 # 32 - indicates chip select is alternate side.
702 [Arguments] ${power_restore_policy}=always-off
706 # always-on : turn on when power is restored
[all …]
|