| commit | 2b3145d366cb36646dff23fbedfa48623e51069c | [log] [tgz] |
|---|---|---|
| author | Yong Li <yong.b.li@linux.intel.com> | Wed Mar 28 14:20:26 2018 +0800 |
| committer | Yong Li <yong.b.li@linux.intel.com> | Wed Mar 28 14:20:26 2018 +0800 |
| tree | 330c26d2bc9836e356397d93d1875c1af514efd4 | |
| parent | 1f0743c1bcaaa0c03601ec57770fbcec2276efbe [diff] |
Add a new PSU support The PSU type is delta dps-750XB A, it is connected to i2c7, eeprom data is: hexdump -Cv 7-0050/eeprom 00000000 01 00 00 00 01 09 00 f5 01 08 19 c5 44 45 4c 54 |............DELT| 00000010 41 cb 44 50 53 2d 37 35 30 58 42 20 41 ca 45 39 |A.DPS-750XB A.E9| 00000020 38 37 39 31 2d 30 31 30 c4 30 35 20 20 d1 45 39 |8791-010.05 .E9| 00000030 38 37 39 31 44 31 34 31 35 30 36 37 30 35 39 c0 |8791D1415067059.| 00000040 c0 c1 00 00 00 00 00 3e 00 02 18 3c aa ee 02 d0 |.......>...<....| 00000050 06 37 05 10 27 9c 31 20 4e c0 5d 2f 3f 0c 1f 52 |.7..'.1 N.]/?..R| 00000060 c3 00 00 00 85 01 02 0d 49 a7 01 b0 04 74 04 ec |........I....t..| 00000070 04 78 00 00 00 30 f2 01 82 0d 09 67 82 b0 04 74 |.x...0.....g...t| 00000080 04 ec 04 78 00 00 00 dc 05 ff ff ff ff ff ff ff |...x............| Change-Id: Ic1ec0729d84d3ae1b2224e1e96809ad668c13d14 Signed-off-by: Yong Li <yong.b.li@linux.intel.com>
#Entity Manager#
Entity manager is a runtime configuration application which parses configuration files (in JSON format) and attempts to detect the devices described by the configuration files. It also can, based on the configuration, attempt to load device tree overlays to add sensors to the device tree. The output is also a JSON file which includes all devices in the system such as fans and temperature sensors.
In most cases a server system is built with multiple hardware modules (circuit boards) such as baseboard, risers, and hot-swap backplanes. While it is perfectly legal to combine the JSON configuration information for all the hardware modules into a single file if desired, it is also possible to divide them into multilple configuration files. For example, there may be a baseboard JSON file (describes all devices on the baseboard) and a chassis JSON file (describes devices attached to the chassis). When one of the hardware modules needs to be upgraded (e.g., a new temperature sensor), only such JSON configuration file needs to be be updated.
Within a configuration file, there is a JSON object which consists of multiple "string : value" pairs. This Entity Manager defines the following strings.
| String | Example Value | Description |
|---|---|---|
| "name" | "X1000 1U Chassis" | Human readable name used for identification and sorting. |
| "probe" | "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME':'FFPANEL'})" | Statement which attempts to read from the hardware. The result determines if a configuration record should be applied. The value for probe can be set to “TRUE” in the case the record should always be applied, or set to more complex lookups, for instance a field in a FRU file. |
| "exposes" | [{"name" : "CPU fan"}, ...] | An array of JSON objects which are valid if the probe result is successful. These objects describe the devices BMC can interact. |
| "status" | "disabled" | An indicator that allows for some records to be disabled by default. |
| "bind_*" | "2U System Fan connector 1" | The record isn't complete and needs to be combined with another to be functional. The value is a unique reference to a record elsewhere. |
Template strings in the form of "$identifier" may be used in configuration files. The following table describes the template strings currently defined.
| Template String | Description |
|---|---|
| "$bus" | During a I2C bus scan and when the "probe" command is successful, this template string is substituted with the bus number to which the device is connected. |
| "$address" | When the "probe" is successful, this template string is substituted with the (7-bit) I2C address of the FRU device. |
| "$index" | A run-tim enumeration. This template string is substituted with a unique index value when the "probe" command is successful. This allows multiple identical devices (e.g., HSBPs) to exist in a system but each with a unique name. |
Required fields are name, probe and exposes.
The configuration JSON files attempt to model after actual hardware modules which made up a complete system. An example baseboard JSON file shown below defines two fan connectors and two temperature sensors of TMP75 type. These objects are considered valid by BMC when the probe command (reads and compares the product name in FRU) is successful and this baseboard is named as "WFP baseboard".
{
"exposes": [
{
"name": "1U System Fan connector 1",
"pwm": 1,
"status": "disabled",
"tachs": [
1,
2
],
"type": "IntelFanConnector"
},
{
"name": "2U System Fan connector 1",
"pwm": 1,
"status": "disabled",
"tachs": [
1
],
"type": "IntelFanConnector"
},
{
"address": "0x49",
"bus": 6,
"name": "Left Rear Temp",
"thresholds": [
[
{
"direction": "greater than",
"name": "upper critical",
"severity": 1,
"value": 115
},
{
"direction": "greater than",
"name": "upper non critical",
"severity": 0,
"value": 110
},
{
"direction": "less than",
"name": "lower non critical",
"severity": 0,
"value": 5
},
{
"direction": "less than",
"name": "lower critical",
"severity": 1,
"value": 0
}
]
],
"type": "TMP75"
},
{
"address": "0x48",
"bus": 6,
"name": "Voltage Regulator 1 Temp",
"thresholds": [
[
{
"direction": "greater than",
"name": "upper critical",
"severity": 1,
"value": 115
},
{
"direction": "greater than",
"name": "upper non critical",
"severity": 0,
"value": 110
},
{
"direction": "less than",
"name": "lower non critical",
"severity": 0,
"value": 5
},
{
"direction": "less than",
"name": "lower critical",
"severity": 1,
"value": 0
}
]
],
"type": "TMP75"
}
],
"name": "WFP Baseboard",
"probe": "xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME' : '.*WFT'})"
}
####Configuration Records - Chassis Example ####
Although fan connectors are considered a part of a baseboard, the physical fans themselves are considered as a part of a chassis. In order for a fan to be matched with a fan connector, the keyword "bind_connector" is used. The example below shows how a chassis fan named "Fan 1" is connected to the connector named "1U System Fan connector 1". When the probe command finds the correct product name in baseboard FRU, the fan and the connector are considered as being joined together.
{
"exposes": [
{
"bind_connector": "1U System Fan connector 1",
"name": "Fan 1",
"thresholds": [
[
{
"direction": "less than",
"name": "lower critical",
"severity": 1,
"value": 1750
},
{
"direction": "less than",
"name": "lower non critical",
"severity": 0,
"value": 2000
}
]
],
"type": "AspeedFan"
}
]
}
As demons can trigger off of shared types, sometimes some handshaking will be needed to enable sensors. Using the TMP75 sensor as an example, when the sensor object is enabled, the device tree must be updated before scanning may begin. The device tree overlay generator has the ability to key off of different types and create device tree overlays for specific offsets. Once this is done, the baseboard temperature sensor demon can scan the sensors.
The following environment variables need to be set to run unit tests: