| /openbmc/qemu/target/xtensa/core-dsp3400/ |
| H A D | core-matmap.h | 2 * xtensa/config/core-matmap.h -- Memory access and translation mapping
10 * information contained in the core-isa.h header file.
19 * XCHAL_ICACHE_SIZE (presence of I-cache)
20 * XCHAL_DCACHE_SIZE (presence of D-cache)
25 /* Copyright (c) 1999-2010 Tensilica Inc.
49 /*----------------------------------------------------------------------
51 ----------------------------------------------------------------------*/
54 /* Cache Attribute encodings -- lists of access modes for each cache attribute: */
108 * one is returned instead (eg. writethru instead of writeback,
112 #define XCHAL_CA_WRITETHRU 1 /* cache enabled (write-through) mode */
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/User/Ldap/ |
| H A D | Config.interface.yaml | 3 User.Ldap.Config interface on one or more objects must implement
7 - name: LDAPServerURI
12 - xyz.openbmc_project.Common.Error.InternalFailure
13 - xyz.openbmc_project.Common.Error.InvalidArgument
14 - xyz.openbmc_project.Common.Error.NoCACertificate
15 - name: LDAPBindDN
21 - xyz.openbmc_project.Common.Error.InternalFailure
22 - xyz.openbmc_project.Common.Error.InvalidArgument
23 - name: LDAPBindDNPassword
29 on the D-bus object itself. Implementation can use the given value and
[all …]
|
| /openbmc/docs/designs/ |
| H A D | vpd-collection.md | 5 Created: 2019-06-11
9 On OpenBMC, Vital Product Data (VPD) collection is limited to only one or two
10 Field Replaceable Units (FRUs) today - one example is the BMC FRU. On OpenPower
11 systems, the BMC also supports just one VPD format, the [OpenPower VPD] [1]
18 - Some of the VPD information such as FRU part number, serial number need to be
21 - Several use cases on the BMC require that the applications decide on a certain
26 - There are use cases for the BMC to send VPD data to the host
31 of certain parameters of the FRU (atypical - for FRUs that do not have an
39 Essentially, the IPZ VPD structure consists of key-value pairs called keywords.
47 laid out one after another.
[all …]
|
| H A D | physical-topology.md | 13 objects. For instance, one chassis can contain another, be powered by a set of
15 currently have a standard way to represent these types of relationships.
27 Changes to phosphor-dbus-interfaces documenting new Associations have been
28 [proposed](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/46806)
37 - Must represent one-to-many relationships from chassis inventory objects which:
38 - Connect to cables
39 - Contain other chassis and/or are contained by a chassis
40 - Contain storage drives
41 - Are cooled by fans
42 - Are powered by power supplies
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/ |
| H A D | Association.interface.yaml | 5 An object implementing Association describes a one way, one to many
10 - name: Endpoints
|
| /openbmc/u-boot/doc/ |
| H A D | README.dfutftp | 1 # SPDX-License-Identifier: GPL-2.0+
7 Device Firmware Upgrade (DFU) - extension to use TFTP
11 ----
22 --------
25 upgrading firmware (e.g. kernel, u-boot, rootfs, etc.)
29 possible to overcome the major problem of USB based DFU -
38 To utilize this feature, one needs to first enable support
42 The "dfu" command has been extended to support transfer via TFTP - one
47 As of this writing (SHA1:8d77576371381ade83de475bb639949b44941e8c v2015.10-rc2)
49 contemporary u-boot tree.
[all …]
|
| H A D | README.bloblist | 1 # SPDX-License-Identifier: GPL-2.0+
3 Blob Lists - bloblist
7 ------------
9 A bloblist provides a way to store collections of binary information (blobs) in
16 --------------------------------------
18 The bloblist is created when the first U-Boot component runs (often SPL,
20 can be accessed as needed. This provides a way to transfer state from one part
24 can be passed through to SPL and U-Boot proper, which can print a message
29 -----
38 ---------
[all …]
|
| /openbmc/qemu/docs/devel/migration/ |
| H A D | main.rst | 14 two times. I.e. it can only restore the state in one guest that has
15 the same devices that the one it was saved (this last requirement can
20 requested: migration. This means that QEMU is able to start in one
26 can take a while to move all state from one machine to another. Live
41 - tcp migration: do the migration using tcp sockets
42 - unix migration: do the migration using unix sockets
43 - exec migration: do the migration using the stdin/stdout through a process.
44 - fd migration: do the migration using a file descriptor that is
46 - file migration: do the migration using a file that is passed to QEMU
54 (see add-fd QMP command documentation). This method allows a
[all …]
|
| H A D | compatibility.rst | 5 ---------------------------------
10 The difficult one is when they are different versions.
15 - QEMU version
16 - machine type version
20 - qemu-system-x86_64 (v5.2), from now on qemu-5.2.
21 - qemu-system-x86_64 (v5.1), from now on qemu-5.1.
26 - pc-q35-5.2 (newer one in qemu-5.2) from now on pc-5.2
27 - pc-q35-5.1 (newer one in qemu-5.1) from now on pc-5.1
40 1 - qemu-5.2 -M pc-5.2 -> migrates to -> qemu-5.2 -M pc-5.2
45 2 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
[all …]
|
| /openbmc/phosphor-virtual-sensor/ |
| H A D | README.md | 1 # phosphor-virtual-sensor
3 phosphor-virtual-sensor reads the configuration file
4 `virtual_sensor_config.json` from one of three locations:
7 2. `/var/lib/phosphor-virtual-sensor`
8 3. `/usr/share/phosphor-virtual-sensor`
17 added this way can use any expression that is accepted by exprtk.
19 ## information to get a virtual sensor configuration from D-Bus
26 "Config": "D-Bus"
31 Sensors added this way can only use a set of restricted calculations. Currently
35 hardware configuration file in entity-manager. This method of adding a virtual
[all …]
|
| /openbmc/qemu/target/xtensa/core-de233_fpu/ |
| H A D | core-matmap.h | 2 * xtensa/config/core-matmap.h -- Memory access and translation mapping
10 * information contained in the core-isa.h header file.
19 * XCHAL_ICACHE_SIZE (presence of I-cache)
20 * XCHAL_DCACHE_SIZE (presence of D-cache)
25 /* Copyright (c) 1999-2020 Tensilica Inc.
49 /*----------------------------------------------------------------------
51 ----------------------------------------------------------------------*/
55 /* Cache Attribute encodings -- lists of access modes for each cache attribute: */
113 * one is returned instead (eg. writethru instead of writeback,
117 #define XCHAL_CA_WRITETHRU 11 /* cache enabled (write-through) mode */
[all …]
|
| /openbmc/openbmc/poky/meta/files/common-licenses/ |
| H A D | ClArtistic | 10 the Package in a more-or-less customary fashion, plus the right to make
43 the Copyright Holder. A Package modified in such a way shall still be
46 3. You may otherwise modify your copy of this Package in any way, provided
48 when you changed that file, and provided that you do at least ONE of the
60 c) rename any non-standard executables so the names do not conflict
62 a separate manual page for each non-standard executable that clearly
69 in some specific way.
73 executable form, provided that you do at least ONE of the following:
79 b) accompany the distribution with the machine-readable source of
82 c) give non-standard executables non-standard names, and clearly
[all …]
|
| H A D | NBPL-1.0 | 9 …users of the package the right to use and distribute the Package in a more-or-less customary fashi…
27 …e Public Domain or from the Copyright Holder. A Package modified in such a way shall still be cons…
29 … way, provided that you insert a prominent notice in each changed file stating how and when you ch…
35 …-standard executables so the names do not conflict with standard executables, which must also be p…
39 …this Package in object code or executable form, provided that you do at least ONE of the following:
43 …b) accompany the distribution with the machine-readable source of the Package with your modificati…
45 … accompany any non-standard executables with their corresponding Standard Version executables, giv…
53 … Paragraph 6, provided these subroutines do not change the language in any way that would cause it…
|
| H A D | OLDAP-1.1 | 10 …users of the package the right to use and distribute the Package in a more-or-less customary fashi…
28 …e Public Domain or from the Copyright Holder. A Package modified in such a way shall still be cons…
30 … way, provided that you insert a prominent notice in each changed file stating how and when you ch…
36 …-standard executables so the names do not conflict with standard executables, which must also be p…
40 …this Package in object code or executable form, provided that you do at least ONE of the following:
44 …b) accompany the distribution with the machine-readable source of the Package with your modificati…
46 … accompany any non-standard executables with their corresponding Standard Version executables, giv…
54 … Paragraph 6, provided these subroutines do not change the language in any way that would cause it…
|
| H A D | OLDAP-1.2 | 10 …users of the package the right to use and distribute the Package in a more-or-less customary fashi…
28 …e Public Domain or from the Copyright Holder. A Package modified in such a way shall still be cons…
30 … way, provided that you insert a prominent notice in each changed file stating how and when you ch…
36 …-standard executables so the names do not conflict with standard executables, which must also be p…
40 …this Package in object code or executable form, provided that you do at least ONE of the following:
44 …b) accompany the distribution with the machine-readable source of the Package with your modificati…
46 … accompany any non-standard executables with their corresponding Standard Version executables, giv…
54 … Paragraph 6, provided these subroutines do not change the language in any way that would cause it…
|
| H A D | OLDAP-1.3 | 4 Copyright 1998-1999, The OpenLDAP Foundation. All Rights Reserved.
10 …users of the package the right to use and distribute the Package in a more-or-less customary fashi…
28 …e Public Domain or from the Copyright Holder. A Package modified in such a way shall still be cons…
30 … way, provided that you insert a prominent notice in each changed file stating how and when you ch…
36 …-standard executables so the names do not conflict with standard executables, which must also be p…
40 …this Package in object code or executable form, provided that you do at least ONE of the following:
44 …b) accompany the distribution with the machine-readable source of the Package with your modificati…
46 … accompany any non-standard executables with their corresponding Standard Version executables, giv…
54 …rovided these subroutines do not change the behavior of the Package in any way that would cause it…
|
| /openbmc/qemu/docs/specs/ |
| H A D | ivshmem-spec.rst | 2 Device Specification for Inter-VM shared memory device
5 The Inter-VM shared memory device (ivshmem) is designed to share a
12 can obtain one from an ivshmem server.
27 --------
31 - BAR0 holds device registers (256 Byte MMIO)
32 - BAR1 holds MSI-X table and PBA (only ivshmem-doorbell)
33 - BAR2 maps the shared memory object
37 - If you only need the shared memory part, BAR2 suffices. This way,
41 - If you additionally need the capability for peers to interrupt each
50 IVPosition register (described below) to become non-negative before
[all …]
|
| /openbmc/qemu/scripts/coccinelle/ |
| H A D | errp-guard.cocci | 20 // spatch --sp-file scripts/coccinelle/errp-guard.cocci \
21 // --macro-file scripts/cocci-macro-file.h --in-place \
22 // --no-show-diff --max-width 80 FILES...
24 // Note: --max-width 80 is needed because coccinelle default is less
47 - Error **_errp
55 - _errp
61 // Add invocation of ERRP_GUARD() to errp-functions where // necessary
105 // Note, that even with one (or zero) Error * definition in the each
108 // simple way to match with help of coccinelle.
163 'one control flow: at {}:{} and then at {}:{}'.format(
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | bootindex.rst | 4 QEMU can tell QEMU-aware guest firmware (like the x86 PC BIOS)
6 A simple way to set this order is to use the ``-boot order=`` option,
19 not support ``-boot order=``; on those machines you must always
22 There is no way to set a ``bootindex`` property if you are using
23 a short-form option like ``-hda`` or ``-cdrom``, so to use
25 into long-form ``-drive`` and ``-device`` option pairs.
28 -------
33 .. parsed-literal::
35 |qemu_system| -drive file=disk1.img,if=none,id=disk1 \\
36 -device ide-hd,drive=disk1,bootindex=4 \\
[all …]
|
| /openbmc/u-boot/tools/binman/etype/ |
| H A D | u_boot_ucode.py | 1 # SPDX-License-Identifier: GPL-2.0+
5 # Entry-type module for a U-Boot binary with an embedded microcode pointer
13 """U-Boot microcode block
21 U-Boot on x86 needs a single block of microcode. This is collected from
26 the FSP sets up the SRAM / cache-as-RAM but does so in the call that
28 microcode the same way in U-Boot (even non-FSP platforms). This is that
31 platforms), or used to set up the microcode (for non-FSP platforms).
32 This all happens in the build system since it is the only way to get
35 There are two cases to handle. If there is only one microcode blob in
37 entry (u-boot-ucode) is empty. If there is more than one update, then
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | submitting-a-pull-request.rst | 1 .. _submitting-a-pull-request:
8 :ref:`submitting-a-patch`
18 threaded as follow-ups to the pull request itself. The simplest way to
19 do this is to use ``git format-patch --cover-letter`` to create the
21 details that ``git request-pull`` outputs.
25 ``--subject-prefix=PULL`` in your ``git format-patch`` command). This
27 if they are only CC'd on one email out of the set).
29 **Each patch must have your own Signed-off-by: line** as well as that of
34 **Don't forget to add Reviewed-by: and Acked-by: lines**. When other
39 you're updating patches manually or in some other way you'll need to
[all …]
|
| H A D | decodetree.rst | 18 immediates, and sub-opcodes.
20 In support of patterns, one may declare *fields*, *argument sets*, and
21 *formats*, each of which may be re-used to simplify further definitions.
33 For *unnamed_field*, the first number is the least-significant bit position
54 In this way one can define disjoint fields.
59 One may use ``!function`` with zero ``fields``. This case is called
67 +---------------------------+---------------------------------------------+
71 +---------------------------+---------------------------------------------+
73 +---------------------------+---------------------------------------------+
77 +---------------------------+---------------------------------------------+
[all …]
|
| /openbmc/u-boot/board/freescale/bsc9131rdb/ |
| H A D | README | 2 --------
3 - BSC9131 is integrated device that targets Femto base station market.
5 technologies with MAPLE-B2F baseband acceleration processing elements.
6 - It's MAPLE disabled personality is called 9231.
9 . Power Architecture subsystem including a e500 processor with 256-Kbyte shared
11 . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache
13 Processing (MAPLE-B2F)
14 . A multi-standard baseband algorithm accelerator for Channel Decoding/Encoding,
20 . DDR3/3L memory interface with 32-bit data width without ECC and 16-bit with
21 ECC, up to 400-MHz clock/800 MHz data rate
[all …]
|
| /openbmc/openbmc/poky/meta/recipes-devtools/rsync/files/ |
| H A D | determism.patch | 8 "util.c" and "util2.c" sort before or after each other. In en_US.UTF-8
9 they sort one way, in C, they sort the other. The sorting order changes
15 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
18 Upstream-Status: Backport [ish, see below]
21 in a different way. This patch can be dropped when we upgrade to include:
23 ---
27 diff --git a/Makefile.in b/Makefile.in
29 --- a/Makefile.in
31 @@ -27,6 +27,11 @@ MKDIR_P=@MKDIR_P@
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/State/ |
| H A D | README.md | 5 The goal of the phosphor-state-manager repository is to control and track the
11 interfaces are designed in a way to support a many to many mappings of each
21 it's required target (Ready) or it's on it's way there (NotReady). Users can
32 power to the chassis. The Chassis being on is a pre-req to the Host being
34 to one or the other is implied by the transition not matching the current
66 In multi-host or multi-chassis system, instance number can be used from 1-N, as
72 In the future, OpenBMC will provide an association API, which allows one to
77 to the system as a whole as if it was a system with one BMC, one chassis and one
80 entities as if they are one (if at all possible).
88 multi-chassis system, starting counting from 1 rather than 0 would avoid this
[all …]
|