Author: Brandon Wyman !bjwyman
Primary assignee: Brandon Wyman
Other contributors: Derek Howard
Created: 2019-06-17
This is a proposal to provide a set of enhancements to the current OpenBMC power supply application for enterprise class systems. Some enterprise class systems may consist of a number of configuration variations including different power supply types and numbers. An application capable of communicating with the different power supplies is needed in order to initialize the power supplies, validate configurations, report invalid configurations, detect and report various faults, and report vital product data (VPD). Some of the function will be configurable to be included or excluded for use on different platforms.
The OpenBMC project currently has a witherspoon-pfault-analysis repository that contains a power supply monitor application and a power sequencer monitor application. The current power supply application is lacking things desired for an enterprise class server.
The intent of this new application design is to enhance the OpenBMC project with a single power supply application that can communicate with one or more PMBus power supplies and provide the enterprise features currently lacking in the existing application that has multiple instances talking to a single power supply.
Some of these requirements may be deemed as business specific logic, and thus could be configurable options as appropriate.
phosphor-dbus-monitor to this application, depending on if such function was already written or ported forward from a previously similar system.The proposal is to create a single new power supply application in the OpenBMC phosphor-power repository. The application would be written in C++17.
Upon startup, the power supply application would be passed a parameter consisting of the location of some kind of configuration file, some JSON format file. This file would contain information such as the D-Bus object name(s), possible power supply types, possible system types that the various power supplies are valid to be used in, I2C/PMBus file location data, read retries, deglitch counts, etc.
The power supply application would then detect which system type it is running on, which supplies are present, if the power supply is ready for reading VPD information, what type each supply is, etc. The application would then try to find a matching valid configuration. If no match is found, that configuration would be considered invalid. The application should continue to check what if any faults are occurring, logging errors as appropriate.
When the system is powered on, the power supplies should start outputting power to the system. At that point the application will start to and continue to monitor the supplies and communicate any changes such as removal of input voltage, removal of a power supply, insertion of a power supply, and take any necessary actions to take upon detection of fault conditions.
The proposed power supply application would not control any fans internal to the power supply, that function would be left to other userspace application(s).
The current implementation of multiple instances of a power supply monitor was considered, essentially similar to the psu-monitor from the witherspoon-pfault-analysis repository. This design was avoided due to:
The application is expected to have some impact on the PLDM API, due to the various DBus properties it may be updating.
No security impacts are anticipated.
The main documentation impact should be this design document. Future enhancements or clarifications may be required for this document.
The application is expected to have a similar or lesser performance impact than the one application per power supply.
Testing can be accomplished via automated or manual testing to verify that:
CI testing could be impacted if a system being used for testing is in an unsupported or faulted configuration.