| /openbmc/qemu/docs/devel/ |
| H A D | kconfig.rst | 13 SCSI adapters. Arm, s390 and x86 boards can all present a virtio-blk
16 Each QEMU target enables a subset of the boards, devices and buses that
21 QEMU uses a simple domain-specific language to describe the dependencies
24 * new targets and boards can be added without knowing in detail the
27 include all the required dependencies and all the devices that the
30 * users can easily build reduced versions of QEMU that support only a subset
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
36 This domain-specific language is based on the Kconfig language that
41 is instead specified in per-target files under the ``configs/``
[all …]
|
| /openbmc/u-boot/common/spl/ |
| H A D | Kconfig | 17 If you want to build SPL as well as the normal image, say Y.
22 default y
25 supports MMC, NAND and YMODEM and other methods loading of U-Boot
29 bool "Pass hand-off information from SPL to U-Boot proper"
32 It is useful to be able to pass information from SPL to U-Boot
33 proper to preserve state that is known in SPL and is needed in U-Boot.
34 Enable this to locate the handoff information in U-Boot proper, early
35 in boot. It is available in gd->handoff. The state state is set up
44 This option can minilize the SPL size to compatible with AST2600-A0
48 bool "Pass hand-off information from SPL to U-Boot proper"
[all …]
|
| /openbmc/qemu/.gitlab-ci.d/custom-runners/ |
| H A D | ubuntu-22.04-aarch64.yml | 1 # All ubuntu-22.04 jobs should run successfully in an environment
2 # setup by the scripts/ci/setup/ubuntu/build-environment.yml task
3 # "Install basic packages to build QEMU on Ubuntu 22.04"
5 ubuntu-22.04-aarch64-all-linux-static:
8 stage: build
10 - ubuntu_22.04
11 - aarch64
13 - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ /^staging/'
14 - if: "$AARCH64_RUNNER_AVAILABLE"
16 - mkdir build
[all …]
|
| /openbmc/openbmc/poky/meta-yocto-bsp/ |
| H A D | README.hardware.md | 13 Support for additional devices is normally added by adding BSP layers to your
15 (BSP) Developer's Guide - documentation source is in documentation/bspguide or
18 Note that these reference BSPs use the linux-yocto kernel and in general don't
26 The following boards are supported by the meta-yocto-bsp layer:
28 * Texas Instruments Beaglebone (`beaglebone-yocto`)
29 * General 64-bit Arm SystemReady platforms (`genericarm64`)
30 * General IA platforms (`genericx86` and `genericx86-64`)
38 Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/
44 git send-email -M -1 --to poky@lists.yoctoproject.org
46 Send pull requests, patches, comments or questions about meta-yocto-bsp to
[all …]
|
| /openbmc/openbmc/poky/ |
| H A D | README.hardware.md | 13 Support for additional devices is normally added by adding BSP layers to your
15 (BSP) Developer's Guide - documentation source is in documentation/bspguide or
18 Note that these reference BSPs use the linux-yocto kernel and in general don't
26 The following boards are supported by the meta-yocto-bsp layer:
28 * Texas Instruments Beaglebone (`beaglebone-yocto`)
29 * General 64-bit Arm SystemReady platforms (`genericarm64`)
30 * General IA platforms (`genericx86` and `genericx86-64`)
38 Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/
44 git send-email -M -1 --to poky@lists.yoctoproject.org
46 Send pull requests, patches, comments or questions about meta-yocto-bsp to
[all …]
|
| /openbmc/qemu/docs/devel/testing/ |
| H A D | fuzzing.rst | 5 This document describes the virtual-device fuzzing infrastructure in QEMU and
9 ------
16 is an *in-process* fuzzer. For the developer, this means that it is their
17 responsibility to ensure that state is reset between fuzzing-runs.
20 --------------------
22 To build the fuzzers, install a recent version of clang:
24 Here, enable-asan and enable-ubsan are optional but they allow us to reliably
25 detect bugs such as out-of-bounds accesses, uses-after-free, double-frees
28 CC=clang-8 CXX=clang++-8 /path/to/configure \
29 --enable-fuzzing --enable-asan --enable-ubsan
[all …]
|
| /openbmc/qemu/docs/system/riscv/ |
| H A D | virt.rst | 8 real-world hardware.
10 Supported devices
11 -----------------
13 The ``virt`` machine supports the following devices:
17 * Platform-Level Interrupt Controller (PLIC)
22 * 8 virtio-mmio transport devices
26 The hypervisor extension has been enabled for the default CPU, so virtual
27 machines with hypervisor extension can simply be used without explicitly
31 ----------------------------------
34 which it passes to the guest, if there is no ``-dtb`` option. This provides
[all …]
|
| H A D | sifive_u.rst | 4 SiFive HiFive Unleashed Development Board is the ultimate RISC-V development
5 board featuring the Freedom U540 multi-core RISC-V processor.
7 Supported devices
8 -----------------
10 The ``sifive_u`` machine supports the following devices:
15 * Platform-Level Interrupt Controller (PLIC)
17 * L2 Loosely Integrated Memory (L2-LIM)
22 * 1 One-Time Programmable (OTP) memory with stored serial number
30 1 E51 core and 4 U54 core combination and the RISC-V core boots in 64-bit mode.
32 is also possible to create a 32-bit variant with the same peripherals except
[all …]
|
| /openbmc/qemu/docs/devel/migration/ |
| H A D | qpl-compression.rst | 4 The Intel Query Processing Library (Intel ``QPL``) is an open-source library to
8 The ``QPL`` compression relies on Intel In-Memory Analytics Accelerator(``IAA``)
21 +----------------+ +------------------+
22 | MultiFD Thread | |accel-config tool |
23 +-------+--------+ +--------+---------+
27 +-------+--------+ | Setup IAA
29 +-------+---+----+ |
31 | +-------------+-------+
33 | Devices +-----+-----+
35 | +-----+-----+
[all …]
|
| H A D | uadk-compression.rst | 4 UADK is a general-purpose user space accelerator framework that uses shared
8 UADK includes Unified/User-space-access-intended Accelerator Framework (UACCE),
24 different character devices with UACCE by using kernel-mode drivers of the
25 vendors. A user can access the hardware accelerators by performing user-mode
26 operations on the character devices.
30 +----------------------------------+
32 +----+------------------------+----+
35 +-------+--------+ +-------+-------+
37 +-------+--------+ +-------+-------+
41 | +--------+------+
[all …]
|
| /openbmc/qemu/docs/ |
| H A D | pcie_pci_bridge.txt | 6 PCIE-to-PCI bridge is a new method for legacy PCI
9 Previously Intel DMI-to-PCI bridge was used for this purpose.
10 But due to its strict limitations - no support of hot-plug,
11 no cross-platform and cross-architecture support - a new generic
12 PCIE-to-PCI bridge should now be used for any legacy PCI device usage
15 This generic PCIE-PCI bridge is a cross-platform device,
16 can be hot-plugged into appropriate root port (requires additional actions,
17 see 'PCIE-PCI bridge hot-plug' section),
18 and supports devices hot-plug into the bridge itself
21 Hot-plug of legacy PCI devices into the bridge
[all …]
|
| /openbmc/u-boot/arch/x86/ |
| H A D | Kconfig | 5 default "x86"
8 prompt "Run U-Boot in 32/64-bit mode"
9 default X86_RUN_32BIT
11 U-Boot can be built as a 32-bit binary which runs in 32-bit mode
12 even on 64-bit machines. In this case SPL is not used, and U-Boot
13 runs directly from the reset vector (via 16-bit start-up).
15 Alternatively it can be run as a 64-bit binary, thus requiring a
16 64-bit machine. In this case SPL runs in 32-bit mode (via 16-bit
17 start-up) then jumps to U-Boot in 64-bit mode.
19 For now, 32-bit mode is recommended, as 64-bit is still
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | introduction.rst | 7 ---------------------------
10 memory and emulated devices) to run a guest OS. It supports a number
14 .. list-table:: Supported Accelerators
15 :header-rows: 1
17 * - Accelerator
18 - Host OS
19 - Host Architectures
20 * - KVM
21 - Linux
22 - Arm (64 bit only), MIPS, PPC, RISC-V, s390x, x86
[all …]
|
| /openbmc/qemu/ |
| H A D | configure | 14 source_path=$(cd "$(dirname -- "$0")"; pwd)
16 if test "$PWD" -ef "$source_path"
18 echo "Using './build' as the directory for build output"
20 MARKER=build/auto-created-by-configure
22 if test -e build
24 if test -f $MARKER
26 rm -rf build
28 echo "ERROR: ./build dir already exists and was not previously created by configure"
33 if ! mkdir build || ! touch $MARKER
35 echo "ERROR: Could not create ./build directory. Check the permissions on"
[all …]
|
| /openbmc/u-boot/common/ |
| H A D | Kconfig | 25 Enable recording of boot time in SPL. To make this visible to U-Boot
27 information when SPL finishes and load it when U-Boot proper starts
34 Enable recording of boot time in SPL. To make this visible to U-Boot
36 information when TPL finishes and load it when U-Boot proper starts
44 This shows how long it took U-Boot to go through each stage of the
60 default 30
67 default 5
109 default 0
116 default 0x1000
129 Enabling this will make a U-Boot binary that is capable of being
[all …]
|
| /openbmc/openbmc/poky/documentation/test-manual/ |
| H A D | runtime-testing.rst | 1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
7 The OpenEmbedded build system makes available a series of automated
16 Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
28 ------------------------------
32 - *Set up to avoid interaction with sudo for networking:* To
35 - Add ``NOPASSWD`` for your user in ``/etc/sudoers`` either for all
36 commands or just for ``runqemu-ifup``. You must provide the full
45 - Manually configure a tap interface for your system.
47 - Run as root the script in ``scripts/runqemu-gen-tapdevs``, which
48 should generate a list of tap devices. This is the option
[all …]
|
| /openbmc/openbmc/poky/documentation/dev-manual/ |
| H A D | qemu.rst | 1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
18 built using the Yocto Project as just another task on your build system.
20 supported Yocto Project architectures without having actual hardware.
34 - `QEMU Website <https://wiki.qemu.org/Main_Page>`__\ *:* The official
37 - `Documentation <https://wiki.qemu.org/Manual>`__\ *:* The QEMU user
49 (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the
56 - If you cloned the ``poky`` repository or you downloaded and
57 unpacked a Yocto Project release tarball, you can source the build
58 environment script (i.e. :ref:`structure-core-script`)::
61 $ source oe-init-build-env
[all …]
|
| /openbmc/u-boot/ |
| H A D | README | 1 # SPDX-License-Identifier: GPL-2.0+
3 # (C) Copyright 2000 - 2013
9 This directory contains the source code for U-Boot, a boot loader for
15 The development of U-Boot is closely related to Linux: some parts of
37 scattered throughout the U-Boot source identifying the people or
41 actual U-Boot source tree; however, it can be created dynamically
51 U-Boot, you should send a message to the U-Boot mailing list at
52 <u-boot@lists.denx.de>. There is also an archive of previous traffic
53 on the mailing list - please search the archive before asking FAQ's.
54 Please see http://lists.denx.de/pipermail/u-boot and
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.x86 | 1 # SPDX-License-Identifier: GPL-2.0+
6 U-Boot on x86
9 This document describes the information about U-Boot running on x86 targets,
10 including supported boards, build instructions, todo list, etc.
13 ------
14 U-Boot supports running as a coreboot [1] payload on x86. So far only Link
17 most of the low-level details.
19 U-Boot is a main bootloader on Intel Edison board.
21 U-Boot also supports booting directly from x86 reset vector, without coreboot.
23 'bare metal', U-Boot acts like a BIOS replacement. The following platforms
[all …]
|
| /openbmc/openbmc/meta-raspberrypi/docs/ |
| H A D | extra-build-config.md | 1 # Optional build configuration
4 the build. We list here the ones that are closely related to this BSP or
6 <http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html>
21 GPU. ARM gets the remaining memory. Min 16. Default 64.
24 the 512MB RP. Overrides gpu_mem. Max 192. Default not set.
27 the 256MB RP. Overrides gpu_mem. Max 448. Default not set.
30 the 256MB/512MB RP. Overrides gpu_mem. Max 944. Default not set.
32 See: <https://www.raspberrypi.com/documentation/computers/config_txt.html#memory-options>
36 …default, each machine uses `vc4` for graphics. This will in turn sets mesa as provider for `gl` li…
50 See: <https://www.raspberrypi.com/documentation/computers/config_txt.html#licence-key-and-codec-opt…
[all …]
|
| /openbmc/openbmc/poky/meta-poky/conf/templates/default/ |
| H A D | local.conf.sample.extended | 13 # Default to setting automatically based on cpu count
19 #PARALLEL_MAKE ?= "-j 4"
21 # Default to setting automatically based on cpu count
22 #PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
24 # For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
34 # If you want to get an image based on directfb without x11 alter
40 # packages at build time using qemu-native. Disabling it (by setting it to 0)
41 # will save some build time at the expense of breaking i18n on devices with
45 # If GLIBC_SPLIT_LC_PACKAGES is set to a non-zero value, convert
46 # glibc-binary-localedata-XX-YY to be a meta package depending on
[all …]
|
| /openbmc/u-boot/tools/binman/ |
| H A D | README.entries | 5 be placed in an image one by one to build up a final firmware image. It is
15 ------------------------------------------------------
21 - filename: Filename of file to read into entry
22 - compress: Compression algorithm to use:
24 lz4: Use lz4 compression (via 'lz4' command-line utility)
27 default filename is often specified specified by the subclass. See for
28 example the 'u_boot' entry which provides the filename 'u-boot.bin'.
30 If compression is enabled, an extra 'uncomp-size' property is written to
31 the node (if enabled with -u) which provides the uncompressed size of the
36 Entry: blob-dtb: A blob that holds a device tree
[all …]
|
| /openbmc/qemu/.gitlab-ci.d/ |
| H A D | crossbuilds.yml | 2 - local: '/.gitlab-ci.d/crossbuild-template.yml'
4 cross-armhf-user:
7 job: armhf-debian-cross-container
9 IMAGE: debian-armhf-cross
11 cross-arm64-system:
14 job: arm64-debian-cross-container
16 IMAGE: debian-arm64-cross
18 cross-arm64-user:
21 job: arm64-debian-cross-container
23 IMAGE: debian-arm64-cross
[all …]
|
| /openbmc/qemu/docs/system/s390x/ |
| H A D | vfio-ap.rst | 7 ------------
11 These AP devices provide cryptographic functions to all CPUs assigned to a
19 -------------------------
51 An AP queue is the means by which an AP command-request message is sent to an
57 which the AP command-request message is to be sent for processing.
63 * NQAP: to enqueue an AP command-request message to a queue
64 * DQAP: to dequeue an AP command-reply message from a queue
73 ----------------------------------------------
84 an APID from 0-255. If a bit is set, the corresponding adapter is valid for
89 corresponds to an AP queue index (APQI) from 0-255. If a bit is set, the
[all …]
|
| /openbmc/phosphor-power/phosphor-power-sequencer/src/ |
| H A D | pmbus_driver_device.hpp | 8 * http://www.apache.org/licenses/LICENSE-2.0
12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
39 * StandardDevice sub-class for power sequencer devices that are bound to a
45 // Specify which compiler-generated methods we want
51 virtual ~PMBusDriverDevice() = default;
144 * Throws an exception if an error occurs trying to build the map.
181 * Build mapping from PMBus PAGE numbers to the hwmon file numbers in
191 * over time because power devices may have been added or removed.
193 * Throws an exception if an error occurs trying to build the map.
|