| /openbmc/openbmc/meta-arm/meta-arm-bsp/recipes-kernel/linux/arm-platforms-kmeta/bsp/arm-platforms/ |
| H A D | juno.scc | 8 kconf hardware juno/juno-board.cfg
9 kconf hardware juno/juno-devfreq.cfg
10 kconf hardware juno/juno-dma.cfg
11 kconf hardware juno/juno-drm.cfg
12 kconf hardware juno/juno-fb.cfg
13 kconf hardware juno/juno-i2c.cfg
14 # kconf hardware juno/juno-mali-midgard.cfg
15 kconf hardware juno/juno-mmc.cfg
16 kconf hardware juno/juno-net.cfg
17 kconf hardware juno/juno-pci.cfg
[all …]
|
| H A D | fvp.scc | 6 kconf hardware fvp/fvp-board.cfg
7 kconf hardware fvp/fvp-net.cfg
8 kconf hardware fvp/fvp-rtc.cfg
9 kconf hardware fvp/fvp-serial.cfg
10 kconf hardware fvp/fvp-cfi.cfg
11 kconf hardware fvp/fvp-drm.cfg
12 kconf hardware fvp/fvp-watchdog.cfg
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/HardwareIsolation/ |
| H A D | Entry.interface.yaml | 2 Implement to provide the isolated hardware entry attributes.
6 example, isolated hardware inventory path and error log if it caused to
7 isolate hardware. The isolated hardware association of forward and reverse
14 isolated hardware object.
17 xyz.openbmc_project.Time.EpochTime for the isolated hardware creation time.
23 The severity of hardware isolation.
28 The isolated hardware resolution status is used to indicate whether
29 the isolated hardware is repaired or replaced. Setting this to "true"
31 isolated hardware entries may not be deleted and used for further
37 Possible severity for hardware isolation.
[all …]
|
| H A D | Create.interface.yaml | 4 the information of isolated hardware.
10 the hardware, needs to be isolated. This interface can be used if want
11 to isolate hardware without an error log, for example, the user
12 voluntarily tried to isolate hardware.
17 The hardware inventory path which is needs to isolate.
21 The severity of hardware isolation.
38 the hardware, needs to be isolated. This interface can be used if the
39 system wants to isolate hardware with an error log that is caused to
40 isolate hardware. This method is not going to create an error log and
47 The hardware inventory path which is needs to isolate.
[all …]
|
| /openbmc/openbmc/meta-ibm/recipes-phosphor/logging/ |
| H A D | phosphor-logging_%.bbappend | 5 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Rainier2U_dev_callouts.json"
6 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Rainier4U_dev_callouts.json"
7 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Everest_dev_callouts.json"
8 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Bonnell_dev_callouts.json"
9 SRC_URI:append:p10bmc = " file://com.ibm.Hardware.Chassis.Model.Balcones_dev_callouts.json"
10 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Raini…
11 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Raini…
12 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Evere…
13 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Bonne…
14 FILES:${PN}:append:p10bmc = " ${datadir}/phosphor-logging/pels/com.ibm.Hardware.Chassis.Model.Balco…
[all …]
|
| /openbmc/u-boot/include/ |
| H A D | hwspinlock.h | 11 * Hardware spinlocks are used to perform hardware protection of
18 * struct hwspinlock - A handle to (allowing control of) a single hardware
21 * @dev: The device which implements the hardware spinlock.
22 * @id: The hardware spinlock ID within the provider.
32 * hwspinlock_get_by_index - Get a hardware spinlock by integer index
34 * This looks up and request a hardware spinlock. The index is relative to the
35 * client device; each device is assumed to have n hardware spinlock associated
39 * @index: The index of the hardware spinlock to request, within the
40 * client's list of hardware spinlock.
41 * @hws: A pointer to a hardware spinlock struct to initialize.
[all …]
|
| /openbmc/docs/designs/ |
| H A D | error-log-handling-for-phal.md | 1 # Error handling for power Hardware Abstraction Layer (pHAL)
12 power Hardware Abstraction Layer(pHAL) library calls to [Platform Event Log][1]
17 OpenBmc Applications use the pHAL layer for hardware access and hardware
18 initialization, any software/hardware error returned by the pHAL layer need to
24 refers to the action of "guarding" faulty hardware from impacting future system
25 operation. Callout points to a specific hardware with in the server that relates
35 3. libekb for hardware procedure execution
36 4. libpdbg for hardware access
44 pHAL: power Hardware Abstraction Layer. pHAL is group of libraries running in
45 BMC. These libraries are used by Open Power specific application for hardware
[all …]
|
| H A D | redfish-pcie.md | 35 from hardware. The consumer will retrieve and parse the D-Bus data to provide
42 gathering and caching PCIe hardware data and maintaining the D-Bus interfaces
43 and properties. The actual hardware mechanism that is used to gather the PCIe
44 hardware data will vary.
51 When reading hardware directly, the PCIe daemon must be aware of power state
52 changes and any BIOS timing requirements, so it can check for hardware changes,
66 Possible performance impact on the hardware-scanning and D-Bus updates. The
67 piece that implements hardware scanning should use mechanisms, such as caching
68 of the hardware configuration, to minimize the scanning time and updates to
|
| H A D | voltage-regulator-configuration.md | 14 dependent on the system type and rail type. Regulators have a hardware default
15 configuration that is defined by hardware engineers early in system design.
24 Hardware engineers must specify many low-level configuration values for a
29 Depending on the regulator type, the hardware engineer may enter the
33 non-volatile memory on the regulator. This provides the hardware/power-on
39 - New information found during hardware testing. For example, downstream
40 hardware requires a higher voltage or is drawing more current than expected.
41 - Hardware workarounds. Problems in the regulator hardware or related hardware
43 problem may be resolved in newer versions of the hardware, but firmware still
44 must support the older hardware. For this reason, hardware workarounds are
[all …]
|
| /openbmc/phosphor-dbus-interfaces/gen/com/meta/Hardware/ |
| H A D | meson.build | 10 sdbusplus_current_path = 'com/meta/Hardware'
13 'com/meta/Hardware/Anacapa__markdown'.underscorify(),
14 input: ['../../../../yaml/com/meta/Hardware/Anacapa.interface.yaml'],
27 'com/meta/Hardware/Anacapa',
35 'com/meta/Hardware/BMC__markdown'.underscorify(),
36 input: ['../../../../yaml/com/meta/Hardware/BMC.interface.yaml'],
49 'com/meta/Hardware/BMC',
57 'com/meta/Hardware/Catalina__markdown'.underscorify(),
58 input: ['../../../../yaml/com/meta/Hardware/Catalina.interface.yaml'],
71 'com/meta/Hardware/Catalina',
[all …]
|
| /openbmc/u-boot/drivers/hwspinlock/ |
| H A D | Kconfig | 1 menu "Hardware Spinlock Support"
4 bool "Enable U-Boot hardware spinlock support"
6 This option enables U-Boot hardware spinlock support
9 bool "Enable Hardware Spinlock support for Sandbox"
12 Enable hardware spinlock support in Sandbox. This is a dummy device that
17 bool "Enable Hardware Spinlock support for STM32"
20 Enable hardware spinlock support in STM32MP. Hardware spinlocks are
21 hardware mutex which provide a synchronisation mechanism for the
|
| /openbmc/openbmc-test-automation/gui/test/server_health/ |
| H A D | test_obmc_gui_hardware_status.robot | 3 Documentation Test OpenBMC GUI "Hardware status" sub-menu of "Server health".
29 [Documentation] Verify ability to select "Hardware status" sub-menu option
33 Wait Until Page Contains Hardware status
34 Page should contain All hardware in the system
38 [Documentation] Verify ability to export inventory from "Hardware status"
47 [Documentation] Verify search text input allowed from "Hardware status"
59 [Documentation] Verify search text allowed to clear from "Hardware status"
72 ... "Hardware status" sub-menu.
74 [Template] Verify Hardware Inventory Expand
92 Verify Hardware Inventory Expand
[all …]
|
| /openbmc/openbmc/poky/documentation/kernel-dev/ |
| H A D | concepts-appx.rst | 35 needs for targeted hardware.
337 Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
354 warnings, the system only reports missing "hardware" options as they
355 could result in a boot failure or indicate that important hardware is
358 To determine whether or not a given option is "hardware" or
359 "non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
360 files that classify individual or groups of options as either hardware
361 or non-hardware. To better show this, consider a situation where the
364 yocto-kernel-cache/features/drm-psb/hardware.cfg
365 yocto-kernel-cache/features/kgdb/hardware.cfg
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/com/ibm/Dump/Entry/ |
| H A D | Hardware.interface.yaml | 2 Implement this to add Hardware dump management.
4 Hardware dump is a collection hardware state information, including various
6 descriptive term for entire system termination by the hardware due to a
20 A unique id of the failing hardware unit which is causing the dump.
21 This ID could be used to identify the specific piece of hardware
|
| /openbmc/openbmc/poky/meta/recipes-core/busybox/files/ |
| H A D | hwclock.sh | 9 # Description: Set system clock to hardware clock, according to the UTC
13 # WARNING: If your hardware clock is not in UTC/GMT, this script
31 echo "Setting the System Clock using the Hardware Clock as reference..."
51 # Updates the Hardware Clock with the System Clock time.
52 # This will *override* any changes made to the Hardware Clock.
59 echo "Saving the System Clock time to the Hardware Clock..."
67 echo "Hardware Clock updated to `date`."
79 echo " start sets kernel (system) clock from hardware (RTC) clock" >&2
80 echo " stop and reload set hardware (RTC) clock from kernel (system) clock" >&2
|
| /openbmc/phosphor-dbus-interfaces/yaml/com/meta/Hardware/ |
| H A D | Yosemite5.interface.yaml | 3 supported hardware devices specific to the Yosemite5.
8 The compatible hardware strings for the SPI flash on Yosemite5.
14 The compatible hardware strings for the CPLD on Yosemite5.
22 The compatible hardware strings for the VR on Yosemite5.
44 The compatible hardware strings for the TPM on Yosemite5.
50 The compatible hardware strings for the HSC on Yosemite5.
|
| /openbmc/docs/ |
| H A D | hw-vendor-repos-policy.md | 1 # Hardware Vendor Repository Policy
25 Both hardware-specific and vendor-specific repositories should meet the
66 ### Hardware Specific Feature
68 A hardware vendor feature is defined as one of the following:
70 1. A function that is specific to the vendor hardware
71 - For example, PECI, FSI, hardware diagnostics (specific to the processor)
75 To add a hardware specific repository to OpenBMC, it should meet the following
81 Some hardware vendor features which have no real synergy with OpenBMC, for
92 2. A function that requires a specific hardware vendor feature
103 specific hardware families. For example, [OpenPOWER][openpower] was one of the
[all …]
|
| /openbmc/entity-manager/src/gpio-presence/ |
| H A D | README.md | 16 "Name": "com.meta.Hardware.Yv4.cable0",
22 "Name": "com.meta.Hardware.Yv4.ComputeCard",
28 "Name": "com.meta.Hardware.Yv4.SidecarExpansion",
34 "Name": "com.meta.Hardware.Yv4.AirBlocker",
40 "Name": "com.meta.Hardware.Yv4.fanboard0",
74 …"Probe": "xyz.openbmc_project.Inventory.Source.DevicePresence({'Name': 'com.meta.Hardware.Yv4.fanb…
80 This is what the gpio-presence daemon exposes on dbus when the hardware is
96 https://github.com/openbmc/docs/blob/master/designs/inventory/gpio-based-hardware-inventory.md
|
| /openbmc/docs/designs/inventory/ |
| H A D | gpio-based-hardware-inventory.md | 1 # GPIO based hardware inventory
139 …tion <br> xyz.openbmc_project.Configuration.GPIODeviceDetect <br> Name=com.meta.Hardware.Yv4.cable0
147 …pose <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
150 …e on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
163 …move <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
167 …e on <br>xyz.openbmc_project.Inventory.Source.DevicePresence <br> Name=com.meta.Hardware.Yv4.cable0
179 - 'gpio-presence-sensor' uses gpios to detect hardware
180 - 'gpio-presence-sensor' creates a dbus interface when it detects hardware
183 - EM exposes the new configuration for the detected hardware
187 - 'gpio-presence-sensor' detects that the hardware is gone
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.bus_vcxk | 24 The driver needs some defines to describe the target hardware:
28 base address of VCxK hardware memory
45 describes the acknowledge line from vcxk hardware
48 describes the enable line to vcxk hardware
51 describes the invert line to vcxk hardware
54 describes the reset line to vcxk hardware
57 describes the request line to vcxk hardware
|
| /openbmc/qemu/tests/migration-stress/guestperf/ |
| H A D | engine.py | 111 def _migrate(self, hardware, scenario, src, argument
191 hardware._mem *
224 if not hardware._dirty_ring_size:
342 def _get_common_args(self, hardware, tunnelled=False): argument
359 args.append("ramsize=%s" % hardware._mem)
370 "-m", str((hardware._mem * 1024) + 512),
371 "-smp", str(hardware._cpus),
373 if hardware._dirty_ring_size:
375 hardware._dirty_ring_size])
384 if hardware._prealloc_pages:
[all …]
|
| /openbmc/libmctp/ |
| H A D | README.md | 16 - you are providing your own hardware drivers for MCTP transports.
52 To initialise the MCTP stack with a single hardware bus:
55 - `binding = mctp_<binding>_init()`: Initialise a hardware binding
56 - `mctp_register_bus(mctp, binding, eid)`: Register the hardware binding with
74 libmctp implements basic support for bridging between two hardware bindings. In
82 hardware bindings
90 Hardware bindings provide a method for libmctp to send and receive packets
91 to/from hardware. A binding defines a hardware specific structure
97 /* hardware-specific members here... */
111 hardware-specific struct to the libmctp generic core struct
[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
11 for >255 sensors), as well as the hardware channels that IPMI typically uses.
26 Some efforts of improving the hardware transport mechanism of IPMI have been
44 I2C, PCI, Serial or custom hardware channel, without the higher layers of that
45 stack needing to be aware of the hardware implementation. These higher levels
59 typically smaller, and are what is sent over the hardware. Messages that are
60 larger than the hardware Maximum Transmit Unit (MTU) are split into individual
72 - Allow different hardware channels, as we have a wide variety of target
75 - Be usable over simple hardware implementations, but have a facility for higher
[all …]
|
| /openbmc/u-boot/drivers/crypto/ |
| H A D | Kconfig | 1 menu "Hardware crypto devices"
16 hardware. It should only be used when the ASPEED_HACE driver, which
19 Enabling this allows the use of SHA operations in hardware without
32 Enabling this allows the use of SHA operations in hardware without requiring the
42 Enabling this allows the use of ECC/RSA operations in hardware without requiring the
|
| /openbmc/openpower-pnor-code-mgmt/ |
| H A D | item_updater_main.cpp | 64 {"com.ibm.Hardware.Chassis.Model.Balcones"s, in main()
66 {"com.ibm.Hardware.Chassis.Model.BlueRidge2U"s, in main()
68 {"com.ibm.Hardware.Chassis.Model.BlueRidge4U"s, in main()
70 {"com.ibm.Hardware.Chassis.Model.BlueRidge1S4U"s, in main()
72 {"com.ibm.Hardware.Chassis.Model.Bonnell"s, {".BONNELL_XML"s, ".P10"s}}, in main()
73 {"com.ibm.Hardware.Chassis.Model.Everest"s, {".EVEREST_XML"s, ".P10"s}}, in main()
74 {"com.ibm.Hardware.Chassis.Model.Fuji"s, {".FUJI_XML"s, ".P10"s}}, in main()
75 {"com.ibm.Hardware.Chassis.Model.Rainier2U"s, in main()
77 {"com.ibm.Hardware.Chassis.Model.Rainier4U"s, in main()
79 {"com.ibm.Hardware.Chassis.Model.Rainier1S4U"s, in main()
|