| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Control/ |
| H A D | ThermalMode.interface.yaml | 6 Implementation of this interface populates the list of supported modes.
8 Implementation specific mode for the thermal control application
12 - name: Supported
15 - readonly
17 An implementation specific list of supported modes that the thermal
19 - name: Current
|
| H A D | VoltageRegulatorMode.interface.yaml | 3 Control.VoltageRegulatorProfile.Supported is read only. Implementation of
7 and sets the implementation specific mode for the voltage regulator to run
8 in. The definitions of said enum are implementation defined, as systems
22 - name: Supported
25 - readonly
27 An implementation specific list of supported modes that the voltage
30 - name: Selected
|
| H A D | MinimumShipLevel.interface.yaml | 2 'An implementation may provide a single instance of MinimumShipLevelRequired
5 The definition of enforcement of this setting is implementation defined.'
8 - name: MinimumShipLevelRequired
11 'A user has requested that the implementation specific requirements
|
| /openbmc/qemu/include/accel/ |
| H A D | accel-cpu-target.h | 3 * This header is used only by target-specific code.
8 * See the COPYING file in the top-level directory.
15 * This header is used to define new accelerator-specific target-specific
17 * It uses CPU_RESOLVING_TYPE, so this is clearly target-specific.
19 * Do not try to use for any other purpose than the implementation of new
20 * subclasses in target/, or the accel implementation itself in accel/
24 #include "accel/accel-cpu.h"
27 #define TYPE_ACCEL_CPU "accel-" CPU_RESOLVING_TYPE
28 #define ACCEL_CPU_NAME(name) (name "-" TYPE_ACCEL_CPU)
|
| /openbmc/pldm/docs/ |
| H A D | pdr_implementation.md | 1 # PDR Implementation
4 they can vary across platforms and systems. For this reason, platform specific
5 PDR information is encoded in platform specific JSON files. JSON files must be
8 additional processing (apart from PDR creation) for specific PDR types, for eg
9 mapping an effecter id to a D-Bus object.
11 The PLDM responder implementation finds and parses PDR JSON files to create the
12 PDR repository. Platform specific PDR modifications would likely just result in
14 generation code. The PDR generator is a map of PDR Type -> C++ lambda to create
|
| /openbmc/docs/designs/mctp/ |
| H A D | mctp-userspace.md | 8 This document describes a userspace implementation of MCTP infrastructure,
20 provides a socket-based interface for other processes to send and receive
24 handling local MCTP-stack configuration, like local EID assignments.
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.
35 The proposed implementation here is to produce an MCTP "library" which provides
38 - an "upper" messaging transmit/receive interface, for tx/rx of a full message
39 to a specific endpoint (ie, (1) above)
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
[all …]
|
| H A D | mctp.md | 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
27 attempted, but not in a cross-implementation manner so far. This does not
40 
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.
54 For example, the PLDM design at [pldm-stack.md].
58 the higher-level data transferred between MCTP endpoints, which packets are
61 packets by the transmit implementation, and reassembled at the receive
[all …]
|
| /openbmc/u-boot/doc/imx/misc/ |
| H A D | sdp.txt | 1 -------------
2 SDP in U-Boot
3 -------------
9 The implementation in U-Boot uses the USB Downloader Gadget (g_dnl) to
10 provide a SDP implementation over USB. This allows to download program
11 images to the target in SPL/U-Boot using the same protocol/tooling the
15 protocols allow to access a USB device without OS specific drivers. The
16 U-Boot implementation has primarly been tested using the open source
20 install U-Boot without a JTAG debugger, using the USB boot mode as
25 specific image header (see doc/README.imximage). There are extensions
[all …]
|
| /openbmc/openbmc/meta-phosphor/recipes-phosphor/pldm/ |
| H A D | pldm_git.bb | 2 LICENSE = "Apache-2.0"
8 DESCRIPTION = "Implementation of the PLDM specifications"
12 DEPENDS += "phosphor-dbus-interfaces"
13 DEPENDS += "nlohmann-json"
16 DEPENDS += "phosphor-logging"
20 PACKAGE_BEFORE_PN:append = " pldmtool pldm-libs"
28 FILES:pldm-libs = "${libdir}/lib*${SOLIBS}"
33 PACKAGECONFIG[transport-mctp-demux] = "-Dtransport-implementation=mctp-demux"
34 PACKAGECONFIG[transport-af-mctp] = "-Dtransport-implementation=af-mctp"
35 PACKAGECONFIG[oem-ibm] = "-Doem-ibm=enabled, -Doem-ibm=disabled, , squashfs-tools"
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Dump/ |
| H A D | Create.interface.yaml | 5 Any OpenBMC implementation should provide one implementation of
7 /xyz/openbmc_project/dump/<dump type>. On multi-host or on multi-BMC systems
9 /xyz/openbmc_project/dump/<dump type><instance-id>.
12 - name: CreateDump
16 - name: AdditionalData
20 this case should be an implementation specific enum defined for
21 the specific type of dump either in xyz or in a domain. The
23 enum-format string is required to come from a parallel class
24 with this specific Enum name. All of the Enum strings should be
34 - name: Path
[all …]
|
| /openbmc/u-boot/drivers/usb/ulpi/ |
| H A D | Kconfig | 7 Select ULPI viewport (SoC-side interface to ULPI) implementation
14 Support generic ULPI Viewport implementation that is used on
20 Support ULPI Viewport implementation that is used on OMAP devices.
32 This driver uses ULPI viewports that are specific for each SoC.
|
| /openbmc/u-boot/doc/ |
| H A D | README.omap-ulpi-viewport | 1 Reference code ""drivers/usb/ulpi/omap-ulpi-viewport.c"
11 omap-ulpi-viewport.c is a low level function
12 implementation of "drivers/usb/ulpi/ulpi.c"
14 To enable and use omap-ulpi-viewport.c
19 and soc specific binding and usage is done with
20 omap-ulpi-viewport implementation.
23 omap-ehci driver code requests for ulpi phy reset if
26 implementation which will do ulpi reset using the
|
| /openbmc/intel-ipmi-oem/ |
| H A D | README.md | 3 This component is intended to provide Intel-specific IPMI`[3]` command handlers
9 `intel-ipmi-oem` serves as an extension`[1]` to OpenBMC IPMI daemon`[2]`. It is
12 - override existing implementation of standard IPMI commands to comply with
13 Intel-specific solutions,
14 - provide implementation for non-standard OEM extensions.
21 - Acquiring SMBIOS data over IPMI
22 - Commands for better integration with Intel hardware
23 - Firmware update extensions
24 - Extended parsing of IPMI Platform Events`[4]`
28 1. [OpenBMC IPMI Architecture](https://github.com/openbmc/docs/blob/master/architecture/ipmi-archit…
[all …]
|
| /openbmc/phosphor-gpio-monitor/ |
| H A D | README.md | 5 ### `phosphor-gpio-monitor`
8 take action if requested. This implementation uses GPIO keys and only supports
12 ### `phosphor-multi-gpio-monitor`
14 This daemon accepts command line parameter as a well-defined GPIO configuration
20 New implementation (phosphor-multi-gpio-monitor) provides multiple gpio line
21 monitoring in single instance of phosphor-multi-gpio-monitor running. It is very
27 There is a phosphor-multi-gpio-monitor.json file that defines details of GPIOs
29 specific configuration file via bbappend.
34 2. LineName: this is the line name defined in device tree for specific gpio
79 ### `phosphor-multi-gpio-presence`
[all …]
|
| /openbmc/docs/designs/ |
| H A D | bmc-service-failure-debug-and-recovery.md | 16 - A class of failure exists where a BMC service has entered a failed state but
18 - A class of failure exists under which we can attempt debug data collection
21 This proposal argues for and proposes a software-driven debug data capture and
26 By necessity, BMCs are not self-contained systems. BMCs exist to service the
27 needs of both the host system by providing in-band platform services such as
29 out-of-band system management interfaces such as error reporting, platform
35 are usually a domain-specific Linux distributions with complex or highly coupled
40 recovery in the face of well-defined error conditions, but the need to mitigate
41 ill-defined error conditions or entering unintended software states remains.
60 As the state transformations to enter the ill-defined or unintended software
[all …]
|
| H A D | nmi-dbus-interface.md | 7 Created: 2019-05-21
19 causing system hang(<https://github.com/ibm-openbmc/dev/issues/457>). This means
24 which, in turn, triggers an architecture-dependent procedure that fires an
30 architecture-specific procedure that enables data collection followed by
34 ### D-Bus
36 Introducing new D-Bus interface in the control.host namespace
37 (/openbmc/phosphor-dbus-interfaces/xyz/openbmc_project/Control/Host/
38 NMI.interface.yaml) and implement the new D-Bus back-end for respective
39 processor specific targets.
43 Enable NMI D-Bus phosphor interface and support this via Redfish
[all …]
|
| H A D | thermal-control-modes.md | 7 Created: 2019-02-06
17 optical cables plugged into a card downwind from the GPUs' exhaust, an end-user
35 <https://github.com/openbmc/dbus-sensors/blob/master/src/ExitAirTempSensor.cpp>
39 Create the ability for an end-user to enable the use of a thermal control mode
40 other than the default. In this use-case, the mode is specific to an
42 standardized profile/modes such "Acoustic" and "Performance". Once the end-user
45 implementation specific to that instance of the application on that platform.
51 Initially the current mode would be set to "Default" and the implementation of
54 As one implementation, phosphor-fan-presence/control would be updated to extend
58 queried for supported modes or update the current mode. An end-user may set the
|
| H A D | psu-firmware-update.md | 7 - Su Xiao <suxiao@inspur.com>
8 - Derek Howard <derekh@us.ibm.com>
10 Created: 2019-06-03
28 - [phosphor-bmc-code-mgmt][2] implements BMC code update, and it supports all
30 - [openpower-pnor-code-mgmt][3] implements BIOS code update, and it only
33 - Both of the above use the same [Software DBus interface][1].
35 For PSU firmware update, it is preferred to re-use the same function for the
53 avoid power loss. This shall be handled by PSU vendor-specific tools, but not in
56 Note: The "vendor-specific" referred below is the PSU vendor-specific.
58 So the below checks are optional and expected to be handled by vendor-specific
[all …]
|
| /openbmc/bmcweb/docs/ |
| H A D | OEM_SCHEMAS.md | 17 Because of that, OEM properties in an open-source project pose many problems
21 possible. Adding machine-specific resources, properties, and types defeats a
22 large amount of reuse, as clients must implement machine-specific APIs, some of
25 and therefore needs to take care when adding new, non-standard APIs, given the
29 quality and testing than their spec-driven alternatives, given the lack of
36 have to break an API boundary to move to the standard implementation. Given the
47 In the current implementation, OEM schemas for all namespaces are shipped on all
57 1. Read all the relevant documentation on OEM schema technical implementation
73 4. If OpenBMC feedback is that this feature is specific to a single OEM or ODM,
76 an OEM/ODM specific namespace.
[all …]
|
| /openbmc/intel-ipmi-oem/docs/ |
| H A D | Intel_IPMI_Platform_Events.md | 3 In many cases Manufacturers-specific IPMI Platfrom Events are stored in binary
8 events originating from Intel Management Engine (ME) is used as a case-study.
9 General design of the solution is followed by tailored-down implementation for
14 - **IPMI** - Intelligent Platform Management Interface; standarized binary
16 - **Platform Event** - specific type of IPMI binary payload, used for encoding
17 and sending asynchronous one-way messages to recipient `[1]-29.3`
18 - **ME** - Intel Management Engine, autonomous subsystem used for remote
20 - **Redfish** - modern datacenter management protocol, built around REST
22 - **OpenBMC** - open-source BMC implementation with Redfish-oriented interface
28 between entities in data-center. Recipient is responsible to receive data,
[all …]
|
| /openbmc/u-boot/arch/arm/cpu/armv8/ |
| H A D | Kconfig | 15 bool "Enable multiple CPUs to enter into U-Boot"
21 CPUECTLR_EL1.SMPEN bit before U-Boot.
33 or when CPU implementation doesn't include that register.
36 bool "Support spin-table enable method"
39 Say Y here to support "spin-table" enable method for booting Linux.
42 - Specify enable-method = "spin-table" in each CPU node in the
44 - Bring secondary CPUs into U-Boot proper in a board specific
49 U-Boot automatically does:
50 - Set "cpu-release-addr" property of each CPU node
52 - Reserve the code for the spin-table and the release address
[all …]
|
| /openbmc/phosphor-dbus-monitor/src/ |
| H A D | journal.hpp | 6 #include <phosphor-logging/log.hpp>
18 * @brief Journal callback implementation.
37 /** @brief Callback interface implementation. */
41 /** @brief Delegate type specific calls to subclasses. */
75 * @brief C++ type specific logic for the journal callback.
77 * @tparam T - The C++ type of the property values being traced.
78 * @tparam Severity - The log severity of the log entry.
95 /** @brief log interface implementation. */
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema-installed/ |
| H A D | Manager.v1_22_0.json | 4 "$schema": "http://redfish.dmtf.org/schemas/v1/redfish-schema-v1.json",
5 …"copyright": "Copyright 2014-2025 DMTF. For the full DMTF copyright policy, see http://www.dmtf.or…
12 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
43 "description": "The available OEM-specific actions for this resource.",
44 …"longDescription": "This property shall contain the available OEM-specific actions for this resour…
58 … "Oem": "The controller supports a command shell connection through an OEM-specific protocol.",
69 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
84 …on": "This property enumerates the command shell connection types that the implementation allows.",
94 …hall contain the maximum number of concurrent service sessions that this implementation supports.",
130 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema/ |
| H A D | Manager.v1_22_0.json | 4 "$schema": "http://redfish.dmtf.org/schemas/v1/redfish-schema-v1.json",
5 …"copyright": "Copyright 2014-2025 DMTF. For the full DMTF copyright policy, see http://www.dmtf.or…
12 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
43 "description": "The available OEM-specific actions for this resource.",
44 …"longDescription": "This property shall contain the available OEM-specific actions for this resour…
58 … "Oem": "The controller supports a command shell connection through an OEM-specific protocol.",
69 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
84 …on": "This property enumerates the command shell connection types that the implementation allows.",
94 …hall contain the maximum number of concurrent service sessions that this implementation supports.",
130 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Object/ |
| H A D | Enable.interface.yaml | 4 A d-bus object under certain circumstances may have the need to be denoted
7 again. What causes the object to be enabled or disabled - whether it's via
8 an external interface or internal logic - depends on a specific
9 implementation and use-case.
11 An example could be a d-bus object that denotes boot settings. However let's
12 say there's a permanent settings object versus a one-time (the next boot)
18 - name: Enabled
21 Whether the object is enabled or not. Implementation may throw error
25 - xyz.openbmc_project.Common.Error.NotAllowed
|