| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp/ |
| H A D | 0004-abseil-ppc-fixes.patch | 6 An all-in-one patch that fixes several issues:
8 1) UnscaledCycleClock not fully implemented for ppc*-musl (disabled on musl)
9 2) powerpc stacktrace implementation only works on glibc (disabled on musl)
10 3) powerpc stacktrace implementation has ppc64 assumptions (fixed)
15 Upstream-Status: Pending
17 Signed-off-by: Khem Raj <raj.khem@gmail.com>
18 ---
19 absl/base/internal/unscaledcycleclock.cc | 4 ++--
20 absl/base/internal/unscaledcycleclock_config.h | 3 ++-
21 absl/debugging/internal/examine_stack.cc | 8 +++++++-
[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
16 defined in config based on gpio state change. It uses libgpiod library.
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
23 line by name defined in kernel.
27 There is a phosphor-multi-gpio-monitor.json file that defines details of GPIOs
34 2. LineName: this is the line name defined in device tree for specific gpio
[all …]
|
| /openbmc/openbmc/meta-openembedded/meta-python/recipes-devtools/python/python3-grpcio/ |
| H A D | abseil-ppc-fixes.patch | 3 Date: Sat, 13 Mar 2021 10:26:25 -0800
4 Subject: [PATCH] An all-in-one patch that fixes several issues:
6 1) UnscaledCycleClock not fully implemented for ppc*-musl (disabled on musl)
7 2) powerpc stacktrace implementation only works on glibc (disabled on musl)
8 3) powerpc stacktrace implementation has ppc64 assumptions (fixed)
13 Upstream-Status: Pending
14 Signed-off-by: Khem Raj <raj.khem@gmail.com>
15 Signed-off-by: Xu Huan <xuhuan.fnst@fujitsu.com>
16 Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
17 ---
[all …]
|
| /openbmc/docs/designs/mctp/ |
| 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
23 these; we currently have BT and KCS (both defined as part of the IPMI 2.0
27 attempted, but not in a cross-implementation manner so far. This does not
31 layer bindings for the actual transport of MCTP packets. These are defined by
40 
45 stack needing to be aware of the hardware implementation. These higher levels
46 only need to be aware that they are communicating with a certain entity, defined
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-kernel.md | 1 # OpenBMC in-kernel MCTP
8 This document describes a kernel-based implementation of MCTP infrastructure,
9 providing a sockets-based API for MCTP communication within an OpenBMC-based
12 # Requirements for a kernel implementation
14 - The MCTP messaging API should be an obvious application of the existing POSIX
17 - Configuration should be simple for a straightforward MCTP endpoint: a single
20 - Infrastructure should be flexible enough to allow for more complex MCTP
23 - each MCTP network (as defined by section 3.2.31 of DSP0236) may consist of
26 - multiple distinct (ie., non-bridged) networks, possibly containing
29 - multiple local EIDs on a single interface, and
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Control/ |
| H A D | VoltageRegulatorMode.interface.yaml | 3 Control.VoltageRegulatorProfile.Supported is read only. Implementation of
5 where the VR has a well defined default, implementations should place the
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/linux/Documentation/watchdog/ |
| H A D | mlx-wdt.rst | 16 Actual HW timeout can be defined as a power of 2 msec.
19 Get time-left isn't supported
22 Actual HW timeout is defined in sec. and it's the same as
23 a user-defined timeout.
25 Get time-left is supported.
31 Type 1 HW watchdog implementation exist in old systems and
33 Two types of HW implementation have also different register map.
35 Type 3 HW watchdog implementation can exist on all Mellanox systems
43 There are several actions that can be defined in the watchdog:
54 This mlx-wdt driver supports both HW watchdog implementations.
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/arm/ |
| H A D | arm,coresight-cti.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
4 ---
5 $id: http://devicetree.org/schemas/arm/arm,coresight-cti.yaml#
6 $schema: http://devicetree.org/meta-schemas/core.yaml#
21 number is defined at design time, the maximum of each defined in the DEVID
25 programmable channels, usually 4, but again implementation defined and
31 are implementation defined, except when the CTI is connected to an ARM v8
37 indicate this feature (arm,coresight-cti-v8-arch).
51 and usages. These can be defined along with the signal indexes with the
52 constants defined in <dt-bindings/arm/coresight-cti-dt.h>
[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/linux/tools/testing/selftests/powerpc/tm/ |
| H A D | tm.h | 1 /* SPDX-License-Identifier: GPL-2.0-only */
22 printf("PPC_FEATURE2_HTM not defined, can't check AT_HWCAP2\n"); in have_htm()
32 printf("PPC_FEATURE2_HTM_NOSC not defined, can't check AT_HWCAP2\n"); in have_htm_nosc()
38 * Transactional Memory was removed in ISA 3.1. A synthetic TM implementation
40 * synthetic implementation immediately fails after tbegin. This failure sets
41 * Bit 7 (Failure Persistent) and Bit 15 (Implementation-specific).
49 * times in case we got an Implementation-specific failure on a non ISA in htm_is_synthetic()
50 * v3.1 system. On these systems the Implementation-specific failure in htm_is_synthetic()
|
| /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 | event-logging.md | 3 Author: [Patrick Williams][patrick-email] `<stwcx>`
5 [patrick-email]: mailto:patrick@stwcx.xyz
13 There is currently not a consistent end-to-end error and event reporting design
15 primarily using phosphor-logging and one using rsyslog, both of which have gaps
17 end-to-end design handling both errors and tracing events which facilitate
30 be "DIMM-A0 encountered an uncorrectable ECC error" or "System boot successful".
36 temperature threshold exceeded: ["temperature threshold exceeded"][HPE-Example]
37 and ["Temperature #0x30 Upper Critical going high"][Oracle-Example]. There is
45 reference][Registry-Example] from the DMTF gives this example:
84 Within OpenBMC, there is currently a [limited design][existing-design] for this
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Inventory/Decorator/ |
| H A D | MeetsMinimumShipLevel.interface.yaml | 4 meet an implementation defined minimum level for shipment requirement.
11 - name: MeetsMinimumShipLevel
14 'The inventory item meets the implementation defined minimum ship
|
| /openbmc/linux/Documentation/networking/device_drivers/ethernet/altera/ |
| H A D | altera_tse.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 Altera Triple-Speed Ethernet MAC driver
9 Copyright |copy| 2008-2014 Altera Corporation
11 This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
24 The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP
31 Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The
36 The SGDMA component is to be deprecated in the near future (over the next 1-2
46 Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time.
47 Scatter-gather DMA will be added to a future maintenance update to this
60 Device Drivers ---> Network device support ---> Ethernet driver support --->
[all …]
|
| /openbmc/u-boot/arch/m68k/lib/ |
| H A D | cache.c | 1 // SPDX-License-Identifier: GPL-2.0+
16 /* Must be implemented for all M68k processors with copy-back data cache */ in flush_cache()
35 #if defined(CONFIG_CF_V4) || defined(CONFIG_CF_V4E) in icache_enable()
38 #if defined(CONFIG_CF_V4E) in icache_enable()
57 #if defined(CONFIG_CF_V4) || defined(CONFIG_CF_V4E) in icache_disable()
60 #if defined(CONFIG_CF_V4E) in icache_disable()
90 #if defined(CONFIG_CF_V4) || defined(CONFIG_CF_V4E) in dcache_enable()
93 #if defined(CONFIG_CF_V4E) in dcache_enable()
111 #if defined(CONFIG_CF_V4) || defined(CONFIG_CF_V4E) in dcache_disable()
114 #if defined(CONFIG_CF_V4E) in dcache_disable()
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | writing-monitor-commands.rst | 4 This document is a step-by-step guide on how to write new QMP commands using
8 into the QAPI framework implementation.
10 For an in-depth introduction to the QAPI framework, please refer to
11 :doc:`qapi-code-gen`. For the QMP protocol, see the
12 :doc:`/interop/qmp-spec`.
24 --------
34 added to the monitor/qmp-cmds.c file
47 -------
54 # qemu-system-TARGET [...] \
55 -chardev socket,id=qmp,port=4444,host=localhost,server=on \
[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
23 enum-format string is required to come from a parallel class
34 - name: Path
41 - xyz.openbmc_project.Common.File.Error.Open
42 - xyz.openbmc_project.Common.File.Error.Write
[all …]
|
| /openbmc/linux/arch/arm/include/asm/ |
| H A D | cp15.h | 1 /* SPDX-License-Identifier: GPL-2.0 */
14 #define CR_P (1 << 4) /* 32-bit exception handler */
15 #define CR_D (1 << 5) /* 32-bit data address range */
16 #define CR_L (1 << 6) /* Implementation defined */
20 #define CR_F (1 << 10) /* Implementation defined */
21 #define CR_Z (1 << 11) /* Implementation defined */
55 extern unsigned long cr_alignment; /* defined in entry-armv.S */
109 * read-only) is fine for most cases and saves quite some #ifdeffery.
|
| /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-power/phosphor-power-sequencer/docs/ |
| H A D | README.md | 1 # phosphor-power-sequencer
5 The phosphor-power-sequencer application powers the chassis on/off and monitors
14 The application is a single-threaded C++ executable. It is a 'daemon' process
18 The application is driven by an optional, system-specific JSON configuration
30 - UCD90160
31 - UCD90320
33 Additional device types can be supported by creating a new sub-class within the
38 - A BMC application or script sets the `state` property to 1 on the
39 `org.openbmc.control.Power` D-Bus interface.
40 - The phosphor-power-sequencer application writes the value 1 to the named GPIO
[all …]
|
| /openbmc/linux/include/uapi/linux/ |
| H A D | tee.h | 2 * Copyright (c) 2015-2016, Linaro Limited
52 #define TEE_MEMREF_NULL (__u64)(-1) /* NULL MemRef Buffer */
55 * TEE Implementation ID
61 * OP-TEE specific capabilities
66 * struct tee_ioctl_version_data - TEE version
67 * @impl_id: [out] TEE implementation id
68 * @impl_caps: [out] Implementation specific capabilities
69 * @gen_caps: [out] Generic capabilities, defined by TEE_GEN_CAPS_* above
71 * Identifies the TEE implementation, @impl_id is one of TEE_IMPL_ID_* above.
72 * @impl_caps is implementation specific, for example TEE_OPTEE_CAP_*
[all …]
|
| /openbmc/linux/Documentation/networking/caif/ |
| H A D | linux_caif.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 Copyright |copy| ST-Ericsson AB 2010
17 CAIF is a MUX protocol used by ST-Ericsson cellular modems for
22 ST-Ericsson modems support a number of transports between modem
29 The implementation of CAIF is divided into:
32 * CAIF Core Protocol Implementation
39 ! +------+ +------+
40 ! +------+! +------+!
42 +-------> !interf!+ ! API !+ <- CAIF Client APIs
43 ! +------+ +------!
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema-installed/ |
| H A D | Message.v1_3_0.json | 3 "$schema": "http://redfish.dmtf.org/schemas/v1/redfish-schema-v1.json",
4 …"copyright": "Copyright 2014-2024 DMTF. For the full DMTF copyright policy, see http://www.dmtf.or…
11 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
26 "description": "The human-readable message.",
27 "longDescription": "This property shall contain a human-readable message.",
42 …"longDescription": "This property shall contain a `MessageId`, as defined in the 'MessageId format…
49 …e. Services can replace the value defined in the message registry with a value more applicable to…
56 …operties contained in this object shall conform to the Redfish Specification-described requirement…
63 …"longDescription": "This property shall contain an array of RFC6901-defined JSON pointers indicati…
69 …tain the resolution of the message. Services can replace the resolution defined in the message re…
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/json-schema/ |
| H A D | Message.v1_3_0.json | 3 "$schema": "http://redfish.dmtf.org/schemas/v1/redfish-schema-v1.json",
4 …"copyright": "Copyright 2014-2024 DMTF. For the full DMTF copyright policy, see http://www.dmtf.or…
11 "^([a-zA-Z_][a-zA-Z0-9_]*)?@(odata|Redfish|Message)\\.[a-zA-Z_][a-zA-Z0-9_]*$": {
26 "description": "The human-readable message.",
27 "longDescription": "This property shall contain a human-readable message.",
42 …"longDescription": "This property shall contain a `MessageId`, as defined in the 'MessageId format…
49 …e. Services can replace the value defined in the message registry with a value more applicable to…
56 …operties contained in this object shall conform to the Redfish Specification-described requirement…
63 …"longDescription": "This property shall contain an array of RFC6901-defined JSON pointers indicati…
69 …tain the resolution of the message. Services can replace the resolution defined in the message re…
[all …]
|