| /openbmc/u-boot/doc/ |
| H A D | README.POST | 28 2) The results of tests shall be saved so that it will be possible to
56 A new optional module will be added to U-Boot, which will run POST
57 tests and collect their results at boot time. Also, U-Boot will
61 The list of available POST tests will be configured at U-Boot build
62 time. The POST layer will allow the developer to add any custom POST
63 tests. All POST tests will be divided into the following groups:
67 This group will contain those tests that run only once on
72 This group will contain those tests that do not take much
77 This group will contain POST tests that consume much time
82 This group will contain those tests that can be run manually.
[all …]
|
| H A D | README.bootmenu | 27 menu entry will be selected automatically
34 <commands> are commands which will be executed when a menu
44 will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on
45 the console (or on the screen) and the command of the first menu entry will
46 be called immediately. If delay is less then 0, bootmenu will be shown and
47 autoboot will be disabled.
63 The above example will be rendered as below
81 Selected menu entry will be highlighted - it will have inverted
|
| /openbmc/docs/designs/oem/ibm/ |
| H A D | system-power-mode.md | 20 thermal monitoring and control. When a system is powered on, the OCCs will go to
21 an Active state. Anytime the OCC state changes to active, the BMC will need to
22 send a mode change and idle power saver (IPS) settings to the OCC. It will also
28 When a system is booted, the OCC will move to an ACTIVE state. In the ACTIVE
31 necessary to reset the OCC. When this happens, the OCC will move out of ACTIVE
32 state. After recovery, the OCC will be put back into the ACTIVE state. Anytime
34 runtime, the BMC will need to send the mode and the idle power saver settings to
40 Current Customer Settable System Power Modes that will be sent to the OCCs:
47 committee and will be used if/when approved.
57 Defaults will need to be configurable by the system owner (via JSON file)
[all …]
|
| /openbmc/phosphor-power/phosphor-power-sequencer/docs/ |
| H A D | power_loss.md | 24 `phosphor-power-sequencer` application will take no action.
27 device will normally change the chassis power good (pgood) signal from true to
28 false. `phosphor-power-sequencer` will isolate the failure to the power supply
29 rail. `phosphor-power-sequencer` will log a power supply error. This error will
37 The system loses all power. It will be completely off until utility power is
46 If the blackout affects all chassis, the system loses all power. It will behave
49 If the blackout only affects some chassis, the following steps will occur:
51 - The `phosphor-chassis-power` application will do the following:
56 - The `Available` property will be set to false for chassis that are
60 - If the BMC was reset by hardware due to the blackout, the following will
[all …]
|
| H A D | chassis_status.md | 59 When the system is being powered on, the `state` will be changed to 1 for the
65 that object path will change to 1. When all chassis whose `state` was set to 1
67 will change to 1.
70 `pgood` property for that chassis's object path will change to 0. The `pgood`
71 property for the system object path will remain set to 1 for a period of time.
72 Eventually the system will be powered off due to the power good fault. See
75 When the system is being powered off, the `state` will be changed to 0 for the
79 for that object path will change to 0. When all chassis have successfully
80 powered off, the `pgood` property for the system object path will change to 0.
97 property will be set.
[all …]
|
| /openbmc/openbmc/meta-arm/documentation/ |
| H A D | releases.md | 3 …e of the Yocto Project will have a branch named “dunfell” in the official git repository, and laye…
8 …will allow for a more stable software platform for software to be developed, tested, and released.…
14 … in a timely fashion (after the time crunch). Nagging emails will be sent and managers will be inv…
17 …ll code will be compiled as part of the CI process of the gerrit code review. Also, testing on vir…
20 …d branches for meta-arm will be released as close as possible to the release of the YP LTS release…
22 …will only be two active development branches at any given time: master and the most recent Long Te…
24 Named branch release will coincide with Yocto Project releases. These non-LTS branches will be bug …
27 When YP is approaching release, meta-arm will attempt to stabilize master so that the releases can …
30 …master branch. Previous named branches are now frozen and will not accept new patches (but will co…
34 …ag with the Yocto Project version number will be added. For example, `4.3`. Also, this tag versi…
[all …]
|
| /openbmc/docs/designs/ |
| H A D | power-recovery.md | 32 told) that chassis power can no longer be supported, but power to the BMC will
42 The goal of this design document is to describe how OpenBMC firmware will deal
66 - Do nothing when power is lost to the system (this will be the default)
77 policy. This is a separate instance of the `PowerRestorePolicy` which will be
79 setting is not the default, `None`, then software will execute the policy
92 - At a minimum, `PinholeReset` will be added. Others can be added as needed
103 this scenario after a BMC reboot, chassis-state-manager will check to see what
156 entire system is imminent(i.e. a blackout scenario where BMC will also lose
165 An application will be run after the chassis and host states have been
166 determined which will only run if the chassis power is not on.
[all …]
|
| H A D | bmc-reset-with-host-up.md | 69 - Both IPMI and PLDM stacks will give the host a set amount of time to respond.
70 Lack of response within this time limit will result in the BMC potentially
73 - IPMI and PLDM will implement a phosphor-dbus-interface interface,
74 `xyz.openbmc_project.Condition.HostFirmware`, which will have a
80 - IPMI will continue to utilize the SMS_ATN command to indicate to the host that
82 command, it will be considered up and running
86 - PLDM will utilize a GetTID command to the host to determine if it is running
87 - Where applicable, PLDM will provide a mechanism to distinguish between
91 firmware and talking PLDM but the BMC recovery paths will differ based on
107 IPMI and PLDM software will be started as applicable. A combination of systemd
[all …]
|
| H A D | fail-boot-on-hw-error.md | 52 - The chassis/host instance pair will not be allowed to power on until the log
54 - A BMC reset will clear this power on prevention
57 - These causes will be defined within the extensions documentation
60 **Special Note:** Initially the associated host and chassis will be hard coded
69 called QuiesceOnHwError. This property will be hosted under the
72 Define a new D-Bus interface which will indicate an error has been created which
73 will prevent the boot of a chassis/host instance:
76 This interface will be hosted under a instance based D-Bus object
80 When an error is created via a phosphor-logging interface, the software will
81 check to see if the error has a callout, and if so it will check the new
[all …]
|
| H A D | voltage-regulator-configuration.md | 103 A new application named `phosphor-regulators` will be created to configure
104 voltage regulators. The application will be located in the proposed new
107 _Statement of direction: This application will provide other regulator-based
112 The application will read a JSON file at runtime that defines the configuration
113 changes for all regulators. The JSON file will be specific to a system type, so
114 it will be stored in the GitHub repository for the appropriate build layer (such
123 directory. The application will search both directories, and the file in the
124 test directory will override the file in the standard directory. If the
125 application receives a SIGHUP signal, it will re-read the JSON file.
127 A document will be provided that describes the objects and properties that can
[all …]
|
| H A D | psu-firmware-update.md | 78 It will re-use the current interfaces to upload, verify, and activate the image.
90 3. There will be a new service that implements the [Activation][5] interface to
92 - The service will be started by default when BMC starts;
93 - On start, the service will check the PSU's existing firmware and create the
97 - When a new object with PSU `VersionPurpose` is added, the service will
101 - The service will have a configuration file to describe the PSU model and
103 - The service will find the matched vendor-specific tool to perform the code
105 `psu-update@foo.service` which executes `foo psu.bin`, the service will
111 the signature will be saved to a pre-defined directory in read-write
116 5. When the vendor-specific tool returns errors, the PSU update will be aborted
[all …]
|
| H A D | firmware-update-via-blobs.md | 66 Sending the firmware image over the BLOB protocol will be done via routing the
80 The BLOB protocol allows a handler to specify a list of blob ids. This list will
83 identify the mechanism selected by the client-side. The stat command will return
86 The blob ids for the mechanisms will be as follows:
94 The flash handler will determine what commands it should expect to receive and
95 responses it will return given the blob opened, based on the flags provided to
98 The flash handler will only allow one of the above blobs to be opened for a
109 The flash handler will only allow one open file at a time, such that if the host
113 There is only one hash "file" mechanism. The exact hash used will only be
114 important to your verification service. The value provided will be written to a
[all …]
|
| H A D | phosphor-hwmon-io-uring.md | 16 therefore may block other functions such as IPMI. This project will involve
38 By using io_uring, the asynchronous sensor reads will need to maintain the same
40 OpenBMC repositories that will benefit from this library include:
51 Users will need the ability to choose whether they want to utilize this new
54 io_uring library will need to be calculated for each daemon.
58 In the phosphor-hwmon repository, the primary files that will require
69 The refactor will maintain this loop over all sensors, but instead make the read
70 operation non-blocking by using an io_uring wrapper. A caching layer will be
71 used to store the read results, which will be the main access point for
114 sensor), users will be able to determine whether or not to utilize this new
[all …]
|
| H A D | vpd-collection.md | 12 format. As a part of its enterprise class servers, IBM will use the IPZ format
41 the SN keyword will contain a serial number that can uniquely identify an
56 specification does define it, but will need to use the ECC for IBM's
74 Some of the VPD will need to be exchanged with the host.
83 to synthesize VPD for such FRUs. Details on VPD synthesis will be in its own
128 updates will be made:
130 - Two new services will be created to handle the new VPD formats. ipz-vpd-parser
134 - Another service will be created to update the inventory with location code
139 - There will be one udev rule per EEPROM on the system from which the BMC has to
143 - Each udev rule will be setup to launch an instance of one of the VPD parser
[all …]
|
| H A D | target-fail-monitoring.md | 22 cases, the unit which caused the failure will log an error to phosphor-logging
24 ...), there will be no indication to the end user that something failed. It is
55 A systemd unit that is a service will only enter into a `failed` state after all
71 - This will be `timeout`,`failed`, and `dependency`
72 - Error will always be the configured one with additional data indicating the
106 Create a new standalone application in phosphor-state-manager which will load
139 On startup, all input json files will be loaded and monitoring will be setup.
141 This application will not register any interfaces on D-Bus but will subscribe to
142 systemd dbus signals for JobRemoved. sdeventplus will be used for all D-Bus
149 For service failures, a dump will be collected by default because the BMC will
[all …]
|
| /openbmc/phosphor-power/phosphor-regulators/docs/ |
| H A D | sensor_monitoring.md | 46 When regulator monitoring is disabled, the following changes will be made to all
49 - The Value property will be set to NaN.
50 - The Available property will be set to false.
56 - The error will be logged. If the same error occurs repeatedly on a rail, it
57 will only be logged once per system boot.
58 - Any remaining actions for the rail will be skipped.
59 - The following changes will be made to all D-Bus sensor objects for this rail:
60 - The Value property will be set to NaN.
61 - The Functional property will be set to false.
62 - Sensor monitoring will continue with the next rail or voltage regulator.
[all …]
|
| /openbmc/u-boot/drivers/serial/ |
| H A D | Kconfig | 44 the full UART driver will be omitted, thus saving space.
54 the full UART driver will be omitted, thus saving space.
64 the full UART driver will be omitted, thus saving space.
180 the drivers may conflict and you will get strange output.
183 prompt "Select which UART will provide the debug UART"
191 You will need to provide parameters to make this work. The driver will
198 You will need to provide parameters to make this work. The driver will
206 You will need to provide parameters to make this work. The
207 driver will be available until the real driver model serial is
215 You will need to provide parameters to make this work. The
[all …]
|
| /openbmc/openpower-hw-diags/attn/ |
| H A D | Attention_Handler.md | 24 attention handler will query the state of the host to determine the nature of
69 the host is started. When the attention handler is started it will register
71 resident in memory waiting for attentions. The attention handler will be stopped
74 If the attention handler terminates due to an error condition it will
81 When the attention signal becomes active the attention handler will begin
82 handling attentions. Using the PDBG interface the attention handler will query
84 enabled processor will be queried and a map of active attentions will be
85 created. The first attention of highest priority will be the one that is
94 dump. The attention handler will wait, up to one hour, for the dump to complete
113 will consider two cases namely a TI with SRC and a TI with EID.
[all …]
|
| /openbmc/qemu/include/io/ |
| H A D | channel-socket.h | 11 * This library is distributed in the hope that it will be useful,
90 * will run in the foreground so the caller will not regain
106 * context will be used.
109 * will run in the background so the caller will regain
111 * will be invoked on completion or failure. The @addr
112 * parameter will be copied, so may be freed as soon
131 * will run in the foreground so the caller will not regain
149 * context will be used.
152 * will run in the background so the caller will regain
154 * will be invoked on completion or failure. The @addr
[all …]
|
| /openbmc/entity-manager/ |
| H A D | Doxyfile | 9 # All text after a single hash (#) is considered a comment and will be ignored.
51 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
57 # into which the generated documentation will be written. If a relative path is
58 # entered, it will be relative to the location where doxygen was started. If
59 # left blank the current directory will be used.
63 # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
65 # will distribute the generated files over these directories. Enabling this
73 # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
75 # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
82 # documentation generated by doxygen is written. Doxygen will use this
[all …]
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-dbs/influxdb/influxdb/ |
| H A D | influxdb.conf | 6 # will change the value used at runtime when the process is restarted.
8 # Once every 24 hours InfluxDB will report usage data to usage.influxdata.com
50 # The amount of time that a write will wait before fsyncing. A duration
58 # recreated at startup. A value of "tsi1" will use a disk based index that supports higher
66 # Whether queries should be logged before execution. Very useful for troubleshooting, but will
71 # This setting will incur a small overhead because every key must be checked.
82 # CacheSnapshotMemorySize is the size at which the engine will
89 # which the engine will snapshot the cache and write it to
94 # will compact all TSM files in a shard if it hasn't received a
105 # will allow TSM compactions to write to disk. Note that short bursts are allowed
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | multi-process.rst | 51 A QEMU control process would remain, but in multi-process mode, will
85 parent object (such as "pci-device" for a PCI device) and QEMU will
195 emulation applications will need to include the QEMU block objects.
209 The remote emulation process will run the QEMU object hierarchy without
210 modification. The device emulation objects will be also be based on the
215 The processes will communicate with the QEMU process over UNIX domain
218 processes will provide are specified on its command line, as they would
237 The first argument to the remote emulation process will be a Unix domain
304 The proxy object model will use device proxy objects to replace the
305 device emulation code within the QEMU process. These objects will live
[all …]
|
| /openbmc/qemu/include/hw/ |
| H A D | ptimer.h | 17 * using ptimer_run(), the value will count downwards at the frequency
19 * When it reaches zero it will trigger a callback function, and
26 * When ptimer_transaction_commit() is called it will evaluate the state
32 * bug in the QEMU device and will cause warning messages to be printed
89 * ptimer_set_count() or ptimer_set_limit() will not trigger the timer
90 * (though it will cause a reload). Only a counter decrement to "0"
91 * will cause a trigger. Not compatible with NO_IMMEDIATE_TRIGGER;
92 * ptimer_init() will assert() that you don't set both.
108 * If a ptimer is created using this API then will use the
119 * is called it will evaluate the state of the timer after all the
[all …]
|
| /openbmc/bmcweb/redfish-core/include/ |
| H A D | error_messages.hpp | 77 * @param[in] arg1 Parameter of message that will replace %1 in its body.
89 * @param[in] arg1 Parameter of message that will replace %1 in its body.
101 * @param[in] arg1 Parameter of message that will replace %1 in its body.
102 * @param[in] arg2 Parameter of message that will replace %2 in its body.
116 * @param[in] arg1 Parameter of message that will replace %1 in its body.
117 * @param[in] arg2 Parameter of message that will replace %2 in its body.
131 * @param[in] arg1 Parameter of message that will replace %1 in its body.
132 * @param[in] arg2 Parameter of message that will replace %2 in its body.
146 * @param[in] arg1 Parameter of message that will replace %1 in its body.
147 * @param[in] arg2 Parameter of message that will replace %2 in its body.
[all …]
|
| /openbmc/phosphor-fan-presence/docs/control/ |
| H A D | events.md | 55 The trigger `init.get_properties` will, on fan control startup, read the Present
60 The trigger `signal.properties_changed` will watch for changes on the Present
64 The `count_state_before_target` action will look at the object cache value of
66 15000 when one or more of them is false. Otherwise, it will clear its fan target
88 The actions and triggers defined with this group will look at this D-Bus
93 The actions and triggers defined with this group will look at this D-Bus
105 will run.
138 member. When the signal occurs, the new property value will be added to or
143 signal occurs, the interface and its properties will be added to the object
148 the signal occurs, the interface and properties will be removed from the
[all …]
|