| /openbmc/qemu/docs/system/ |
| H A D | device-emulation.rst | 6 QEMU supports the emulation of a large number of devices from
7 peripherals such network cards and USB devices to integrated systems
10 used to describes devices within QEMU.
20 system is expecting to see. All devices can be specified with the
22 options ``--device help`` will list all devices it is aware of. Using
32 Most devices will exist on a BUS of some sort. Depending on the
35 can be inferred, for example PCI devices are generally automatically
41 Some devices, for example a PCI SCSI host controller, will add an
42 additional buses to the system that other devices can be attached to.
43 A hypothetical chain of devices might look like:
[all …]
|
| H A D | virtio-net-failover.rst | 6 is used to create a net_failover pair of devices.
8 The general idea is that we have a pair of devices, a (vfio-)pci and a
12 module will pair net devices with the same MAC address.
14 The two devices are called primary and standby device. The fast hardware based
21 Currently only PCIe devices are allowed as primary devices, this restriction
23 devices are allowed as primary device. The user needs to ensure that primary
24 and standby devices are not plugged into the same PCIe slot.
55 This is only for pairing the devices within QEMU. The guest kernel
56 module net_failover will match devices with identical MAC addresses.
69 failover primary devices are present in the configuration, migration
[all …]
|
| H A D | bootindex.rst | 5 which order it should look for a bootable OS on which devices.
8 property on the individual block or net devices you specify
12 firmware will consider devices for booting the guest OS. If the
14 boot priority. There is no particular order in which devices with no
51 Some firmware has limitations on which devices can be considered for
56 8 total devices, any number of which may be disks or virtio-net devices.
59 boot from to a boot method. It doesn't happen for devices the firmware
64 has three bootable devices target1, target3, target5 connected to it,
77 from the expected devices.
|
| /openbmc/entity-manager/src/entity_manager/ |
| H A D | devices.hpp | 7 namespace devices namespace
11 // driver creates a /sys/bus/i2c/devices/<busnum>-<i2caddr>/hwmon
14 // not reliable. I2C devices flagged with hasHWMonDir are tested for correct
19 // Devices such as I2C EEPROMs do not generate this file structure. These
20 // kinds of devices are flagged using the noHWMonDir enumeration. The
43 {{"EEPROM_24C01", "24c01 $Address", "/sys/bus/i2c/devices/i2c-$Bus",
45 {"EEPROM_24C02", "24c02 $Address", "/sys/bus/i2c/devices/i2c-$Bus",
47 {"EEPROM_24C04", "24c04 $Address", "/sys/bus/i2c/devices/i2c-$Bus",
49 {"EEPROM_24C08", "24c08 $Address", "/sys/bus/i2c/devices/i2c-$Bus",
51 {"EEPROM_24C16", "24c16 $Address", "/sys/bus/i2c/devices/i2
[all...] |
| /openbmc/openbmc/meta-facebook/meta-harma/recipes-phosphor/configuration/entity-manager/ |
| H A D | device-driver-probe | 29 echo pca9546 0x71 > /sys/bus/i2c/devices/i2c-9/new_device
32 echo pca9546 0x71 > /sys/bus/i2c/devices/i2c-11/new_device
43 echo adc128d818 0x1d > /sys/bus/i2c/devices/i2c-36/new_device
44 echo ina238 0x44 > /sys/bus/i2c/devices/i2c-36/new_device
45 echo ina238 0x45 > /sys/bus/i2c/devices/i2c-36/new_device
46 echo MCP9600 0x60 > /sys/bus/i2c/devices/i2c-34/new_device
47 echo MCP9600 0x62 > /sys/bus/i2c/devices/i2c-34/new_device
48 echo MCP9600 0x63 > /sys/bus/i2c/devices/i2c-34/new_device
49 echo MCP9600 0x64 > /sys/bus/i2c/devices/i2c-34/new_device
50 echo MCP9600 0x65 > /sys/bus/i2c/devices/i2c-34/new_device
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/src/ |
| H A D | chassis.hpp | 65 * @param devices Devices within this chassis, if any. The vector should
66 * contain regulator devices and any related devices required
70 std::vector<std::unique_ptr<Device>> devices = in Chassis() argument
73 devices{std::move(devices)}
90 * Clear any cached data about hardware devices.
105 * Close the devices within this chassis, if any.
112 * Configure the devices within this chassis, if any.
123 * Detect redundant phase faults in regulator devices in this chassis.
133 * Returns the devices within this chassis, if any.
135 * The vector contains regulator devices and any related devices
[all …]
|
| H A D | chassis.cpp | 26 // Add devices and their rails to the map in addToIDMap()
27 for (std::unique_ptr<Device>& device : devices) in addToIDMap()
36 for (std::unique_ptr<Device>& device : devices) in clearCache()
45 for (std::unique_ptr<Device>& device : devices) in clearErrorHistory()
55 "Closing devices in chassis " + std::to_string(number)); in closeDevices()
57 // Close devices in closeDevices()
58 for (std::unique_ptr<Device>& device : devices) in closeDevices()
70 // Configure devices in configure()
71 for (std::unique_ptr<Device>& device : devices) in configure()
80 for (std::unique_ptr<Device>& device : devices) in detectPhaseFaults()
[all …]
|
| /openbmc/qemu/docs/ |
| H A D | qdev-device-use.txt | 5 In qdev, each device has a parent bus. Some devices provide one or
10 where this address can be configured, devices provide a bus-specific
28 === Block Devices ===
34 of which can have up to two devices, and each device is a guest part,
41 The old ways to define block devices define host and guest part
70 * serial goes into DEV-OPTS, for devices supporting serial numbers.
71 For other devices, it goes nowhere.
95 As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
111 "Default Devices".
122 As for all PCI devices, you can add bus=PCI-BUS,addr=DEVFN to
[all …]
|
| H A D | bypass-iommu.txt | 7 devices in the system can only support go through vIOMMU or not, which
9 coexist of devices go through vIOMMU and devices not. This is useful to
10 passthrough devices with no-iommu mode and devices go through vIOMMU in
14 determine whether the devices attached on the PCI host bridge will bypass
16 virtual iommu in the system, it is implemented to allow some devices to
18 the attached devices will go through vIOMMU by default.
66 There might be potential security risk when devices bypass iommu, because
67 devices might send malicious dma request to virtual machine if there is no
76 space for devices bypass iommu.
79 RID mapping for devices which do not bypass iommu.
[all …]
|
| H A D | pcie.txt | 7 devices in PCI Express based machines and explains the reasoning behind
34 PCI Express devices should be plugged only into PCI Express Root Ports and
39 Place only the following kinds of devices directly on the Root Complex:
40 (1) PCI Devices (e.g. network card, graphics card, IDE controller),
41 not controllers. Place only legacy PCI devices on
45 Although the PCI Express spec does not forbid PCI Express devices as
47 devices with the Root Complex. Guest OSes are suspected to behave
48 strangely when PCI Express devices are integrated
81 A PCI Express Root bus supports up to 32 devices. Since each
86 Prefer grouping PCI Express Root Ports into multi-function devices
[all …]
|
| /openbmc/u-boot/drivers/block/ |
| H A D | Kconfig | 2 bool "Support block devices"
6 Enable support for block devices, such as SCSI, MMC and USB
9 devices often have a partition table which allows the device to
16 Some devices require block support whether or not DM is enabled
19 bool "Support block devices in SPL"
23 Enable support for block devices, such as SCSI, MMC and USB
26 devices often have a partition table which allows the device to
31 bool "Support block devices in TPL"
35 Enable support for block devices, such as SCSI, MMC and USB
38 devices often have a partition table which allows the device to
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | kconfig.rst | 16 Each QEMU target enables a subset of the boards, devices and buses that
27 include all the required dependencies and all the devices that the
31 of boards or devices. For example, by default most targets will include
32 all emulated PCI devices that QEMU supports, but the build process is
156 **devices**
166 Devices are the most complex of the five. They can have a variety
168 all the devices that can be accessed from QEMU.
170 Devices *depend on* the bus that they lie on, for example a PCI
172 have no ``depends on`` directive. Devices also *select* the buses
174 ``select SCSI``. Finally, devices are usually ``default y`` if and
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/test/ |
| H A D | chassis_tests.cpp | 92 std::vector<std::unique_ptr<Device>> devices{}; in TEST_F() local
93 devices.emplace_back(createDevice("vdd_reg1")); in TEST_F()
94 devices.emplace_back(createDevice("vdd_reg2")); in TEST_F()
97 Chassis chassis{1, defaultInventoryPath, std::move(devices)}; in TEST_F()
122 std::vector<std::unique_ptr<Device>> devices{}; in TEST_F() local
123 devices.emplace_back(createDevice("reg1", {"rail1"})); in TEST_F()
124 devices.emplace_back(createDevice("reg2", {"rail2a", "rail2b"})); in TEST_F()
125 devices.emplace_back(createDevice("reg3")); in TEST_F()
128 Chassis chassis{1, defaultInventoryPath, std::move(devices)}; in TEST_F()
134 // Verify all Devices are in the IDMap in TEST_F()
[all …]
|
| /openbmc/qemu/docs/system/devices/ |
| H A D | usb.rst | 5 plug virtual USB devices or real host USB devices (only works with
7 connect virtual USB hubs as necessary to connect multiple USB devices.
23 XHCI supports USB 1.1, USB 2.0 and USB 3.0 devices, so this is the
26 need to use the bus= parameter when adding USB devices.
32 The QEMU EHCI Adapter supports USB 2.0 devices. It can be used either
34 devices. The companion controller setup is more convenient to use
36 1.1 devices. See next section for details.
39 controllers for USB 1.1 devices too. Each controller creates its own
42 the EHCI controller. Devices must be attached to the correct
55 When adding USB devices using the ``-device`` switch you can specify the
[all …]
|
| /openbmc/qemu/include/hw/mem/ |
| H A D | memory-device.h | 33 * All memory devices need to implement TYPE_MEMORY_DEVICE as an interface.
41 * configurations. Such devices can logically get (un)plugged, however,
42 * empty memory devices are mostly ignored by the memory device code.
44 * Conceptually, memory devices only span one memory region. If multiple
47 * devices.
68 * all memory devices mapped into guest physical address space.
90 * This is helpful for devices that dynamically manage the amount of
92 * most devices, this corresponds to the size of the memory region.
117 * Optional for memory devices that require only a single memslot,
118 * required for all other memory devices: Return the number of memslots
[all …]
|
| /openbmc/dbus-sensors/src/mctp/ |
| H A D | MCTPDeviceRepository.hpp | 17 std::map<std::string, std::shared_ptr<MCTPDevice>> devices; member in MCTPDeviceRepository
22 return std::ranges::find_if(devices, pred); in lookup()
37 auto [entry, fresh] = devices.emplace(inventory, device); in add()
50 if (entry == devices.end()) in remove()
57 devices.erase(entry); in remove()
62 return lookup(device) != devices.end(); in contains()
69 if (entry == devices.end()) in inventoryFor()
78 auto entry = devices.find(inventory); in deviceFor()
79 if (entry == devices.end()) in deviceFor()
|
| /openbmc/u-boot/doc/ |
| H A D | README.virtio | 9 devices, including supported boards, build instructions, driver details etc.
23 spec. While VirtIO devices are commonly implemented as PCI devices on x86,
24 embedded devices models like ARM/RISC-V, which does not normally come with
32 network and block device, the most two commonly used devices, are supported.
55 You can even create a QEMU ARM target with VirtIO devices showing up on both
63 [*] PCI driver for virtio devices
75 VirtIO net and block devices on ARM.
83 On x86, command is slightly different to create PCI VirtIO devices.
91 Additional net and block devices can be created by appending more '-device'
92 parameters. It is also possible to specify both MMIO and PCI VirtIO devices.
[all …]
|
| H A D | README.uefi | 34 Support for attaching virtual block devices, e.g. iSCSI drives connected by the
170 are devices, drivers, and loaded images. These objects are referenced by
183 Devices offer the EFI_DEVICE_PATH_PROTOCOL. A device path is the concatenation
184 of device nodes. By their device paths all devices of a system are arranged in a
188 a driver to devices (which are referenced as controllers in this context).
228 The driver may create child controllers (child devices). E.g. a driver for block
229 IO devices will create the device handles for the partitions. The child
235 ## U-Boot devices mapped as UEFI devices
237 Some of the U-Boot devices are mapped as UEFI devices
239 * block IO devices
[all …]
|
| /openbmc/phosphor-host-ipmid/ |
| H A D | whitelist-filter.cpp | 40 void cacheRestrictedMode(const std::vector<std::string>& devices);
69 /** @brief Get RestrictionMode of the devices which has RestrictionMode support
71 * @param[in] devices - vector of devices object path
76 const std::vector<std::string>& devices) in cacheRestrictedMode() argument
82 for (auto& dev : devices) in cacheRestrictedMode()
109 size_t index = std::distance(&*std::begin(devices), &dev); in cacheRestrictedMode()
126 * @param[in] deviceList - map to store devices path and their index
168 /** @brief Get and Update RestrictionModes of supported devices
184 std::vector<std::string> devices; in postInit() local
187 devices = objects->map.at(restrictionModeIntf); in postInit()
[all …]
|
| /openbmc/u-boot/drivers/fpga/ |
| H A D | Kconfig | 12 This provides basic infrastructure to support Altera FPGA devices.
22 This provides common functionality for Gen5 and Arria10 devices.
30 This provides common functionality for Altera Cyclone II devices.
41 This provides common functionality for Altera Stratix 10 devices.
69 on Xilinx Zynq devices.
78 specific for Aspeed FPGA devices
|
| /openbmc/u-boot/drivers/usb/eth/ |
| H A D | Kconfig | 14 Ethernet Devices.
21 Ethernet Devices.
48 (7730/7830/7832) USB 2.0 Ethernet Devices.
55 USB Ethernet Devices. This driver also supports compatible devices
63 Ethernet Devices.
|
| /openbmc/openbmc/meta-openembedded/meta-python/recipes-extended/python-blivet/python3-blivet/ |
| H A D | 0006-tweak-btrfs-packages.patch | 13 blivet/devices/btrfs.py | 2 +-
17 diff --git a/blivet/devices/btrfs.py b/blivet/devices/btrfs.py
19 --- a/blivet/devices/btrfs.py
20 +++ b/blivet/devices/btrfs.py
23 """ Base class for BTRFS volume and sub-volume devices. """
|
| /openbmc/u-boot/drivers/timer/ |
| H A D | Kconfig | 47 Select this to enable a timer for AG01P devices.
53 Select this to enable a timer for Altera devices. Please find
70 Select this to enable timer for Aspeed ast2400/ast2500 devices.
88 Select this to enable a periodic interval timer for Atmel devices,
111 devices based on the MPC83xx family of SoCs.
127 Select this to enable an timer for Omap devices.
141 Rockchip devices.
155 Select this to enable a timer for STi devices.
162 STM32 devices.
175 MediaTek devices.
|
| /openbmc/qemu/docs/system/s390x/ |
| H A D | css.rst | 5 functionless) channel paths, and channel devices (virtio-ccw, 3270, and
6 devices passed via vfio-ccw). It supports multiple subchannel sets (MSS) and
9 All channel devices support the ``devno`` property, which takes a parameter
12 The default channel subsystem image id (``<cssid>``) is ``0xfe``. Devices in
14 enable MCSS-E. Note that devices with a different cssid will not be visible
19 Devices with a ssid that is not ``0`` will not be visible if the guest OS
42 In a Linux guest (without default devices and no other devices specified
|
| /openbmc/u-boot/doc/driver-model/ |
| H A D | usb-info.txt | 84 This holds information about a device on the bus. All devices have
94 as a work-around for controllers which can act as USB devices in OTG
118 one or more 'ports' to which additional devices can be attached. It is
119 possible to power up a hub and find out which of its ports have devices
122 Devices are given addresses starting at 1. The root hub is always address 1,
123 and from there the devices are numbered in sequence. The USB uclass takes
126 USB devices are enumerated by finding a device on a particular hub, and
131 very many devices.
133 Enumeration in U-Boot takes a long time since devices are probed one at a
137 Up to 127 devices can be on each bus. USB has four bus speeds: low
[all …]
|