| /openbmc/phosphor-power/phosphor-power-sequencer/docs/ |
| H A D | multiple_chassis.md | 5 A BMC-based system can contain one or more chassis. A chassis is typically a
6 physical enclosure that contains system components such as CPUs, fans, power
9 A chassis can be stand-alone, such as a tower or desktop. A chassis can also be
12 For the `phosphor-power-sequencer` application, the term "single chassis system"
13 means the system type has a maximum configuration of one chassis. If the system
15 "multiple chassis system" even if the current system only contains one chassis.
17 ## Differences between single and multiple chassis systems
19 ### System and chassis power state
21 In a single chassis system, the system and chassis power state are identical.
24 In a multiple chassis system, each chassis has its own power state. Even if the
[all …]
|
| H A D | power_loss.md | 5 Power distribution in a computer system is complex. It typically flows from a
6 wall outlet to power supplies to voltage regulators to system components. Other
14 processor and other system components have lost power.
18 In a multiple chassis system, a brownout or blackout might only occur in some of
21 ## System behavior during a brownout
24 `phosphor-power-sequencer` application will take no action.
28 false. `phosphor-power-sequencer` will isolate the failure to the power supply
29 rail. `phosphor-power-sequencer` will log a power supply error. This error will
33 ## System behavior during a blackout
35 ### Single chassis system
[all …]
|
| H A D | monitoring_chassis_pgood.md | 6 indicates that all of the main (non-standby) voltage rails are powered on.
8 The `phosphor-power-sequencer` application periodically reads (polls) the
22 `phosphor-power-sequencer` may become unable to read the chassis power good
25 - Hardware communication problems
26 - Unable to read from named GPIO after multiple retries.
27 - The `Available` property of the chassis changes to false.
31 If `phosphor-power-sequencer` is unable to read the chassis power good signal
34 - If this is a single chassis system:
35 - Log an error specifying the power on attempt failed due to an inability to
37 - `phosphor-chassis-state-manager` will [power off](powering_off.md) the
[all …]
|
| H A D | named_gpios.md | 5 The main (non-standby) voltage rails in a chassis are powered on or off by
8 The GPIO name is defined in the Linux device tree. For single chassis systems,
9 the standard GPIO name is `power-chassis-control`. See
10 … Naming in OpenBMC](https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md)
15 found for the current system, the standard GPIO name is used.
20 indicating whether all the main (non-standby) rails are powered on.
22 The `phosphor-power-sequencer` application reads the chassis power good signal
25 The GPIO name is defined in the Linux device tree. For single chassis systems,
26 the standard GPIO name is `power-chassis-good`. See
27 … Naming in OpenBMC](https://github.com/openbmc/docs/blob/master/designs/device-tree-gpio-naming.md)
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/docs/ |
| H A D | multiple_chassis.md | 5 A BMC-based system can contain one or more chassis. A chassis is typically a
6 physical enclosure that contains system components such as CPUs, fans, power
9 A chassis can be stand-alone, such as a tower or desktop. A chassis can also be
12 For the `phosphor-regulators` application, the term "single chassis system"
13 means the system type has a maximum configuration of one chassis. If the system
15 "multiple chassis system" even if the current system only contains one chassis.
17 `phosphor-regulators` only supports powering on and off the entire system. It
19 the system.
21 ## Defining the chassis in a system
25 to a physical chassis in the system.
[all …]
|
| H A D | internal_design.md | 5 - Manager
6 - Top level class created in `main()`.
7 - Loads the JSON configuration file.
8 - Implements the D-Bus `configure` and `monitor` methods.
9 - Contains a System object.
10 - System
11 - Represents the computer system being controlled and monitored by the BMC.
12 - Contains one or more Chassis objects.
13 - Chassis
14 - Represents a physical enclosure that can be powered on and off by the BMC.
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | gdb.rst | 4 ---------
6 QEMU supports working with gdb via gdb's remote-connection facility
8 way that you might with a low-level debug facility like JTAG
13 In order to use gdb, launch QEMU with the ``-s`` and ``-S`` options.
14 The ``-s`` option will make QEMU listen for an incoming connection
15 from gdb on TCP port 1234, and ``-S`` will make QEMU not start the
18 connection, use the ``-gdb dev`` option instead of ``-s``. See
21 .. parsed-literal::
23 |qemu_system| -s -S -kernel bzImage -drive file=rootdisk.img,format=raw -append "root=/dev/sda"
40 Here are some useful tips in order to use gdb on system code:
[all …]
|
| /openbmc/entity-manager/schemas/ |
| H A D | README.md | 8 configurations. This provides flexibility for system designers - the
10 in a single file, or can be organized into several smaller files. Thus, the top
11 most schema describes a single object or an array of objects.
17 ## A single entity manager configuration
29 `/xyz/openbmc_project/inventory/system/<Type>`. For a comprehensive list of
36 `/xyz/openbmc_project/inventory/system/<Type>/<Name>`. Additionally, any DBus
37 interfaces listed in openbmc-dbus.json will be added on
38 `/xyz/openbmc_project/inventory/system/<Type>/<Name>`.
55 `/xyz/openbmc_project/inventory/system/Board/RiserCard1/<Name>`:
70 /xyz/openbmc_project/inventory/system/Board/RiserCard1 add additional subschema
[all …]
|
| /openbmc/openpower-vpd-parser/vpd-manager/include/ |
| H A D | single_fab.hpp | 11 * @brief class to implement single fab feature.
13 * The class hosts functionalities required to support single FAB feature.
20 * @brief API to support single FAB feature.
24 * the system mode and image.
26 * System mode can be of field mode or lab mode and system image can be
29 * @return 0 on success, -1 in case of failure.
42 * @brief API to get IM value from system planar EEPROM path.
49 * @brief API to update IM value on system planar EEPROM path.
51 * @param[in] i_imValue - IM value to be updated.
65 * @brief API to update IM value on system planar EEPROM path to P11 series.
[all …]
|
| H A D | manager.hpp | 9 #include <oem-handler/ibm_handler.hpp>
17 * The class is responsible to implement methods to manage VPD on the system.
18 * It also implements methods to be exposed over D-Bus required to access/edit
34 * @param[in] ioCon - IO context.
35 * @param[in] iFace - interface to implement.
36 * @param[in] progressiFace - Interface to track collection progress.
37 * @param[in] connection - Dbus Connection.
54 * redundant path(s) if any taken from system config JSON.
62 * @param[in] i_vpdPath - Path (inventory object path/FRU EEPROM path).
63 * @param[in] i_paramsToWriteData - Input details.
[all …]
|
| /openbmc/openbmc/poky/documentation/dev-manual/ |
| H A D | speeding-up-build.rst | 1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
6 Build time can be an issue. By default, the build system uses simple
9 build times when dealing with single socket systems (i.e. a single CPU).
14 - :term:`BB_NUMBER_THREADS`:
17 - :term:`BB_NUMBER_PARSE_THREADS`:
20 - :term:`PARALLEL_MAKE`: Extra
22 :ref:`ref-tasks-compile` task in
25 - :term:`PARALLEL_MAKEINST`:
27 :ref:`ref-tasks-install` task in
31 available on the build system. For single socket systems, this
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Inventory/Item/ |
| H A D | Chassis.interface.yaml | 5 - name: Type
12 - name: ChassisType
16 - name: Blade
18 An enclosed or semi-enclosed, typically vertically-oriented,
19 system chassis that must be plugged into a multi-system chassis
21 - name: Component
25 - name: Enclosure
29 - name: Module
33 - name: RackMount
35 A single-system chassis designed specifically for mounting in an
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/com/ibm/VPD/ |
| H A D | Manager.interface.yaml | 2 Implement to manage VPD data in system.
4 - name: WriteKeyword
8 - name: path
11 Path to the D-Bus object that represents the FRU.
12 - name: record
16 - name: keyword
20 - name: value
25 - name: bytesUpdated
29 returns -1.
31 - xyz.openbmc_project.Common.Error.InvalidArgument
[all …]
|
| /openbmc/u-boot/drivers/mtd/spi/ |
| H A D | Kconfig | 11 supported by U-Boot. The uclass interface is defined in
45 to handle the common case when only a single serial
46 flash is present on the system.
49 int "SPI Flash default Chip-select"
54 to handle the common case when only a single serial
55 flash is present on the system.
63 to handle the common case when only a single serial
64 flash is present on the system.
72 to handle the common case when only a single serial
73 flash is present on the system.
[all …]
|
| /openbmc/qemu/docs/system/arm/ |
| H A D | xlnx-zynq.rst | 1 Xilinx Zynq board (``xilinx-zynq-a9``)
4 integrate a feature-rich dual or single-core Arm Cortex-A9 MPCore based
5 processing system (PS) and AMD programmable logic (PL) in a single device.
8 https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Zynq-7000-SoC-Technical-Reference-Manual
10 QEMU xilinx-zynq-a9 board supports following devices:
11 - A9 MPCORE
12 - cortex-a9
13 - GIC v1
14 - Generic timer
15 - wdt
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | multi-thread-tcg.rst | 2 Copyright (c) 2015-2020 Linaro Ltd.
5 later. See the COPYING file in the top-level directory.
10 Multi-threaded TCG
13 This document outlines the design for multi-threaded TCG (a.k.a MTTCG)
14 system-mode emulation. user-mode emulation has always mirrored the
16 changes done for MTTCG system emulation have improved the stability of
17 linux-user emulation.
19 The original system-mode TCG implementation was single threaded and
20 dealt with multiple CPUs with simple round-robin scheduling. This
22 being emulated gained additional cores and per-core performance gains
[all …]
|
| /openbmc/docs/designs/ |
| H A D | psu-monitoring.md | 7 Created: 2019-06-17
22 The OpenBMC project currently has a [witherspoon-pfault-analysis][1] repository
28 a single power supply application that can communicate with one or more
30 in the existing application that has multiple instances talking to a single
47 moved from the `phosphor-dbus-monitor` to this application, depending on if
49 system.
55 7. The power supply application must allow power supply hot-plug and concurrent
60 are present in the system, what type of power supply is present (maximum
71 the sysfs file system files updated via a PMBus device driver (currently
72 only known to be created and updated by the [ibm-cffps][4] device driver).
[all …]
|
| H A D | multihost-physical-led.md | 4 (Jayashree), [jayashree-d@hcl](mailto:jayashree-d@hcl.com)
12 The existing phosphor-led-sysfs design exposes one service per LED configuration
20 For example, Power LED and System Identification LED combines into a single
21 bicolor blue-yellow LED per host. A total of 4 × LEDs will be placed along the
26 or ON and other LEDs needs to be in OFF state. Therefore, bi-color LED needs to
29 Based on the current design in phosphor-led-sysfs application, pairing groups
31 and also to create LEDs under a single service, a new application is proposed.
38 KERNEL META-PHOSPHOR PHOSPHOR-LED-SYSFS SERVICE
40 +------------+ Event 1 +----------+ LED 1 +-----------------------------+
41 | |----------->| |-------->| |
[all …]
|
| /openbmc/debug-trigger/ |
| H A D | README.md | 3 `debug-trigger` listens for an external signal that the BMC is in some way
5 data and reboots the system in the hope that it will recover.
9 `debug-trigger` implements a simple protocol over an LPC KCS device as its
14 `debug-trigger` implements a single action once the trigger event is received,
15 which is to crash the kernel via `/proc/sysrq-trigger`. For systems with kdump
16 configured this results in collection of system state as context for why the
17 system was externally unresponsive.
|
| /openbmc/entity-manager/ |
| H A D | CONFIG_FORMAT.md | 12 - Configuration files will get replicated and built to support hundreds of
14 contrast, reactors tend to scale as a logarithm of system count, with each
15 new system supported adding fewer and fewer reactors. As such, pushing the
18 - Reactor writers tend to be domain experts on their subsystem, and
21 reactors on a single piece of hardware, and will generally have less
26 given piece of hardware in a single file, even at the risk of duplicating
28 - Hardware constraints, bugs, and oddities are generally found over time. The
33 - Having separate config files reduces the number of platforms that need to
37 - Having one config file per piece of hardware makes it much easier and clear
39 - Note: This is a "guideline" not a "rule". There are many cases of hardware
[all …]
|
| /openbmc/bmcweb/redfish-core/include/utils/ |
| H A D | systems_utils.hpp | 1 // SPDX-License-Identifier: Apache-2.0
2 // SPDX-FileCopyrightText: Copyright OpenBMC Authors
31 const boost::system::error_code& ec, in handleSystemCollectionMembers()
34 if (ec == boost::system::errc::io_error) in handleSystemCollectionMembers()
36 asyncResp->res.jsonValue["Members"] = nlohmann::json::array(); in handleSystemCollectionMembers()
37 asyncResp->res.jsonValue["Members@odata.count"] = 0; in handleSystemCollectionMembers()
44 messages::internalError(asyncResp->res); in handleSystemCollectionMembers()
48 nlohmann::json& membersArray = asyncResp->res.jsonValue["Members"]; in handleSystemCollectionMembers()
51 // consider an empty result as single-host, since single-host systems in handleSystemCollectionMembers()
55 asyncResp->res.jsonValue["Members@odata.count"] = 1; in handleSystemCollectionMembers()
[all …]
|
| /openbmc/openbmc/poky/documentation/toaster-manual/ |
| H A D | intro.rst | 1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
8 :term:`OpenEmbedded Build System`. The interface
19 - *Configure and Run Builds:* You can use the Toaster web interface to
22 are asked to select a release, or version of the build system you
27 - Browse layers listed in the various
28 :ref:`layer sources <toaster-manual/reference:layer source>`
32 - Browse images, recipes, and machines provided by those layers.
34 - Import your own layers for building.
36 - Add and remove layers from your configuration.
38 - Set configuration variables.
[all …]
|
| /openbmc/skeleton/pyinventorymgr/ |
| H A D | sync_inventory_items.py | 1 #!/usr/bin/python -u
9 # http://www.apache.org/licenses/LICENSE-2.0
61 # Only expecting a single service to implement
87 if path.split("/")[-1].find("_") < 0:
101 # Only expecting a single object to implement UUID.
107 # Only expecting a single service to implement
120 # Get the value of the mac on the system (from u-boot) without ':' separators
124 sys_mac = subprocess.check_output(["fw_printenv", "-n", "ethaddr"])
126 # Handle when mac does not exist in u-boot
131 # Replace the value of the system mac with the value of the inventory
[all …]
|
| /openbmc/phosphor-gpio-monitor/ |
| H A D | README.md | 5 ### `phosphor-gpio-monitor`
7 This daemon accepts a command line parameter for monitoring single gpio line and
9 monitoring single GPIO line, for multiple lines, user has to run this daemon
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
79 ### `phosphor-multi-gpio-presence`
81 This daemon accepts command line parameter as a well-defined GPIO configuration
[all …]
|
| /openbmc/phosphor-fan-presence/docs/presence/ |
| H A D | README.md | 5 - [Overview](#overview)
6 - [Data Format](#data-format)
7 - [Example](#example)
8 - [System Config Location](#system-config-location)
9 - [Contents](#contents)
10 - [Validation](#validation)
11 - [Firmware Updates](#firmware-updates)
12 - [Loading and Reloading](#loading-and-reloading)
16 The `phosphor-fan-presence-tach` application is controlled by a configuration
32 ## System Config Location
[all …]
|