| /openbmc/linux/drivers/firmware/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only
4 # see Documentation/kbuild/kconfig-language.rst.
7 menu "Firmware Drivers"
9 source "drivers/firmware/arm_scmi/Kconfig"
12 tristate "ARM System Control and Power Interface (SCPI) Message Protocol"
16 System Control and Power Interface (SCPI) Message Protocol is
18 Cores(AP) and the System Control Processor(SCP). The MHU peripheral
19 provides a mechanism for inter-processor communication between SCP
25 certain system clocks configuration, thermal sensors and many
38 enabled or disabled via the SCP firmware
[all …]
|
| /openbmc/ipmitool/include/ipmitool/ |
| H A D | ipmi_sel.h | 22 * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED.
157 { 0xC0 , 0xFF , 0xff, IPMI_EVENT_CLASS_DISCRETE , "OEM Firmware Info", NULL },
158 { 0xC0 , 0xFF , 0xff, IPMI_EVENT_CLASS_DISCRETE , "OEM Firmware Info", NULL },
173 /* based on PICMG IPMB-0 Link state sensor */
174 { 0xC3 , 0x02 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "IPMB-L Link State", "IPMB L Disabled" },
175 { 0xC3 , 0x03 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "IPMB-L Link State", "IPMB L Enabled" },
197 …{ 0xC7 , 0x08 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "FWUM Status", "Firmware Watchdog Bite, reset oc…
208 { 0xCA , 0x00 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "Firmware Upgrade Status", "In progress"},
209 { 0xCA , 0x01 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "Firmware Upgrade Status", "Success"},
210 { 0xCA , 0x02 , 0xff, IPMI_EVENT_CLASS_DISCRETE , "Firmware Upgrade Status", "Failure"},
[all …]
|
| /openbmc/openbmc-test-automation/ipmi/ |
| H A D | test_ipmi_systeminfo_parameters.robot | 3 Documentation Module to test IPMI System Info Parameters functionality.
5 ... 1. Set In Progress - param 0,
6 ... 2. System Firmware Version - param 1,
7 ... 3. System Name - param 2,
8 ... 4. Primary OS Name - param 3,
9 ... 5. OS Name - param 4,
10 ... 6. Present OS Version Number - param 5.
33 Verify System Info Set In Progress
34 [Documentation] Verify Set In Progress of System Info Parameter,
35 ... to set the set-in-progress and set complete state via IPMI,
[all …]
|
| /openbmc/linux/Documentation/ABI/stable/ |
| H A D | sysfs-driver-firmware-zynqmp | 1 What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs*
9 by system to pass information between masters.
11 The register is reset during system or power-on
17 # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
18 # echo <value> > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
22 # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
23 # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0
27 What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs*
35 can be used by system to pass information between
38 This register is only reset by the power-on reset
[all …]
|
| /openbmc/linux/Documentation/arch/arm/keystone/ |
| H A D | knav-qmss.rst | 9 The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
10 the main hardware sub system which forms the backbone of the Keystone
11 multi-core Navigator. QMSS consist of queue managers, packed-data structure
15 management of the packet queues. Packets are queued/de-queued by writing or
29 Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
31 Accumulator QMSS queues using PDSP firmware
33 The QMSS PDSP firmware support accumulator channel that can monitor a single
37 1 or 32 queues per channel. More description on the firmware is available in
40 git://git.ti.com/keystone-rtos/qmss-lld.git
42 k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
[all …]
|
| /openbmc/linux/Documentation/driver-api/nvdimm/ |
| H A D | firmware-activate.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 NVDIMM Runtime Firmware Activation
7 Some persistent memory devices run a firmware locally on the device /
9 and health monitoring. The process of updating that firmware typically
10 involves a reboot because it has implications for in-flight memory
13 DSM specification [1], has added support for activating firmware at
17 to advertise and control their local runtime firmware activation
20 The libnvdimm bus object, ndbusX, implements an ndbusX/firmware/activate
21 attribute that shows the state of the firmware activation as one of 'idle',
24 - idle:
[all …]
|
| /openbmc/qemu/docs/system/arm/ |
| H A D | sbsa.rst | 1 Arm Server Base System Architecture Reference board (``sbsa-ref``)
4 The ``sbsa-ref`` board intends to look like real hardware (while the ``virt``
9 - `Base System Architecture <https://developer.arm.com/documentation/den0094/>`__ (BSA)
10 - `Server Base System Architecture <https://developer.arm.com/documentation/den0029/>`__ (SBSA)
13 specification defines how the firmware reports that to any operating system.
15 It is intended to be a machine for developing firmware and testing
21 The ``sbsa-ref`` board supports:
23 - A configurable number of AArch64 CPUs
24 - GIC version 3
25 - System bus AHCI controller
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | target-riscv.rst | 1 .. _RISC-V-System-emulator:
3 RISC-V System emulator
6 QEMU can emulate both 32-bit and 64-bit RISC-V CPUs. Use the
7 ``qemu-system-riscv64`` executable to simulate a 64-bit RISC-V machine,
8 ``qemu-system-riscv32`` executable to simulate a 32-bit RISC-V machine.
10 QEMU has generally good support for RISC-V guests. It has support for
12 RISC-V hardware is much more widely varying than x86 hardware. RISC-V
13 CPUs are generally built into "system-on-chip" (SoC) designs created by
23 ----------------------
25 For QEMU's RISC-V system emulation, you must specify which board
[all …]
|
| /openbmc/docs/designs/ |
| H A D | power-recovery.md | 11 Modern computer systems have a feature, automated power-on recovery, which in
12 essence is the ability to tell your system what to do when it hits issues with
13 power to the system. If the system had a black out (i.e. power was completely
14 cut to the system), should it automatically power the system on? Should it leave
15 it off? Or maybe the user would like the system to go to whichever state it was
19 occur. For example, some systems have op-panels, and on these op-panels there
22 situations, the user may wish for the system to not automatically power on the
23 system, because they want to debug the reason for the BMC error.
25 During blackout scenarios, system owners may have a set of services they need
27 to off in a blackout. OpenBMC needs to provide a mechanism for system owners to
[all …]
|
| H A D | redfish-resource-supplement-for-pfr.md | 1 # Redfish resource supplement for Platform Firmware Resilience (PFR)
7 Created: 2019-09-12
11 The platform is a collection of fundamental hardware and firmware components
12 needed to boot and operate a system. The Platform Firmware Resiliency(PFR) in
13 NIST SP 800-193 provides technical guidelines and recommendations supporting
14 resiliency of platform firmware and data against potentially destructive
21 represent the PFR provisioning status such as platform firmware is provisioned
27 Platform Firmware Resilience technology in NIST SP 800-93 provide common
35 - [NIST.SP.180-193](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf)
36 - [Redfish schema supplement](https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_…
[all …]
|
| H A D | fail-boot-on-hw-error.md | 12 firmware to halt a system if an error log is created which calls out a piece of
13 hardware. The reason behind this is to ensure a system is not shipped to a
16 If the system has a hardware issue once shipped from manufacturing, then the BMC
17 firmware behavior should be to report the error, but allow the system to
20 OpenBMC firmware needs a mechanism to support this use case.
26 which the firmware would then query. These registry variables were only settable
27 by someone with admin authority to the system. These flags were not used outside
30 Extensions within phosphor-logging may process logs that do not always come
31 through the standard phosphor-logging interfaces (for example logs sent down by
32 the host). In these cases the system must still halt if those logs contain
[all …]
|
| /openbmc/linux/drivers/acpi/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0
18 Linux requires an ACPI-compliant platform (hardware/firmware),
19 and assumes the presence of OS-directed configuration and power
25 the Plug-and-Play BIOS specification (PnP BIOS), the
35 ACPI is an open industry specification originally co-developed by
36 Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba. Currently,
67 Enable in-kernel debugging of AML facilities: statistics,
92 bool "ACPI Firmware Performance Data Table (FPDT) support"
95 Enable support for the Firmware Performance Data Table (FPDT).
96 This table provides information on the timing of the system
[all …]
|
| /openbmc/linux/Documentation/ABI/testing/ |
| H A D | sysfs-firmware-dmi-entries | 1 What: /sys/firmware/dmi/entries/
5 Many machines' firmware (x86 and ia64) export DMI /
6 SMBIOS tables to the operating system. Getting at this
17 length of the entry, as well as a firmware-provided
24 system unless they know for certain what their firmware
29 assigned by the operating system an 'instance', which is
34 entries "T-0" through "T-(N-1)":
38 /sys/firmware/dmi/entries/17-0
39 /sys/firmware/dmi/entries/17-1
40 /sys/firmware/dmi/entries/17-2
[all …]
|
| H A D | sysfs-firmware-opal-powercap | 1 What: /sys/firmware/opal/powercap
3 Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
7 power-cappable component.
9 What: /sys/firmware/opal/powercap/system-powercap
10 /sys/firmware/opal/powercap/system-powercap/powercap-min
11 /sys/firmware/opal/powercap/system-powercap/powercap-max
12 /sys/firmware/opal/powercap/system-powercap/powercap-current
14 Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
15 Description: System powercap directory and attributes applicable for
21 - powercap-min : This file provides the minimum
[all …]
|
| H A D | sysfs-firmware-gsmi | 1 What: /sys/firmware/gsmi
5 Some servers used internally at Google have firmware
9 historical reasons this different entry-point has been
13 these firmware callbacks. Currently, this functionality
14 is limited to handling the system event log and getting
15 access to EFI-style variables stored in nvram.
19 /sys/firmware/gsmi/vars:
22 underlying implementation as /sys/firmware/efi/vars.
23 See `Documentation/ABI/*/sysfs-firmware-efi-vars`
27 /sys/firmware/gsmi/append_to_eventlog - write-only:
[all …]
|
| H A D | sysfs-firmware-efi | 1 What: /sys/firmware/efi/fw_vendor
4 Description: It shows the physical address of firmware vendor field in the
5 EFI system table.
8 What: /sys/firmware/efi/runtime
12 the EFI system table.
15 What: /sys/firmware/efi/config_table
19 system table.
22 What: /sys/firmware/efi/systab
24 Contact: linux-efi@vger.kernel.org
26 Tables found via the EFI System Table. The order in
[all …]
|
| /openbmc/openbmc/meta-arm/kas/ |
| H A D | corstone1000-image-configuration.yml | 10 BBMULTICONFIG ?= "firmware"
16 # Telling the build system which image is responsible of the generation of the initramfs rootfs
17 INITRAMFS_IMAGE_BUNDLE:firmware = "1"
18 INITRAMFS_IMAGE:firmware ?= "corstone1000-recovery-image"
19 IMAGE_FSTYPES:firmware:pn-corstone1000-recovery-image = "${INITRAMFS_FSTYPES}"
20 IMAGE_NAME_SUFFIX:firmware = ""
23 INIT_MANAGER:firmware = "mdev-busybox"
24 VIRTUAL-RUNTIME_init_manager:firmware = "busybox"
27 PACKAGE_EXCLUDE:firmware += "kernel-image-*"
30 PACKAGECONFIG:remove:firmware:pn-kmod = "openssl"
[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 …]
|
| /openbmc/phosphor-power/phosphor-regulators/docs/config_file/ |
| H A D | README.md | 1 # phosphor-regulators Configuration File
5 - [Overview](#overview)
6 - [Data Format](#data-format)
7 - [Example](#example)
8 - [Name](#name)
9 - [Contents](#contents)
10 - [Validation](#validation)
11 - [Installation](#installation)
12 - [Loading and Reloading](#loading-and-reloading)
13 - [Testing](#testing)
[all …]
|
| /openbmc/phosphor-fan-presence/docs/control/ |
| H A D | README.md | 5 - [Overview](#overview)
6 - [Data Format](#data-format)
7 - [System Config Location](#system-config-location)
8 - [Contents](#contents)
9 - [Validation](#validation)
10 - [Firmware Updates](#firmware-updates)
11 - [Loading and Reloading](#loading-and-reloading)
12 - [Debug](#debug)
16 The `phosphor-fan-control` application is comprised of as set of configuration
26 ## System Config Location
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/remoteproc/ |
| H A D | ti,omap-remoteproc.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/remoteproc/ti,omap-remoteproc.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Suman Anna <s-anna@ti.com>
13 The OMAP family of SoCs usually have one or more slave processor sub-systems
14 that are used to offload some of the processor-intensive tasks, or to manage
15 other hardware accelerators, for achieving various system level goals.
17 The processor cores in the sub-system are usually behind an IOMMU, and may
18 contain additional sub-modules like Internal RAM and/or ROMs, L1 and/or L2
[all …]
|
| /openbmc/u-boot/doc/driver-model/ |
| H A D | fs_firmware_loader.txt | 3 # SPDX-License-Identifier: GPL-2.0
8 This is file system firmware loader for U-Boot framework, which has very close
9 to some Linux Firmware API. For the details of Linux Firmware API, you can refer
10 to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html.
12 File system firmware loader can be used to load whatever(firmware, image,
13 and binary) from the storage device in file system format into target location
17 To enable firmware loader, CONFIG_FS_LOADER need to be set at
20 Firmware Loader API core features
21 ---------------------------------
23 Firmware storage device described in device tree source
[all …]
|
| /openbmc/phosphor-fan-presence/docs/monitor/ |
| 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-monitor` application is controlled by a configuration file
22 non-functional due to fan hardware limitations.
[all …]
|
| /openbmc/linux/drivers/dax/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only
14 device. Platform firmware or a device driver may identify a
26 libnvdimm sub-system.
38 indication from platform firmware is meant to reserve the
40 device-dax instances for these memory ranges, and that also
43 "System RAM" pool.
52 CXL RAM regions are either mapped by platform-firmware
53 and published in the initial system-memory map as "System RAM", mapped
54 by platform-firmware as "Soft Reserved", or dynamically provisioned
55 after boot by the CXL driver. In the latter two cases a device-dax
[all …]
|
| /openbmc/u-boot/arch/arm/cpu/armv8/ |
| H A D | Kconfig | 15 bool "Enable multiple CPUs to enter into U-Boot"
20 Say Y here if there is not any trust firmware to set
21 CPUECTLR_EL1.SMPEN bit before U-Boot.
28 register may be controlled by EL3/EL2 firmware. To be more
29 precise, by default (if there is EL2/EL3 firmware running)
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:
[all …]
|