| /openbmc/docs/designs/ |
| H A D | README.md | 3 This is a directory of design documents.
5 Newly authored design documents are encouraged to follow the
6 [design document template](design-template.md).
|
| H A D | design-template.md | 7 - Not all new features need a design document. If a feature can be contributed
9 areas, it doesn't need a design discussion and documentation.
17 design proposals compel the reviewers agree with the proposal's conclusions.
23 - You should get your design reviewed and merged before writing your code.
25 may learn of new requirements during the design review process that could
46 "design"
50 # Example design - this is the design title
74 glossary if necessary. Note: this is background; do not write about your design,
98 (2 paragraphs) Include alternate design ideas here which you are leaning away
99 from. Elaborate on why a design was considered and why the idea was rejected.
[all …]
|
| H A D | cper-records.md | 33 design, and passes the OpenBMC CI tests currently. This is the proposed branch
56 While this design fits into a much more elaborate design alluded to in the
62 might not meet all design goals for all contributors, having a common
65 Future design docs (or amendments to this design) will iterate on implementing
66 more of the design referenced in this [CPER specification][arm_sbmr], for common
68 the quality up to standards is the initial goal of this design.
72 Rewrite libcper decoding from a new design point. While this is certainly
85 - Which repositories are expected to be modified to execute this design?
99 design is complete.
|
| H A D | multihost-ipmi-design.md | 1 # Multi-host IPMI design
13 IPMI commands handling. We have a multi-host system and proposing the design to
62 IPMI commands handling. We have a multi-host system and proposing the design to
67 To address issue1 and issue2, we propose the following design changes in
193 to respond each host.The changes looks simple and no major design change from
194 the existing design. But many common handlers will be running as duplicate in
207 There may not be an impact in ipmid command handler functions.This design will
212 The proposed design can be tested in a platform in which the multiple hosts are
|
| H A D | liquid-leak-detection.md | 24 generic in its design and does not meet most of the requirements.
59 This design involves implementing following Redfish schemas and associated
130 [event logging design](https://github.com/openbmc/docs/blob/master/designs/event-logging.md).
143 The current design of the phosphor-gpio-monitor is too generic and does not meet
155 design. This would require implementation in the BMCWeb.
159 The design may cause a minor reduction in system performance due to the need for
166 - Which repositories are expected to be modified to execute this design? BMCWeb,
|
| H A D | expired-password.md | 61 This design uses meanings 3 and 4 except where indicated.
89 This design has three main parts:
122 session. The ipmitool is not being enhanced by this design.
131 - Redfish: This design adds the Redfish PasswordChangeRequired handling to
152 This design is intended to cover any cause of expired password, including both
156 This design is intended to enable the webui-vue web application to implement a
159 Per the above design, when the web app uses either `/login` or
206 Warning. This design may leave the BMC with its default password for an extended
207 period of time if the use case given in the requirements section of this design
211 design where the BMC is initially in a provisioning mode which does not allow
[all …]
|
| H A D | multihost-physical-led.md | 12 The existing phosphor-led-sysfs design exposes one service per LED configuration
29 Based on the current design in phosphor-led-sysfs application, pairing groups
35 The below diagram represents the overview for current physical LED design.
76 The existing design uses sysfs entry as udev events for particular LED and
107 The below diagram represents the overview for proposed physical LED design.
135 This document proposes a new design for physical LED implementation.
232 The proposed design is tested in a multiple hosts platform.
|
| /openbmc/u-boot/board/avionic-design/tec/ |
| H A D | MAINTAINERS | 2 M: Alban Bedel <alban.bedel@avionic-design.de>
4 F: board/avionic-design/tec/
|
| H A D | Kconfig | 7 default "avionic-design"
|
| /openbmc/u-boot/board/avionic-design/plutux/ |
| H A D | MAINTAINERS | 2 M: Alban Bedel <alban.bedel@avionic-design.de>
4 F: board/avionic-design/plutux/
|
| H A D | Kconfig | 7 default "avionic-design"
|
| /openbmc/u-boot/board/avionic-design/medcom-wide/ |
| H A D | MAINTAINERS | 2 M: Alban Bedel <alban.bedel@avionic-design.de>
4 F: board/avionic-design/medcom-wide/
|
| H A D | Kconfig | 7 default "avionic-design"
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/VirtualMedia/ |
| H A D | README.md | 4 [openbmc/docs/designs/VirtualMedia.md][design].
6 [design]: https://github.com/openbmc/docs/blob/master/designs/VirtualMedia.md
|
| /openbmc/u-boot/board/avionic-design/tec-ng/ |
| H A D | MAINTAINERS | 2 M: Alban Bedel <alban.bedel@avionic-design.de>
4 F: board/avionic-design/tec-ng/
|
| H A D | Kconfig | 7 default "avionic-design"
|
| /openbmc/entity-manager/configurations/ |
| H A D | VENDORS.md | 7 In some cases a company might design a component (such as a network card),
11 when multiple companies are involved in the chain between design and end-user.
16 1. A company which primarily initiates and oversees the design, manufacture and
29 3. When one company primarily oversees the design but other companies
31 the company that primarily oversaw the design of the component would be the
|
| /openbmc/u-boot/arch/arm/mach-tegra/tegra20/ |
| H A D | Kconfig | 49 source "board/avionic-design/medcom-wide/Kconfig"
51 source "board/avionic-design/plutux/Kconfig"
53 source "board/avionic-design/tec/Kconfig"
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/BIOSConfig/ |
| H A D | README.md | 9 Please refer to the [design][design] for more details.
44 [design]:
|
| /openbmc/entity-manager/src/gpio-presence/ |
| H A D | README.md | 3 This program was originally implemented following the [design][].
7 See the full [design][] for more details.
95 [design]:
|
| /openbmc/telemetry/ |
| H A D | README.md | 7 This application is implementation of Telemetry proposed in OpenBMC design docs
24 1. [OpenBMC platform telemetry design](https://github.com/openbmc/docs/blob/master/designs/telemetr…
|
| /openbmc/webui-vue/.github/ISSUE_TEMPLATE/ |
| H A D | design-review.md | 3 about: Create story used to track design proposals and decisions
23 1. Each design iteration will have a comment section
|
| /openbmc/docs/designs/inventory/ |
| H A D | gpio-based-hardware-inventory.md | 19 gpios. This design focuses on those.
21 Connected entities detectable via other means are out of scope of this design.
25 The existing design for the gpio based cable presence is partially implemented
28 [existing design by Chu Lin](https://github.com/openbmc/docs/blob/879601d92becfa1dbc082f487abfb5e01…
118 The proposed design is to create a new daemon in the entity-manager repository,
412 - Comparing to Chu Lin's design, this design is not focused on the IPMI or
416 which was created as part of Chu Lin's design.
418 - Comparing to Chu Lin's design, this design does not directly provide a cable
422 - Comparing to Chu Lin's design, this design is not limited to cables.
430 - Which repositories are expected to be modified to execute this design?
|
| /openbmc/qemu/docs/system/ppc/ |
| H A D | embedded.rst | 8 - ``virtex-ml507`` Xilinx Virtex ML507 reference design
|
| /openbmc/phosphor-settingsd/ |
| H A D | README-settings-manager.md | 5 The settings manager has the following design goals:
22 Some of the design goals above are achieved via a policy file, which is written
|