| /openbmc/openbmc/poky/bitbake/doc/bitbake-user-manual/ |
| H A D | bitbake-user-manual-ref-variables-context.rst | 10 should only be used in global files like ``.conf``, while others are intended only
29 Those variables are usually configured globally.
34 There are variables:
36 - Like :term:`B` or :term:`T`, that are used to specify directories used by
37 BitBake during the build of a particular recipe. Those variables are
38 specified in ``bitbake.conf``. Some, like :term:`B`, are quite often
42 handled. Those are usually set by ``bitbake.conf`` and might get adapted in a
47 :term:`PERSISTENT_DIR`. Those are usually global.
54 Additionally, variables starting with ``BB`` configure how layers and files are
60 - The configured layers are contained in :term:`BBLAYERS` and files in
[all …]
|
| /openbmc/phosphor-inventory-manager/ |
| H A D | README.md | 15 The following top level YAML tags are supported:
22 Supported event tags are:
26 - type - The event type. Supported types are: _match_ and _startup_.
29 Subsequent tags are defined by the event type.
33 Supported match tags are:
40 Supported startup tags are:
46 Supported filter tags are:
50 Subsequent tags are defined by the filter type.
52 The available filters provided by PIM are:
64 Supported arguments for the propertyChangedTo filter are:
[all …]
|
| /openbmc/entity-manager/configurations/ |
| H A D | VENDORS.md | 11 when multiple companies are involved in the chain between design and end-user.
13 For purposes of this repository, the following prioritized guidelines are used
18 can include components which are exclusively sold to other enterprises for
23 which they exclusively label and sell, such as a server chassis, they are the
24 vendor for the assembled product and any sub-components which are exclusively
25 designed for and used by their assembled product(s). Sub-components that are
34 These guidelines are not meant to be exhaustive rules to cover all scenarios and
37 claims to be the vendor of a device, they probably are, unless there is strong
38 evidence they are not.
|
| /openbmc/openbmc/poky/documentation/ref-manual/ |
| H A D | release-process.rst | 9 information on how releases are named, their life cycle, and their
17 Here are examples of some major YP releases with their codenames
31 basis and are usually driven by the accumulation of enough significant
33 Some example past point releases are:
54 codename are likely to be compatible and thus work together.
58 Codenames are associated with major releases because a Yocto Project
60 company versioning scheme. Codenames are unique, interesting, and
63 Releases are given a nominal release version as well but the codename is
78 the current, in-development branch) are considered for backporting to a
84 bug fixes and security fixes only. Policy dictates that features are
[all …]
|
| /openbmc/bmcweb/docs/ |
| H A D | AGGREGATION.md | 4 satellite BMCs. Aggregated resources are accessed in the same way as local
8 The satellite BMCs are not aware that they are being aggregated. The aggregating
51 Aggregation is supported for all resources that are currently supported by
54 following are a few examples of top level collections:
66 it is assumed that the schemas are compatible.
73 are defined in the Redfish spec, but are not yet supported by bmcweb. Queries to
81 distinguish them from resources that are local to the aggregating BMC. The
98 Requests to top level collections are locally processed like normal by the
103 The responses are processed by first adding the aggregation prefix to the URIs
113 The following example shows how aggregated resources are added to a top level
[all …]
|
| /openbmc/phosphor-host-ipmid/docs/ |
| H A D | contributing.md | 18 Often, creating small commits this way results in a number of commits which are
20 push commits which are based on your change still in review. However, when
23 that topics which are not related to each other semantically are also not
24 related to each other in Git until they are merged into master.
37 `git commit --amend`, for which there are many guides online. As mentioned in
44 should be clearly written - even moreso than production code, unit tests are
54 - Concisely, _what_ change are you making? e.g. "docs: convert from US to UK
56 - Comprehensively, _why_ are you making that change? In some cases, like a small
68 Try to include the component you are changing at the front of your subject line;
70 are modifying. e.g. "apphandler: refactor foo to new API"
[all …]
|
| /openbmc/docs/ |
| H A D | CONTRIBUTING.md | 4 guidelines for contributing to an OpenBMC repository which are hosted in the
28 The BMC's interfaces to the external world are typically through a separate
31 These separate projects are then compiled into the final system by the overall
53 a look at the issues tagged with 'bitesize'. These are fixes or enhancements
54 that don't require extensive knowledge of the OpenBMC codebase, and are easier
65 you are interested in a particular repository - for example, "bmcweb" - type
74 upstream project. Otherwise, conventions are chosen based on the language.
100 E133, E226, E241, E242, E704, W503, and W504. These rules are ignored because
101 they are not unanimously accepted and PEP 8 does not enforce them. It is at the
148 If you are making a nontrivial change, you should plan how to introduce it to
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | build-system.rst | 12 The two general ways to perform a build are as follows:
44 firmware and tests. The results are written as either Makefile
55 which a same-named Meson option exists; dashes in the command line are
98 functioning. These are performed using a few more helper functions:
117 such checks are done at ``make`` time instead (see for example the
138 likewise, there are no options such as ``--meson`` or ``--sphinx-build``.
154 the dependencies are not present.
156 .. [#distlib] The scripts are created based on the package's metadata,
167 The required versions of the packages are stored in a configuration file
173 When dependencies are downloaded, instead, ``configure`` uses a "known
[all …]
|
| H A D | stable-process.rst | 9 QEMU stable releases are based upon the last released QEMU version
14 Usually, stable releases are only provided for the last major QEMU
16 stable releases are produced only until QEMU 2.12.0 is released, at
22 Generally, the following patches are considered stable material:
36 There are various ways to get a patch into stable:
38 * Preferred: Make sure that the stable maintainers are on copy when you send
47 patches that are stable candidates are tracked by the maintainers.
68 ``qemu-devel@nongnu.org`` for review. If any of your patches are included,
71 nominate other patches that you think are suitable for inclusion. After
|
| H A D | replay.rst | 12 Record/replay functions are used for the deterministic replay of qemu
23 E.g. network packets are written into the log when they arrive into the virtual
26 All non-deterministic events are coming from these devices. But to
65 system emulation. As it is important that batches of events are kept
67 while instruction checkpoints are written by the vCPU thread) we need
76 While the unlocks are usually in the reverse order, this is not
85 non-determinism. These are inputs from clock and peripheral devices,
89 Invocations of timers are coupled with clock reads and changing the state
95 Checkpoints here do not refer to virtual machine snapshots. They are just
110 Two functions are used for this purpose; because these actions change
[all …]
|
| /openbmc/openbmc/poky/bitbake/lib/bb/fetch2/ |
| H A D | README | 1 There are expectations of users of the fetcher code. This file attempts to document
2 some of the constraints that are present. Some are obvious, some are less so. It is
3 documented in the context of how OE uses it but the API calls are generic.
23 One specific pain point example are git tags. They can be replaced and change
37 i) versions are expected to be able to increase in a way which sorts allowing
44 k) Where fixes or changes to behaviour in the fetcher are made, we ask that
45 test cases are added (run with "bitbake-selftest bb.tests.fetch"). We do
|
| /openbmc/openbmc/meta-hpe/meta-dl385-g11/conf/templates/default/ |
| H A D | local.conf.sample | 3 # are placed. The comments in this file give some guide to the options a new user
9 # Lines starting with the '#' character are commented out and in some cases the
10 # default values are provided as comments to show people example syntax. Enabling
16 # You need to select a specific machine to target the build with. There are a selection
27 # There are also the following hardware board target machines included for
44 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
56 # and this option determines where those files are placed.
80 # The distribution setting controls which policy settings are used as defaults.
88 # where many versions are set to the absolute latest code from the upstream
98 # Options are:
[all …]
|
| /openbmc/qemu/target/hexagon/ |
| H A D | README | 6 The following versions of the Hexagon core are supported
19 Hexagon-specific code are
24 These files are imported with very little modification from archlib
65 By convention, the operands are identified by letter
67 RsV, RtV are source registers
70 hex_common.py) to determine the signature of the helper function. Here are the
118 C semantics are specified only with macros, we can override the default with
129 There are also cases where we brute force the TCG code generation.
130 Instructions with multiple definitions are examples. These require special
216 purposes. You will also notice there are sometimes two definitions of a macro.
[all …]
|
| /openbmc/docs/designs/ |
| H A D | design-template.md | 24 However you are free to prototype the implementation, but remember that you
39 - If you would like to provide a diagram with your spec, ASCII diagrams are
61 (1 paragraph) What are we doing and why? What problem are you trying to solve?
62 What are the goals and NON-goals? Please make the objective understandable for
70 related work inside and outside of OpenBMC. What other Open Source projects are
79 (2-5 paragraphs) What are the constraints for the problem you are trying to
80 solve? Who are the users of this solution? What is required to be produced? What
83 implementation. Roughly estimate relevant details. How big is the data? What are
98 (2 paragraphs) Include alternate design ideas here which you are leaning away
112 - Which repositories are expected to be modified to execute this design?
|
| /openbmc/openbmc/poky/meta/files/common-licenses/ |
| H A D | Net-SNMP | 15 …and binary forms, with or without modification, are permitted provided that the following conditio…
21 …IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO E…
25 …are copyright (c) 2001-2003, Cambridge Broadband Ltd. All rights reserved. Redistribution and use …
31 …IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO E…
41 Sun, Sun Microsystems, the Sun logo and Solaris are trademarks or registered trademarks of Sun Micr…
43 …and binary forms, with or without modification, are permitted provided that the following conditio…
51 …IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO E…
55 …and binary forms, with or without modification, are permitted provided that the following conditio…
61 …IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO E…
65 …and binary forms, with or without modification, are permitted provided that the following conditio…
[all …]
|
| H A D | Libpng | 42 libpng versions 1.0.7, July 1, 2000 through 1.6.35, July 15, 2018 are
43 Copyright (c) 2000-2002, 2004, 2006-2018 Glenn Randers-Pehrson, are
44 derived from libpng-1.0.6, and are distributed according to the same
68 files that are distributed with libpng have other copyright owners, and
69 are released under other open source licenses.
71 libpng versions 0.97, January 1998, through 1.0.6, March 20, 2000, are
72 Copyright (c) 1998-2000 Glenn Randers-Pehrson, are derived from
73 libpng-0.96, and are distributed according to the same disclaimer and
81 libpng versions 0.89, June 1996, through 0.96, May 1997, are
82 Copyright (c) 1996-1997 Andreas Dilger, are derived from libpng-0.88,
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | security.rst | 26 The following entities are untrusted, meaning that they may be buggy or
35 Bugs affecting these entities are evaluated on whether they can cause damage in
48 Bugs affecting the non-virtualization use case are not considered security
56 requirements are met.
85 The QEMU process should not have access to any resources that are inaccessible
94 In reality certain resources are inaccessible to the guest but must be
95 available to QEMU to perform its function. For example, host system calls are
96 necessary for QEMU but are not exposed to guests. A guest that escapes into
101 clearly documented so users are aware of the trade-off of enabling the feature.
106 Several isolation mechanisms are available to realize this architecture of
[all …]
|
| /openbmc/qemu/docs/about/ |
| H A D | build-platforms.rst | 7 platforms. This appendix outlines which platforms are the major build
8 targets. These platforms are used as the basis for deciding upon the
10 supported platforms are the targets for automated testing performed by
11 the project when patches are submitted for review, and tested before and
17 reports are welcome for problems encountered on unlisted platforms
18 unless they are clearly older vintage than what is described here.
38 Those hosts are officially supported, with various accelerators:
60 Other host architectures are not supported. It is possible to build QEMU system
78 are not considered, even when they are endorsed by the vendor (eg. Debian LTS);
107 Some of QEMU's build dependencies are written in Python. Usually these
[all …]
|
| /openbmc/docs/architecture/ |
| H A D | optionality.md | 5 new features are developed, to ensure stability of systems over time. With that
11 Linux kernel, systemd, sdbusplus, and phosphor object mapper. These features are
16 These are subsystems that, while widely applicable, a user might choose to
33 Theses are features that are broadly applicable to all all deployments of a
46 User opt-in features are features for which an external user must explicitly
48 they may be configurable at compile time, are not required to be configurable at
64 disabled. Note, there are cases where _removing_ a feature might cause user
70 Specific mechanisms to enable or disable these features are commonly:
|
| /openbmc/openbmc/meta-hpe/meta-dl360-g11/conf/templates/default/ |
| H A D | local.conf.sample | 3 # are placed. The comments in this file give some guide to the options a new user
11 # Lines starting with the '#' character are commented out and in some cases the
12 # default values are provided as comments to show people example syntax. Enabling
19 # You need to select a specific machine to target the build with. There are a selection
30 # There are also the following hardware board target machines included for
41 # These are some of the more commonly used values. Looking at the files in the
50 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
63 # and this option determines where those files are placed.
89 # The distribution setting controls which policy settings are used as defaults.
96 # where many versions are set to the absolute latest code from the upstream
[all …]
|
| /openbmc/openbmc/meta-hpe/meta-rl300-g11/conf/templates/default/ |
| H A D | local.conf.sample | 3 # are placed. The comments in this file give some guide to the options a new user
11 # Lines starting with the '#' character are commented out and in some cases the
12 # default values are provided as comments to show people example syntax. Enabling
19 # You need to select a specific machine to target the build with. There are a selection
30 # There are also the following hardware board target machines included for
41 # These are some of the more commonly used values. Looking at the files in the
50 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
63 # and this option determines where those files are placed.
89 # The distribution setting controls which policy settings are used as defaults.
96 # where many versions are set to the absolute latest code from the upstream
[all …]
|
| /openbmc/u-boot/doc/ |
| H A D | README.sched | 16 - There are NO primitives for thread synchronization (locking,
21 etc) are NOT saved.
27 - There are NO priorities, and the scheduling policy is round-robin
30 - There are NO capabilities to collect thread CPU usage, scheduler
33 - The semantics are somewhat based on those of pthreads, but NOT
36 - Only seven threads are allowed. These can be easily increased by
47 - There NOT enough safety checks as are probably in the other
|
| /openbmc/phosphor-fan-presence/docs/control/ |
| H A D | zones.md | 3 Zones are groups of fans that are set to the same values and have the same
5 [events.json](events.md) are then configured to operate on specific or all
43 interval are analyzed and if the highest requested target is greater than the
49 Optional with a default of zero, meaning increases are immediately requested.
57 inside of this interval are analyzed and if the highest requested target is
60 Optional with a default of zero, meaning decreases are immediately requested.
|
| /openbmc/openbmc/poky/meta-poky/conf/templates/default/ |
| H A D | local.conf.sample | 3 # are placed. The comments in this file give some guide to the options a new user
11 # Lines starting with the '#' character are commented out and in some cases the
12 # default values are provided as comments to show people example syntax. Enabling
19 # You need to select a specific machine to target the build with. There are a selection
30 # There are also the following hardware board target machines included for
41 # These are some of the more commonly used values. Looking at the files in the
50 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
63 # and this option determines where those files are placed.
89 # The distribution setting controls which policy settings are used as defaults.
96 # where many versions are set to the absolute latest code from the upstream
[all …]
|
| /openbmc/openbmc/meta-ufispace/meta-ncplite/conf/templates/default/ |
| H A D | local.conf.sample | 3 # are placed. The comments in this file give some guide to the options a new user
9 # Lines starting with the '#' character are commented out and in some cases the
10 # default values are provided as comments to show people example syntax. Enabling
17 # You need to select a specific machine to target the build with. There are a selection
28 # There are also the following hardware board target machines included for
44 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
57 # and this option determines where those files are placed.
83 # The distribution setting controls which policy settings are used as defaults.
90 # where many versions are set to the absolute latest code from the upstream
101 # Options are:
[all …]
|