| /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/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 …]
|
| H A D | plot.py | 450 hardware = report._hardware
491 """ % (hardware._cpus, hardware._mem,
492 ",".join(hardware._src_cpu_bind),
493 ",".join(hardware._src_mem_bind),
494 ",".join(hardware._dst_cpu_bind),
495 ",".join(hardware._dst_mem_bind),
496 "yes" if hardware._prealloc_pages else "no",
497 "yes" if hardware._locked_pages else "no",
498 "yes" if hardware._huge_pages else "no"))
|
| /openbmc/u-boot/drivers/hwspinlock/ |
| H A D | Kconfig | 4 bool "Enable U-Boot hardware spinlock support"
6 This option enables U-Boot hardware spinlock support
12 Enable hardware spinlock support in Sandbox. This is a dummy device that
20 Enable hardware spinlock support in STM32MP. Hardware spinlocks are
21 hardware mutex which provide a synchronisation mechanism for the
|
| /openbmc/docs/designs/ |
| H A D | error-log-handling-for-phal.md | 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
45 BMC. These libraries are used by Open Power specific application for hardware
58 HWP: Hardware procedure. A "black box" code module supplied by the hardware team
62 Device Tree: A device tree is a data structure describing the hardware
67 EKB: EKB library contains all the hardware procedures (HWP) for the specific
[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
|
| /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/openbmc/poky/meta/recipes-graphics/libva/ |
| H A D | libva.inc | 4 hardware (GPU) acceleration for video processing on Linux and UNIX \
8 Media Accelerator) series of GPU hardware, the API is however not \
9 limited to GPUs or Intel specific hardware, as other hardware and \
10 manufacturers can also freely use this API for hardware accelerated \
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-devtools/android-tools/android-tools/ |
| H A D | gitignore | 39 !/hardware/
40 !/hardware/libhardware/
41 !/hardware/libhardware/include/
42 !/hardware/libhardware/include/hardware/
|
| /openbmc/qemu/qapi/ |
| H A D | misc-arm.json | 11 # QEMU/KVM software version, but also decided by the hardware that the
17 # @emulated: whether current QEMU/hardware supports emulated GIC
20 # @kernel: whether current QEMU/hardware supports hardware accelerated
|
| /openbmc/webui-vue/src/views/HardwareStatus/Inventory/ |
| H A D | Inventory.vue | 155 'hardware-status-bmc-manager-complete',
161 'hardware-status-chassis-complete',
167 'hardware-status-dimm-slot-complete',
172 require('@/eventBus').default.$on('hardware-status-fans-complete', () =>
178 'hardware-status-power-supplies-complete',
184 'hardware-status-processors-complete',
190 'hardware-status-service-complete',
195 require('@/eventBus').default.$on('hardware-status-system-complete', () =>
201 'hardware-status-assembly-complete',
|
| /openbmc/openbmc/poky/documentation/kernel-dev/ |
| H A D | concepts-appx.rst | 35 needs for targeted hardware.
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
366 yocto-kernel-cache/ktypes/base/hardware.cfg
[all …]
|
| /openbmc/qemu/docs/system/arm/ |
| H A D | sbsa.rst | 4 The ``sbsa-ref`` board intends to look like real hardware (while the ``virt``
5 board is a generic board platform that doesn't match any real hardware).
7 The hardware part is defined by two specifications:
38 includes both internal hardware and parts affected by the qemu command line
40 to expect a certain hardware layout (as you would in a real machine).
45 QEMU provides the guest EL3 firmware with minimal information about hardware
49 It is information passed from QEMU to describe the information a hardware
|
| /openbmc/openbmc/meta-ibm/meta-fsp2/ |
| H A D | recipes.txt | 1 recipes-bsp - Anything with links to specific hardware or hardware configuration informati…
|
| /openbmc/openbmc/meta-nuvoton/ |
| H A D | recipes.txt | 1 recipes-bsp - Anything with links to specific hardware or hardware configuration informati…
|
| /openbmc/qemu/docs/devel/migration/ |
| H A D | uadk-compression.rst | 6 hardware acceleration of cryptographic and compression algorithms.
9 which enables hardware accelerators from different vendors that support SVA to
12 Currently, HiSilicon Kunpeng hardware accelerators have been registered with
14 algorithms using hardware accelerators instead of CPUs, freeing up CPU
22 the hardware accelerator to support SVA, and the operating system to support
25 vendors. A user can access the hardware accelerators by performing user-mode
101 Here's an example to enable UACCE with hardware accelerator in HiSilicon
119 on hardware accelerator devices, write permission should be provided to user.
|
| /openbmc/u-boot/drivers/crypto/ |
| H A D | Kconfig | 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/qemu/docs/system/ |
| H A D | target-arm.rst | 15 Arm hardware is much more widely varying than x86 hardware. Arm CPUs
20 small fraction of the Arm hardware ecosystem.
29 the hardware has), so typically you don't need to specify the CPU type
44 cares much less about the detail of the hardware.)
46 If you already have a system image or a kernel that works on hardware
55 bit of hardware, such as small amount of RAM, no PCI or other hard
58 real hardware and is designed for use in virtual machines. You'll
|
| H A D | target-riscv.rst | 12 RISC-V hardware is much more widely varying than x86 hardware. RISC-V
18 For most boards the CPU type is fixed (matching what the hardware has),
34 cares much less about the detail of the hardware.)
36 If you already have a system image or a kernel that works on hardware
45 bit of hardware, such as small amount of RAM, no PCI or other hard
48 real hardware and is designed for use in virtual machines. You'll
|
| /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
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
155 hardware binding to access char devices for IO.
|
| /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/docs/ |
| H A D | hw-vendor-repos-policy.md | 25 Both hardware-specific and vendor-specific repositories should meet the
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
108 OpenBMC in general is to be agnostic of the hardware it is managing, but that is
110 certain hardware.
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/docs/config_file/ |
| H A D | compare_vpd.md | 7 VPD is information that describes a hardware component. VPD is typically read
12 BMC applications and drivers are responsible for reading VPD from hardware
31 - The hardware component does not support the keyword.
32 - An error occurred while attempting to read VPD from the hardware component.
33 - The BMC cannot access the VPD due to the system hardware design, such as not
|
| /openbmc/openbmc/meta-arm/meta-arm-bsp/documentation/ |
| H A D | musca-b1.md | 4 For a description of the hardware, go to
7 For emulated hardware, go to
|