| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Populate Redfish Status.Health and Status.State for processor core
resources
resource_utils::getResourceState() and getResourceHealth() are extended
to accept MapperServiceMap and use the first service implementing the
required interface. This avoids duplicate requests when multiple
services advertise the same interface for a core object
This commit also changes the iterator name in HEAD and GET path from
`it` to `coreIt` for better readability as well as passing coreId by
reference to avoid copies
Tested:
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0
{
...
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
- Where "State" can be "Present", "Available", "Enabled"
- Redfish Validator Passed
Change-Id: I5833541dceb9627b56b96e8235afcde78a09081f
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
Signed-off-by: Justin Nguyen <justinnanguyen@gmail.com>
|
|
Extend handleFabricSwitchPathSwitchGet() in fabric.hpp to read
xyz.openbmc_project.State.Decorator.PowerState from the resolved Switch
D-Bus path and surface the value as the Redfish PowerState property on
/redfish/v1/Fabrics/{FabricId}/Switches/{SwitchId}.
Tested: Build an image for nvl32-obmc machine with the following
patches cherry-picked:
1. Align with upstream u-boot dts tree:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89932
2. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
3. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
4. nvidia-gpu: add PowerState on ConnectX PCIeDevice:
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/90170
$ curl -sk https://{BMC_IP}/redfish/v1/Fabrics/fabric/Switches/\
Nvidia_ConnectX_24_PCIe
{
"@odata.id":
"/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_24_PCIe",
"@odata.type": "#Switch.v1_7_0.Switch",
"Id": "Nvidia_ConnectX_24_PCIe",
"Name": "Nvidia_ConnectX_24_PCIe",
"Ports": {
"@odata.id":
".../Switches/Nvidia_ConnectX_24_PCIe/Ports"
},
"PowerState": "On",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
$ busctl get-property xyz.openbmc_project.GpuSensor \
/xyz/openbmc_project/inventory/Nvidia_ConnectX_24_PCIe \
xyz.openbmc_project.State.Decorator.PowerState PowerState
s "xyz.openbmc_project.State.Decorator.PowerState.State.On"
```
Redfish Service Validator:
Summary - PASS: 9752, WARN: 373, FAIL: 0, NOT TESTED: 13355
Validating /redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_24_PCIe...
- Pass: 9, Warn: 0, Fail: 0, Skip: 32
Validating /redfish/v1/Fabrics/fabric/Switches/Terminus_18_PCIeSwitch_1_100...
- Pass: 8, Warn: 0, Fail: 0, Skip: 33
```
Change-Id: I4bc636664ae74280b72eab13219e5bf5b1e79a85
Signed-off-by: JY Voon <jvoon@nvidia.com>
|
|
Add optional support for UUID property for PCIeDevice.
Tested: Build an image for nvl32-obmc machine with the following patch
cherry picked.
```
1. Align with upstream u-boot dts tree:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89932
2. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
3. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
```
PCIeDevice with Common.UUID published (GPU path):
$ busctl get-property xyz.openbmc_project.GpuSensor \
/xyz/openbmc_project/inventory/Nvidia_GPU_10 \
xyz.openbmc_project.Common.UUID UUID
s "68174e99-daf4-02d1-ba39-4ed2bf8a0f21"
$ curl -sk https://{BMC_IP}/redfish/v1/Systems/system/\
PCIeDevices/Nvidia_GPU_10
{
"@odata.id": "/redfish/v1/Systems/system/PCIeDevices/Nvidia_GPU_10",
"@odata.type": "#PCIeDevice.v1_19_0.PCIeDevice",
"Id": "Nvidia_GPU_10",
"Manufacturer": "NVIDIA",
"Model": "RTXPRO6000BlackwellDC",
"Name": "PCIe Device",
"PartNumber": "900-2G153-0000-000",
"SerialNumber": "1792425045093",
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UUID": "68174e99-daf4-02d1-ba39-4ed2bf8a0f21"
}
PCIeDevice without Common.UUID published (ConnectX path):
$ busctl get-property xyz.openbmc_project.GpuSensor \
/xyz/openbmc_project/inventory/Nvidia_ConnectX_24_PCIe \
xyz.openbmc_project.Common.UUID UUID
Failed to get property UUID on interface
xyz.openbmc_project.Common.UUID: Unknown interface
xyz.openbmc_project.Common.UUID or property UUID.
$ curl -sk https://{BMC_IP}/redfish/v1/Systems/system/\
PCIeDevices/Nvidia_ConnectX_24_PCIe | jq 'has("UUID")'
false
Change-Id: I38cf972f03f0dd0299b708ea8203872c73c8e224
Signed-off-by: JY Voon <jvoon@nvidia.com>
|
|
Extended Cable's Status.State to use Available mapping and added
Status.Health to Cable which it did not have before
Utilize resource_util's getResourceHealth and getResourceState to
standardize Redfish Status.State and Status.Health
Tested: on QEMU, which has no host and so no real cable inventory, with
a cable object injected into phosphor-inventory-manager.
Functional true -> "Health": "OK", "State": "Enabled"
Functional false -> "Health": "Critical", "State": "Enabled"
Where State can be "Enabled", "Absent", and "UnavailableOffline" if the
xyz.openbmc_project.State.Decorator.Availability interface is
implemented
Change-Id: I9f99f7cfe348545506753cc4eedd81570fbf3fba
Signed-off-by: Akshay Gaitonde <a.g@utexas.edu>
Signed-off-by: Justin Nguyen <justinnanguyen@gmail.com>
|
|
The SubProcessors core is a collection under the processor
schema. The association objects, (containing, contained_by), are used
to link the processor core.
The association between processor and core have been documented in
phosphor-dbus-interfaces [1]
[1] https://github.com/openbmc/phosphor-dbus-interfaces/commit/8c79b1dc0270d01c0b713a345c8ec39533c542e4
Tested: Redfish Validator Passed
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0",
"@odata.type": "#Processor.v1_18_0.Processor",
"Id": "core0",
"Name": "SubProcessor",
"ProcessorType": "Core"
}
```
Verified that below return a link header
```
- GET /redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0
- HEAD /redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0
```
Change-Id: I8cee9909ce20fc0bfdd56fb4fc992163546be180
Signed-off-by: George Liu <liuxiwei@inspur.com>
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
The SubProcessors is a collection under the processor collection
schema. The association objects, (containing, contained_by), are
used to link the processor.
The association between processor and core have been documented in
phosphor-dbus-interfaces [1]
[1] https://github.com/openbmc/phosphor-dbus-interfaces/commit/8c79b1dc0270d01c0b713a345c8ec39533c542e4
Tested:
- GET cpu and cpu subprocessors
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/Processors/cpu0
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0",
"@odata.type": "#Processor.v1_18_0.Processor",
"Id": "cpu0",
...
"SubProcessors": {
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0/SubProcessors"
},
...
}
```
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/Processors/cpu0/SubProcessors
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0/SubProcessors",
"@odata.type": "#ProcessorCollection.ProcessorCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core0"
},
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0/SubProcessors/core1"
},
...
],
"Members@odata.count": 4,
"Name": "SubProcessor Collection"
}
```
- Verified that below return a link header
- GET /redfish/v1/Systems/system/Processors/cpu0/SubProcessors
- HEAD /redfish/v1/Systems/system/Processors/cpu0/SubProcessors
- Redfish Validator Passed
Change-Id: If155b97b0c782d82541c00ecf5ee70cb0180f71f
Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Signed-off-by: Nikhil Namjoshi <nikhilnamjoshi@google.com>
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
Implement Redfish Chassis Links/Processors property to expose the
association between a chassis and its processors. The "containing"
association from the chassis D-Bus object is traversed to discover
all associated processor objects.
Processors implementing either of the following D-Bus interfaces are
included:
- xyz.openbmc_project.Inventory.Item.Accelerator
- xyz.openbmc_project.Inventory.Item.Cpu
The following Redfish property is populated:
- Links/Processors[]/@odata.id
(/redfish/v1/Systems/<system>/Processors/<name>)
Tested:
```
Build an image for nvl32-obmc machine with the following
patches cherry-picked:
1. platform-init enable LCLK and espiCLK:
https://gerrit.openbmc.org/c/openbmc/platform-init/+/89900
2. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
3. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
```
```
$ curl -sk -u \
https://localhost/redfish/v1/Chassis/{}
{
...
"Links": {
...
"Processors": [
{
"@odata.id": "/redfish/v1/Systems/system/Processors/GPU_*_*"
}
]
}
...
}
```
```
Redfish Service Validator: PASS: 10646, WARN: 381, FAIL: 1,
NOT TESTED: 16809
The FAIL is pre-existing.
```
Change-Id: I071ba0f7774d7c6c11f4a49fc584d50b0dfb9ca8
Signed-off-by: Jacky Huang <jackyhuang@nvidia.com>
|
|
Add FirmwareVersion and Location.PartLocation.ServiceLabel
to GPU Processor.
Tested: Build an image for nvl32-obmc machine with the following
patches cherry-picked:
1. Align with upstream u-boot dts tree:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89932
2. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
3. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
$ curl -sk https://{BMC_IP}/redfish/v1/Systems/system/\
Processors/GPU_0_0
{
"@odata.id": "/redfish/v1/Systems/system/Processors/GPU_0_0",
"@odata.type": "#Processor.v1_18_0.Processor",
"FirmwareVersion": "98.02.AF.00.01",
"Id": "GPU_0_0",
"Location": {
"PartLocation": {
"ServiceLabel": "GPU_0_0"
}
},
"Manufacturer": "NVIDIA",
"Model": "RTXPRO6000BlackwellDC",
"Name": "Processor",
"PartNumber": "900-2G153-0000-000",
"ProcessorType": "Accelerator",
"SerialNumber": "1792425045137",
"Status": {
"Health": "OK",
"State": "Enabled"
},
"UUID": "1eca7165-20f9-9163-7281-10aeae60c883",
"Version": "2BB5-895-A1"
}
Depends-On: Id0c09f4ced40dbe505ca7cbd99f6de0e847afe3b
Change-Id: I04c5a82fe9a04e25dfaed341c46f06804c7000ca
Signed-off-by: JY Voon <jvoon@nvidia.com>
|
|
The EnvironmentMetrics schema[1] provides for efficient retrieval of
environmental metrics by separating them from performance metrics.
EnvironmentMetrics is a property of the Chassis schema since v1_15_0[2].
This commit extends the GET EnvironmentMetrics response to include
PowerLimitWatts property. PowerLimitWatts has been part of the
EnvironmentMetrics schema since v1_1_0. PowerLimitWatts is a
ControlSingleExcerpt[3].
Additionally this commit implements PATCH for the PowerLimitWatts
property of EnvironmentMetrics.
The PowerLimitWatts was added to Redfish release 2021.2 [4] to be used
instead of the deprecated Power schema.[5]
[1] https://redfish.dmtf.org/schemas/v1/EnvironmentMetrics.v1_5_0.json
[2] https://redfish.dmtf.org/schemas/v1/Chassis.v1_28_0.json
[3] https://redfish.dmtf.org/schemas/v1/Control.v1_7_0.json
[4] http://redfish.dmtf.org/schemas/Redfish_Release_History.pdf
[5] https://redfish.dmtf.org/schemas/v1/Power.v1_7_3.json
Tested:
(Used p10bmc hardware simulator with association added)
1. Redfish Service Validator passes
2.GET PowerLimitWatts in Chassis EnvironmentMetrics
```
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
...
"PowerLimitWatts": {
"AllowableMax": 4294967295,
"AllowableMin": 0,
"ControlMode": "Disabled",
"SetPoint": 0
}
}
```
3. GET error handling of invalid chassisId
```
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassisERROR/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type Chassis named 'chassisERROR' was not found.",
"MessageArgs": [
"Chassis",
"chassisERROR"
],
"MessageId": "Base.1.19.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.19.ResourceNotFound",
"message": "The requested resource of type Chassis named 'chassisERROR' was not found."
}
}
```
4. PATCH to set SetPoint in PowerLimitWatts
1> When the value is in the allowable range, the modification succeeds.
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d'{ "PowerLimitWatts": {"SetPoint": 10}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
...
"PowerLimitWatts": {
"AllowableMax": 4294967295,
"AllowableMin": 0,
"ControlMode": "Disabled",
"SetPoint": 10
}
}
```
2> When the value is outside of the allowable range, the modification
fails and an error is reported.
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d '{ "PowerLimitWatts": {"SetPoint": 4294967296}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The value '4294967296' for the property SetPoint is not in the supported range of acceptable values.",
"MessageArgs": [
"4294967296",
"SetPoint"
],
"MessageId": "Base.1.19.PropertyValueOutOfRange",
"MessageSeverity": "Warning",
"Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed."
}
],
"code": "Base.1.19.PropertyValueOutOfRange",
"message": "The value '4294967296' for the property SetPoint is not in the supported range of acceptable values."
}
}
```
5. PATCH to set ControlMode in PowerLimitWatts
1>When the ControlMode is changed to Automatic, the modification
is successful.
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d'{ "PowerLimitWatts": {"ControlMode": "Automatic"}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
...
"PowerLimitWatts": {
"AllowableMax": 4294967295,
"AllowableMin": 0,
"ControlMode": "Automatic",
"SetPoint": 10
}
}
```
2>When the ControlMode is changed to Disabled, the modification
is successful.
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d'{ "PowerLimitWatts": {"ControlMode": "Disabled"}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
curl -k -H "X-Auth-Token: ${token}" -X GET https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
...
"PowerLimitWatts": {
"AllowableMax": 4294967295,
"AllowableMin": 0,
"ControlMode": "Disabled",
"SetPoint": 10
}
}
```
3>When the ControlMode is changed to other values, the modification
fails and an error is reported.
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d '{ "PowerLimitWatts": {"ControlMode": "Error"}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The value '\"Error\"' for the property ControlMode is not in the list of acceptable values.",
"MessageArgs": [
"\"Error\"",
"ControlMode"
],
"MessageId": "Base.1.19.PropertyValueNotInList",
"MessageSeverity": "Warning",
"Resolution": "Choose a value from the enumeration list that the implementation can support and resubmit the request if the operation failed."
}
],
"code": "Base.1.19.PropertyValueNotInList",
"message": "The value '\"Error\"' for the property ControlMode is not in the list of acceptable values."
}
}
```
6. PATCH to set PowerLimitWatts when no associated object
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X PATCH -d '{ "PowerLimitWatts":{"SetPoint":0,"ControlMode":"Automatic"}}' https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The property PowerLimitWatts is not in the list of valid properties for the resource.",
"MessageArgs": [
"PowerLimitWatts"
],
"MessageId": "Base.1.19.PropertyUnknown",
"MessageSeverity": "Warning",
"Resolution": "Remove the unknown property from the request body and resubmit the request if the operation failed."
}
],
"code": "Base.1.19.PropertyUnknown",
"message": "The property PowerLimitWatts is not in the list of valid properties for the resource."
}
}
```
Change-Id: Iacd244e537ccab6572a0a55b7f30871774e097ff
Signed-off-by: Albert Zhang <zhanghaodi@inspur.com>
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
|
|
This change adds user password expiration date time mgmt via REST
API provided by bmcweb. Password expiration date time is managed as
string in 'YYYY-MM-DDTHH:MM:SS±hh:mm' format and internally operates as
Epoch time. When set password expiration date time can be specified in
any format supported by 'dateStringToEpoch' function in
'redfish::time_utils'. Value 'null' is used to make password not to
expire.
Unit tests checking correct password expiration value conversion were
added.
This change depends on corresponding change in phosphor-dbus-interfaces
[1] and in phospor-user-manager [2].
Password expiration management:
- create user with password expiration
```
curl -k -X POST -H 'Content-Type: application/json' \
"https://<bmc>/redfish/v1/AccountService/Accounts" \
-d '{"UserName":"<user>", "Password":"<password>", "RoleId":"<role>", "PasswordExpiration": "<YYYY-MM-DDTHH:MM:SS>"}'
```
- modify user password expiration
```
curl -k -X PATCH -H 'Content-Type: application/json' \
https://<bmc>/redfish/v1/AccountService/Accounts/<user> \
-d '{"PasswordExpiration": "<YYYY-MM-DDTHH:MM:SS>"}'
```
- get user password expiration
```
curl -k -X GET https://<bmc>/redfish/v1/AccountService/Accounts/<user>
```
- modify user password not to expire
```
curl -k -X PATCH -H 'Content-Type: application/json' \
https://<bmc>/redfish/v1/AccountService/Accounts/<user> \
-d '{"PasswordExpiration": null}'
```
Tested:
Functionality of this change was tested via curl utility. Also, it was
checked that proper value was set on dbus for'PasswordExpiration'
attribute of the specified user.
- create user account without password expiration, verify that password
expiration is not set
- create user account with password expiration specified, verify that it
is correct
- create user account with null password expiration which makes password
not to expire, verify that it is correct
- try to create user account with various invalid password expiration
values(incorrect type, invalid format), verify that user is not
created and appropriate error is returned in response
- modify user password expiration to specific time, verify that is is
correct
- make user password not to expiry, verify that it is correct
- try to set password expiration to an invalid value (incorrect type,
invalid format), verify that is does not change and appropriate error
is returned in response
Redfish service validation on /redfish/v1/AccountService/Accounts tree
containing both user accounts with and without password expiration has
passed successfully.
[1] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/75236
[2] https://gerrit.openbmc.org/c/openbmc/phosphor-user-manager/+/75237
Change-Id: Idf5e4356eaa8866dd4a10664996117e2cdba0684
Signed-off-by: Ivan Moiseev <moiseev.ivan4w@yandex.com>
Signed-off-by: Ivan Mikhaylov <fr0st61te@gmail.com>
|
|
Change-Id: Id386a516a9d152e3f9295f457760f34a5c78bae5
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
|
|
This change implements support for the Redfish EnvironmentMetrics
resource for Processors. It allows bmcweb to expose power limit
information from D-Bus xyz.openbmc_project.Control.Power.Cap
interface as PowerLimitWatts properties in the Processor
EnvironmentMetrics.
The implementation uses D-Bus Association (controlled_by) to discover
the control object path from the processor inventory object. This
approach follows the OpenBMC association pattern where inventory
objects link to their corresponding control interfaces.
Key changes:
- processor.hpp: Added EnvironmentMetrics link to Processor resources
only when the processor has a controlled_by association pointing to
an object with xyz.openbmc_project.Control.Power.Cap interface.
- environment_metrics.hpp: Implemented GET handler for
/redfish/v1/Systems/{system}/Processors/{processor}/EnvironmentMetrics
with PowerLimitWatts property mapping from D-Bus Control.Power.Cap
interface.
- Redfish.md: Documented the new EnvironmentMetrics endpoint and
PowerLimitWatts properties.
The implementation maps D-Bus properties to Redfish as follows:
- DefaultPowerCap -> PowerLimitWatts.DefaultSetPoint
- MaxPowerCapValue -> PowerLimitWatts.AllowableMax
- MinPowerCapValue -> PowerLimitWatts.AllowableMin
- PowerCap -> PowerLimitWatts.SetPoint
- PowerCapEnable -> PowerLimitWatts.ControlMode
Note: When PowerCap or DefaultPowerCap is UINT32_MAX (0xFFFFFFFF),
it indicates the value is not set. SetPoint is mapped to null in
this case, and DefaultSetPoint is omitted. This follows the
Control.Power.Cap interface definition [1]. This follows the PDI
Accelerator association definition (controlling/controlled_by) [2].
Tested: Build an image for nvl32-obmc machine with the following
patches cherry-picked:
```
1. Align with upstream u-boot dts tree:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89932
2. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
3. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
Sample output
$ curl -k -H "Content-Type: application/json" \
-X GET https://<bmc_ip>/redfish/v1/Systems/system/\
Processors/GPU_*_*
{
"@odata.id":
"/redfish/v1/Systems/system/Processors/GPU_*_*",
"@odata.type": "#Processor.v1_18_0.Processor",
...
"EnvironmentMetrics": {
"@odata.id":
"/redfish/v1/Systems/system/Processors/GPU_*_*/\
EnvironmentMetrics"
},
...
}
$ curl -k -H "Content-Type: application/json" \
-X GET https://<bmc_ip>/redfish/v1/Systems/system/\
Processors/GPU_*_*/EnvironmentMetrics
{
"@odata.id":
"/redfish/v1/Systems/system/Processors/GPU_*_*/\
EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"Id": "EnvironmentMetrics",
"Name": "Processor Environment Metrics",
"PowerLimitWatts": {
"AllowableMax": {},
"AllowableMin": {},
"ControlMode": {},
"DefaultSetPoint": {},
"SetPoint": {}
}
}
$ curl -k -H "Content-Type: application/json" \
-X GET https://<bmc_ip>/redfish/v1/Systems/system/\
Processors/INVALID/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message":
"The requested resource of type Processor named \
INVALID was not found.",
...
}
],
"code": "Base.1.13.0.ResourceNotFound",
...
}
}
```
1. Verified that EnvironmentMetrics link appears in Processor
resources only when controlled_by association exists with
Control.Power.Cap interface.
2. Confirmed PowerLimitWatts properties correctly map from
D-Bus properties for GPU processors.
3. Validated that SetPoint is null when D-Bus PowerCap is
0xFFFFFFFF (UINT32_MAX).
4. Confirmed DefaultSetPoint is omitted when DefaultPowerCap
is 0xFFFFFFFF.
5. Confirmed 404 error is returned for non-existent processors.
6. Tested with Redfish Service Validator:
Results Summary:
Pass: 8945, Fail: 0, Warning: 369
Validation has succeeded.
```
[1] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/86869
[2] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/88553
```
Change-Id: I69a7ee19bfa7de68c0dcaf164735bf1902b16d96
Signed-off-by: Ender Hsieh <andhsieh@nvidia.com>
|
|
Just like we do for Fans, PowerSupplies, etc. if this Decorator.Asset
interface exists, use it to fill out Manufacturer, Model, PartNumber,
and SerialNumber.
Followed the Inventory.Item.Cable and just leaves off if implementations
don't have this interface.
DMTF will add the SparePartNumber to Redfish 2026.2 so for now will not
include it.
Tested: curl -v -k https://${bmc}/redfish/v1/Cables/external_cable_1 and
Redfish Service Validator passes
See these new properties:
{
"@odata.id": "/redfish/v1/Cables/external_cable_1",
"@odata.type": "#Cable.v1_2_0.Cable",
"Id": "external_cable_1",
...
"Manufacturer": "",
"Model": "",
"Name": "Cable",
"PartNumber": "78P6567",
"SerialNumber": ""
...
}
Change-Id: Ibe126c57539a20b3c5dc89c8321873f0f3c42bc1
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
Signed-off-by: Justin Nguyen <justinnanguyen@gmail.com>
|
|
Map the Inventory.Item.PCIeDevice.DeviceType D-Bus property
into the Redfish PCIeDevice schema's DeviceType property.
When the D-Bus value is the PDI default (Unknown), the
Redfish field is omitted; otherwise the enum is rendered.
The implementation maps D-Bus to Redfish as follows:
- Inventory.Item.PCIeDevice.DeviceTypes.SingleFunction
-> PCIeDevice.DeviceType.SingleFunction
- Inventory.Item.PCIeDevice.DeviceTypes.MultiFunction
-> PCIeDevice.DeviceType.MultiFunction
- Inventory.Item.PCIeDevice.DeviceTypes.Simulated
-> PCIeDevice.DeviceType.Simulated
- Inventory.Item.PCIeDevice.DeviceTypes.Retimer
-> PCIeDevice.DeviceType.Retimer
- Inventory.Item.PCIeDevice.DeviceTypes.Unknown / empty
-> field omitted
Key changes:
- redfish-core/include/utils/pcie_util.hpp: add
redfishPcieDeviceTypeFromDbus() that maps the D-Bus
DeviceTypes enum strings to pcie_device::DeviceType.
- redfish-core/lib/pcie.hpp: unpack the DeviceType property
in addPCIeDeviceProperties() and set
jsonValue["DeviceType"] using the mapper.
Tested: Built an image for nvl32-obmc with the following
patches cherry-picked:
```
1. Align with upstream u-boot dts tree:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89932
2. U-Boot change phy mode (in-flight on mailing list):
https://lore.kernel.org/openbmc/20260504044702.2613879-1-\
andhsieh@nvidia.com/T/#t
3. Kernel device tree add mac mode (in-flight on mailing
list):
https://lore.kernel.org/linux-aspeed/20260505050541.\
3031447-1-andhsieh@nvidia.com/T/#t
4. platform-init enable LCLK and espiCLK:
https://gerrit.openbmc.org/c/openbmc/platform-init/+/89900
5. mctpd configuration:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/87390
6. Enable nvidia-gpu sensor:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/89933
```
Deployed the rebuilt bmcweb onto Alon8-GBT-20.
```
$ curl -sk -u <credentials> \
https://${BMC}/redfish/v1/Systems/system/PCIeDevices/\
GPU_0_0
{
"@odata.id": "/redfish/v1/Systems/system/PCIeDevices/\
GPU_0_0",
"@odata.type": "#PCIeDevice.v1_19_0.PCIeDevice",
"DeviceType": "SingleFunction",
...
}
$ curl -sk -u <credentials> \
https://${BMC}/redfish/v1/Systems/system/PCIeDevices/\
Nvidia_ConnectX_0_PCIe
{
...
(no DeviceType field; D-Bus property not registered)
}
```
1. Verified the Redfish DeviceType field is rendered as
SingleFunction on the GPU PCIeDevice resource.
2. Verified the field is omitted when the D-Bus property is
not registered (ConnectX path), so the Redfish output
remains consistent with the PDI default behavior.
3. Redfish Service Validator: pass.
Change-Id: I13a6214f71e9a06b5f2ab9ca8abef6663a856da2
Signed-off-by: Eric Liu <liuer@nvidia.com>
|
|
The sdbusplus headers provide shortened aliases for many types.
Switch to using them to provide better code clarity and shorter
lines. Possible replacements are for:
* bus_t
* exception_t
* manager_t
* match_t
* message_t
* object_t
* slot_t
* object_path
Change-Id: Iace20f9ad26e8d9dc234979e7a4087d599da2641
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
|
|
We should have a single entry point where we do json parsing. There are
configurations for nlohmmann that we had previously documented, but were
not well enforced. Move all uses to using the helper parse functions.
Tested: Unit tests pass.
Redfish service validator passes.
Change-Id: I2a8aed9327b6b15219dc9b4d6db146b69bcd8eb3
Signed-off-by: Ed Tanous <etanous@nvidia.com>
|
|
This patch enables support for Nvidia ConnectX network cards. Network
adapter schemas are restricted to a single URI path format:
/redfish/v1/Chassis/{ChassisId}/NetworkAdapters/{NetworkAdaptersId}/.
[1]
And thus, the port URI follows this structure
/redfish/v1/Chassis/{ChassisId}/NetworkAdapters/{NetworkAdaptersId}/
Ports/{PortId}.
[2]
Route handler for collections and each individual components are added
in this patch for each URI resource under
/redfish/v1/Chassis/{ChassisId}/NetworkAdapters.
Association between Chassis and NetworkAdapter is `containing` and
`contained_by`. Association between NetworkAdapter and Port is
`connecting` and `connected_to`.
This patch enable support for following properties for Port Metrics URI
of a Network Port. [3]
- TXBytes
- RXBytes
- RXMulticastFrames
- TXMulticastFrames
- RXUnicastFrames
- TXUnicastFrames
- RXBroadcastFrames
- TXBroadcastFrames
- RXFCSErrors
- RXFrameAlignmentErrors
- RXFalseCarrierErrors
- RXUndersizeFrames
- RXOversizeFrames
- RXPauseXONFrames
- RXPauseXOFFFrames
- TXPauseXONFrames
- TXPauseXOFFFrames
- TXSingleCollisions
- TXMultipleCollisions
- TXLateCollisions
- TXExcessiveCollisions
The patch uses "xyz.openbmc_project.Metric.Value" Interface for Network
Port Metrics properties. Association between a Metric and a Port is
`measuring` and `measured_by`.
PDI patch -
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/84629
dbus-sensors patches -
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84520
Tested: Build an image for nvl32-obmc machine with the following patch
cherry picked.
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84520
https://gerrit.openbmc.org/c/openbmc/openbmc/+/85490
The openbmc patch cherry-picks the following patches that are currently
under review.
```
1. device tree
https://lore.kernel.org/all/aRbLqH8pLWCQryhu@molberding.nvidia.com/
2. mctpd patches
https://github.com/CodeConstruct/mctp/pull/85
3. u-boot changes
https://lore.kernel.org/openbmc/20251121-msx4-v1-0-fc0118b666c1@nvidia.com/T/#t
4. kernel changes as specified in the openbmc patch (for espi)
5. entity-manager changes
https://gerrit.openbmc.org/c/openbmc/entity-manager/+/85455
6. platform-init changes
https://gerrit.openbmc.org/c/openbmc/platform-init/+/85456
7. spi changes
https://lore.kernel.org/all/20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com/
```
redfish service validator is passing.
```
$ curl -s -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters",
"@odata.type": "#NetworkAdapterCollection.NetworkAdapterCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_0"
},
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1"
},
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_2"
},
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_3"
}
],
"Members@odata.count": 4,
"Name": "Nvidia_IMGX_ConnectX8_SuperNIC_Switch Network Adapter Collection"
}%
$ curl -s -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1",
"@odata.type": "#NetworkAdapter.v1_11_0.NetworkAdapter",
"Id": "Nvidia_ConnectX_1",
"Name": "Nvidia_ConnectX_1 Network Adapter",
"Ports": {
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports"
},
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
}
}%
$ curl -s -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports",
"@odata.type": "#PortCollection.PortCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0"
},
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_1"
}
],
"Members@odata.count": 2,
"Name": "Nvidia_ConnectX_1 Port Collection"
}%
$ curl -s -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0/
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0",
"@odata.type": "#Port.v1_9_0.Port",
"Id": "Port_0",
"Metrics": {
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0/Metrics"
},
"Name": "Nvidia_ConnectX_1 Port_0 Port",
"Status": {
"Health": "OK",
"HealthRollup": "OK",
"State": "Enabled"
}
}%
$ curl -s -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0/Metrics/
{
"@odata.id": "/redfish/v1/Chassis/Nvidia_IMGX_ConnectX8_SuperNIC_Switch/NetworkAdapters/Nvidia_ConnectX_1/Ports/Port_0/Metrics",
"@odata.type": "#PortMetrics.v1_7_0.PortMetrics",
"Id": "Metrics",
"Name": "Nvidia_ConnectX_1 Port_0 Port Metrics",
"Networking": {
"RXBroadcastFrames": 0,
"RXFCSErrors": 0,
"RXFalseCarrierErrors": 0,
"RXFrameAlignmentErrors": 0,
"RXMulticastFrames": 0,
"RXOversizeFrames": 0,
"RXPauseXOFFFrames": 0,
"RXPauseXONFrames": 0,
"RXUndersizeFrames": 0,
"RXUnicastFrames": 0,
"TXBroadcastFrames": 0,
"TXExcessiveCollisions": 0,
"TXLateCollisions": 0,
"TXMulticastFrames": 0,
"TXMultipleCollisions": 0,
"TXPauseXOFFFrames": 0,
"TXPauseXONFrames": 0,
"TXSingleCollisions": 0,
"TXUnicastFrames": 0
},
"RXBytes": 0,
"TXBytes": 0
}%
```
[1]: https://redfish.dmtf.org/schemas/v1/NetworkAdapter_v1.xml
[2]: https://redfish.dmtf.org/schemas/v1/Port_v1.xml
[3]: https://redfish.dmtf.org/schemas/v1/PortMetrics_v1.xml
Change-Id: I73c5a39b12f8f0a40026fb50c2ded53e0b225f67
Signed-off-by: Harshit Aghera <haghera@nvidia.com>
|
|
This patch enable support for following properties for Port Metrics URI
of a PCIe Switch. [1]
- PCIeErrors.CorrectableErrorCount
- PCIeErrors.NonFatalErrorCount
- PCIeErrors.FatalErrorCount
- PCIeErrors.L0ToRecoveryCount
- PCIeErrors.ReplayCount
- PCIeErrors.ReplayRolloverCount
- PCIeErrors.NAKSentCount
- PCIeErrors.NAKReceivedCount
- PCIeErrors.UnsupportedRequestCount
The patch uses "xyz.openbmc_project.Metric.Value" Interface for PCIe
Port Metrics properties. Association between a Metric and a Port is
`measuring` and `measured_by`.
PDI patch -
https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/84839
dbus-sensors patches -
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84132
Tested: Build an image for nvl32-obmc machine with the following patch
cherry picked.
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84132
https://gerrit.openbmc.org/c/openbmc/openbmc/+/85490
The openbmc patch cherry-picks the following patches that are currently
under review.
```
1. device tree
https://lore.kernel.org/all/aRbLqH8pLWCQryhu@molberding.nvidia.com/
2. mctpd patches
https://github.com/CodeConstruct/mctp/pull/85
3. u-boot changes
https://lore.kernel.org/openbmc/20251121-msx4-v1-0-fc0118b666c1@nvidia.com/T/#t
4. kernel changes as specified in the openbmc patch (for espi)
5. entity-manager changes
https://gerrit.openbmc.org/c/openbmc/entity-manager/+/85455
6. platform-init changes
https://gerrit.openbmc.org/c/openbmc/platform-init/+/85456
7. spi changes
https://lore.kernel.org/all/20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com/
```
redfish service validator is passing.
```
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/Metrics/
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/Metrics",
"@odata.type": "#PortMetrics.v1_3_0.PortMetrics",
"Id": "Metrics",
"Name": "Nvidia_ConnectX_0 UP_0 Port Metrics",
"PCIeErrors": {
"CorrectableErrorCount": 0,
"FatalErrorCount": 0,
"L0ToRecoveryCount": 1,
"NAKReceivedCount": 0,
"NAKSentCount": 0,
"NonFatalErrorCount": 0,
"ReplayCount": 0,
"ReplayRolloverCount": 0,
"UnsupportedRequestCount": 0
}
}%
```
[1]: https://redfish.dmtf.org/schemas/v1/PortMetrics_v1.xml
Change-Id: I7cca75fa5d4c77a4b02d35f7ce0b024f325ceff0
Signed-off-by: Harshit Aghera <haghera@nvidia.com>
|
|
Adds SpeedPercent and SecondarySpeedPercent information according to the
Redfish Fan schema.[1] The schema only allows fans of ReadingType
Percent to be reported in SpeedPercent and SecondarySpeedPercent.
These new properties are accessed through the Redfish Uri for a
particular fan on a particular chassis[2]:
```
/redfish/v1/Chassis/<chassisId>/ThermalSubsystem/Fans/<fanId>
```
The primary and secondary fan sensors connected to the fan are found by:
1) Find all sensors associated to fan using the 'sensors' endpoint.[3]
2) For each sensor get its priority using the
'xyz.openbmc_project.Common.Priority' interface.[4][5]
3) Retrieve the sensor excerpt and place into the response based on the
priority of the sensor.
Implementation Notes:
- The utility function objectExcerptToJson() is used to populate the
SensorFanExcerpt.
- Guards are added to handle different cases of D-Bus sensors Priority
settings:
- Fan has only 1 sensor associated and the sensor has no priority.
Fills SpeedPercent for response.
- Fan has more than one sensor. Any sensor without priority will be
skipped.
- Fan has one or more sensors with priority. The priority setting
determines which property will be filled for the response. If the
priority is 0 it uses SpeedPercent. If the priority is 1 it uses
SecondarySpeedPercent. Any other priority the sensor will not be
included in the response.
- Fan has two sensors with the same priority. The first one is in the
response and the second one is skipped.
[1] https://redfish.dmtf.org/schemas/v1/Fan.v1_6_0.json
[2] https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2025.4.html#fan
[3] https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#association-type-2-linking-a-low-level-hardware-item-to-its-sensors
[4] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/66779
[5] https://gerrit.openbmc.org/c/openbmc/phosphor-hwmon/+/67170
Tested (using p10bmc hardware simulator with fan configuration edits):
- Redfish Service Validator passes
- Tested various fan configurations with Percent fans:
```
/* Fan has two sensors both with priority set */
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan0
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan0",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"SecondarySpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_1",
"Reading": 60,
"SpeedRPM": 12036.0
},
...
"SpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0",
"Reading": 100,
"SpeedRPM": 18000.0
},
...
}
/* Fan has two sensors neither with priority, both skipped */
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan1
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan1",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"PartNumber": "XXXXXXX",
"SerialNumber": "XXXXXXXXXXXX",
"SparePartNumber": "XXXXXXX",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
/* Fan has one sensor without priority, shown as primary */
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan2
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan2",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"SpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_0",
"Reading": 50,
"SpeedRPM": 18000.0
},
...
}
/* Fan has two sensors. Both have priority 0. The first sensor is in the
* response the second sensor is skipped.
*/
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan3
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan3",
"@odata.type": "#Fan.v1_6_0.Fan",
"Id": "fan3",
"Location": {
"PartLocation": {
"ServiceLabel": "U78DA.ND0.1234567-A3"
}
},
"LocationIndicatorActive": false,
"Manufacturer": "Delta",
"Model": "7B5G",
"Name": "Fan",
"PartNumber": "02YK200",
"SerialNumber": "YS10JP12V0TY",
"SparePartNumber": "02YK237",
"SpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_0",
"Reading": null,
"SpeedRPM": 18000.0
},
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
/* Fan has two sensors. One priority 0, other priority 2. Only the
* primary is in the response.
*/
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan4
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan4",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"PartNumber": "XXXXXXX",
"SerialNumber": "XXXXXXXXXXXX",
"SparePartNumber": "XXXXXXX",
"SpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_0",
"Reading": null,
"SpeedRPM": 18000.0
},
...
}
/* Fan has two sensors. One priority 1, other priority 2. Only the
* secondary is in the response.
*/
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan5
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan5",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"SecondarySpeedPercent": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan5_1",
"Reading": null,
"SpeedRPM": 12036.0
},
"SerialNumber": "XXXXXXXXXXXX",
"SparePartNumber": "XXXXXXX",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
- Tested with rotational fans the new fields are not in response:
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan0
{
"@odata.id": "/redfish/v1/Chassis/chassis/ThermalSubsystem/Fans/fan0",
"@odata.type": "#Fan.v1_6_0.Fan",
...
"PartNumber": "XXXXXXX",
"SerialNumber": "XXXXXXXXXXXX",
"SparePartNumber": "XXXXXXX",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0",
"@odata.type": "#Sensor.v1_11_1.Sensor",
...
"ReadingType": "Rotational",
...
}
```
Signed-off-by: George Liu <liuxiwei@inspur.com>
Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com>
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
Change-Id: Ic767de3bde8bfe14b31da23b67e17a8d04eefadb
|
|
This change implements support for the D-Bus interface
xyz.openbmc_project.Common.PhysicalContext for Sensors. It allows
bmcweb to fetch the physical location context via the 'Type'
property from this interface and expose it through the Redfish
Sensor resource.
The dBusSensorPhysicalContextToRedfish helper is added to map the
D-Bus PhysicalContextType enum string to the Redfish
PhysicalContext enumeration. Currently only the Accelerator type
is supported by PDI; additional types should be added here as they
are introduced in phosphor-dbus-interfaces.
This implementation follows the interface definition introduced in:
https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/86504
Key changes:
- sensor_utils.hpp: Added dBusSensorPhysicalContextToRedfish helper.
- sensor_utils.hpp: Updated fillSensorIdentity to unpack and
map the PhysicalContext property to the sensor JSON response.
- Redfish.md: Documented the PhysicalContext property for the
Chassis Sensors resource (/redfish/v1/Chassis/{ChassisId}/
Sensors/{Id}/).
Tested:
```
Sample output
$ curl -k -H "Content-Type: application/json" -X GET
https://"${BMC}"/redfish/v1/Chassis/<id>/Sensors/<sensor_id>
{
...
"PhysicalContext": {},
...
}
```
1. Verified that PhysicalContext appears in the Redfish Sensor
response (e.g., /redfish/v1/Chassis/<id>/Sensors/<sensor_id>).
2. Validated with Redfish Service Validator.
Depends-On: I83dcbe4810139fb92fddf6b099f5a1a057e7e05e
Depends-On: I1d5abfa5d4416af3565bf315e0f28cb6af56f14c
Change-Id: I23a40f9c74c6c368c04488af727e0889fc44e010
Signed-off-by: Ender Hsieh <andhsieh@nvidia.com>
|
|
Adds FanSpeedsPercent information according to the Redfish
EnvironmentMetrics schema [1]. The schema only allows fans of
ReadingType Percent to be included in the FanSpeedsPercent array.
The Redfish Uri supports retrieval of the metrics for a specific
chassis:
```
/redfish/v1/Chassis/<chassisId>/EnvironmentMetrics
```
The fan sensors connected to the chassis are found by:
1) Find all fans associated to the chassis using the 'cooled_by'
endpoint. [3].
2) Find all sensors associated to each fan using the 'sensors'
endpoint. [4]
3) Retrieve the sensor excerpt data for each sensor.
A similar approach to retrieving the sensor data is used here as
for the proposed implementation for ThermalSubsystem/Fans [2].
[1] https://redfish.dmtf.org/schemas/v1/EnvironmentMetrics.v1_3_2.json
[2] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57657
[3] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/58300
[4] https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#association-type-2-linking-a-low-level-hardware-item-to-its-sensors
Implementation notes:
- The utility function objectExcerptToJson() is used to populate the
SensorFanArrayExcerpt.
- Altered the objectExcerptToJson() function to take a
sensor::ReadingType value for the optional expected sensor type.
Tested: (using hardware simulator)
- Redfish Validator passes.
- With redfish-allow-rotational-fans disabled:
(Note fans that percent cannot be computed have null for Reading
property.)
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"FanSpeedsPercent": [
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0",
"Reading": 100,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_1",
"Reading": 60,
"SpeedRPM": 12036.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_0",
"Reading": 50,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_1",
"Reading": 32,
"SpeedRPM": 12036.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_0",
"Reading": 50,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_1",
"Reading": 25,
"SpeedRPM": 12036.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_0",
"Reading": null,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_1",
"Reading": null,
"SpeedRPM": 12036.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_0",
"Reading": null,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_1",
"Reading": null,
"SpeedRPM": 12036.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan5_0",
"Reading": null,
"SpeedRPM": 18000.0
},
{
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan5_1",
"Reading": null,
"SpeedRPM": 12036.0
}
],
"FanSpeedsPercent@odata.count": 12,
"Id": "EnvironmentMetrics",
"Name": "Chassis Environment Metrics"
}
```
- Can see DataSourceUri match Sensors fan paths of ReadingType Percent:
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors | grep fan
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_1"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan1_1"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan2_1"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan3_1"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan4_1"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan5_0"
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan5_1"
// E.g.
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0",
"@odata.type": "#Sensor.v1_11_1.Sensor",
"Id": "fantach_fan0_0",
...
"ReadingType": "Percent",
...
```
- With redfish-allow-rotational-fans enabled the only fans are not
Percent ReadingType so are not added to the FanSpeedsPercent array :
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"FanSpeedsPercent": [],
"FanSpeedsPercent@odata.count": 0,
"Id": "EnvironmentMetrics",
"Name": "Chassis Environment Metrics"
}
// E.g.
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/fantach_fan0_0",
"@odata.type": "#Sensor.v1_11_1.Sensor",
"Id": "fantach_fan0_0",
...
"ReadingType": "Rotational",
...
```
Signed-off-by: George Liu <liuxiwei@inspur.com>
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
Change-Id: I4cfc0aa28d68e7e0fa947251363deb6f06e36225
|
|
This patch enable support for following properties for Port of a PCIe
Switch. [1]
- PortProtocol
- PortType
- CurrentSpeedGbps
- ActiveWidth
One of the devices that gets enabled with this patch is Nvidia ConnectX
devices, which are network cards featuring an integrated PCIe switch.
These devices combine both PCIe ports and network ports in a single
unit. Since such devices don't strictly qualify as Fabric Adapters, the
Switch URI is used instead of the FabricAdapter URI.
Port schema only allows certain URIs as Port URI. URI
/redfish/v1/Fabrics/{FabricId}/Switches/{SwitchId}/Ports/{PortId} seems
most appropriate choice for PCIe Switch Port. [1]
The Fabric resource is modeled similarly to the System resource, meaning
that only one Fabric resource will exist for each BMC. Route handler for
collections and each individual components are added in this patch for
each URI resource under /redfish/v1/Fabrics.
DBus Interface "xyz.openbmc_project.Inventory.Item.PCIeSwitch" is used
to identify the Switch resources. Association between Switch and Port is
`connecting` and `connected_to`.
Feature like Port Metrics properties (for PCIe Error Counters) can be
added in future at Port Metric URI.
dbus-sensors patches -
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84079
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/83202
Tested: Build an image for nvl32-obmc machine with the following patch
cherry picked.
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/84079
https://gerrit.openbmc.org/c/openbmc/openbmc/+/85490
The openbmc patch cherry-picks the following patches that are currently
under review.
```
1. device tree
https://lore.kernel.org/all/aRbLqH8pLWCQryhu@molberding.nvidia.com/
2. mctpd patches
https://github.com/CodeConstruct/mctp/pull/85
3. u-boot changes
https://lore.kernel.org/openbmc/20251121-msx4-v1-0-fc0118b666c1@nvidia.com/T/#t
4. kernel changes as specified in the openbmc patch (for espi)
5. entity-manager changes
https://gerrit.openbmc.org/c/openbmc/entity-manager/+/85455
6. platform-init changes
https://gerrit.openbmc.org/c/openbmc/platform-init/+/85456
7. spi changes
https://lore.kernel.org/all/20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com/
```
redfish service validator is passing.
```
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/
{
"@odata.id": "/redfish/v1/Fabrics",
"@odata.type": "#FabricCollection.FabricCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Fabrics/fabric"
}
],
"Members@odata.count": 1,
"Name": "Fabric Collection"
}%
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/
{
"@odata.id": "/redfish/v1/Fabrics/fabric",
"@odata.type": "#Fabric.v1_2_0.Fabric",
"Id": "fabric",
"Name": "fabric Fabric",
"Switches": {
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches"
}
}%
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches",
"@odata.type": "#SwitchCollection.SwitchCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0"
},
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_1"
},
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_2"
},
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_3"
}
],
"Members@odata.count": 4,
"Name": "fabric Switch Collection"
}%
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0",
"@odata.type": "#Switch.v1_7_0.Switch",
"Id": "Nvidia_ConnectX_0",
"Name": "Nvidia_ConnectX_0",
"Ports": {
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports"
},
"Status": {
"Health": "OK",
"State": "Enabled"
}
}%
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports",
"@odata.type": "#PortCollection.PortCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/DOWN_0"
},
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/DOWN_1"
},
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0"
}
],
"Members@odata.count": 3,
"Name": "Nvidia_ConnectX_0 Port Collection"
}%
$ curl -k -u 'root:0penBmc' https://${bmc_ip}/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/
{
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0",
"@odata.type": "#Port.v1_4_0.Port",
"ActiveWidth": 8,
"CurrentSpeedGbps": 32.0,
"Id": "UP_0",
"Metrics": {
"@odata.id": "/redfish/v1/Fabrics/fabric/Switches/Nvidia_ConnectX_0/Ports/UP_0/Metrics"
},
"Name": "Nvidia_ConnectX_0 UP_0 Port",
"PortProtocol": "PCIe",
"PortType": "UpstreamPort",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}%
```
[1]: https://redfish.dmtf.org/schemas/v1/Port_v1.xml
Change-Id: I52f4ca62b4953f6196c589e340602a0d7885d9c1
Signed-off-by: Harshit Aghera <haghera@nvidia.com>
|
|
nlohmann::json::begin() throws an uncaught exception.
Tested: Redfish service validator passes.
Signed-off-by: Ed Tanous <ed@tanous.net>
Change-Id: I08244b0787cd4d6e592b0731196490a5160aba62
|
|
Implement LocationIndicatorActive for Assembly schema to set and get the
status of the location LED. A client uses the `LocationIndicatorActive`
property to physically identify or locate the assembly.
The assembly is an array of AssemblyData [1], and the element of the
array can be patched as explained in [2].
```
{
"Assemblies": [
{},
{},
{
"LocationIndicatorActive": true
},
{}
]
}
```
Tested:
- Validator passes.
-
1. Get LocationIndicatorActive
```
curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Assembly
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly",
"@odata.type": "#Assembly.v1_6_0.Assembly",
"Assemblies": [
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/0",
"@odata.type": "#Assembly.v1_6_0.AssemblyData",
"LocationIndicatorActive": false,
"MemberId": "0",
...
},
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/1",
"@odata.type": "#Assembly.v1_6_0.AssemblyData",
"LocationIndicatorActive": false,
"MemberId": "1",
...
}
],
"Assemblies@odata.count": 2,
"Id": "Assembly",
"Name": "Assembly Collection"
}
```
2. Set LocationIndicatorActive to true
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" \
-X PATCH -d '{"Assemblies":[{"LocationIndicatorActive":true},{}]}' \
https://${bmc}/redfish/v1/Chassis/chassis/Assembly
```
Then we will see the location LED lit up, and the
LocationIndicatorActive value becomes true.
```
curl -k -H "X-Auth-Token: $token" -X GET https://${bmc}/redfish/v1/Chassis/chassis/Assembly
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly",
"@odata.type": "#Assembly.v1_6_0.Assembly",
"Assemblies": [
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/0",
"@odata.type": "#Assembly.v1_6_0.AssemblyData",
"LocationIndicatorActive": true,
"MemberId": "0",
...
},
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/1",
"@odata.type": "#Assembly.v1_6_0.AssemblyData",
"LocationIndicatorActive": false,
"MemberId": "1",
...
}
],
"Assemblies@odata.count": 2,
"Id": "Assembly",
"Name": "Assembly Collection"
}
```
If the input array size is different from the existing assemblies, it
will cause an error like
```
curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" \
-X PATCH -d '{"Assemblies":[{},{"LocationIndicatorActive":true},{}]}' \
https://${bmc}/redfish/v1/Chassis/chassis/Assembly
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The array provided for property Assemblies exceeds the size limit 2.",
"MessageArgs": [
"Assemblies",
"2"
],
"MessageId": "Base.1.19.ArraySizeTooLong",
"MessageSeverity": "Warning",
"Resolution": "Resubmit the request with an appropriate array size."
}
],
"code": "Base.1.19.ArraySizeTooLong",
"message": "The array provided for property Assemblies exceeds the size limit 2."
}
}%
```
[1] https://redfish.dmtf.org/schemas/v1/Assembly.v1_6_0.json
[2] https://redfishforum.com/thread/437/patch-individual-items-array-objects
Change-Id: Ic2e87f5daeb7ebed161654bb54ac29e7d5daa482
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
Add support for PeakReading and PeakReadingTime for sensors. This
enhancement allows sensor readings to include max observed value
information in the Redfish API, along with timestamp. It uses PDI
xyz.openbmc_project.Telemetry.Report. Property PeakReading is added if
OperationType in PDI property ReadingParameters is set to Maximum.
Current Limitation -
The ResetMetrics action is currently not supported for sensor URIs. As a
result, the ability to clear PeakReading values for GPU Power Sensors
has not been implemented.
Future Consideration -
If ResetMetrics action support is added in the future, the corresponding
functionality will also need to be implemented in the dbus-sensor
application to ensure full compatibility.
Schema:
https://redfish.dmtf.org/schemas/v1/Sensor.v1_2_0.yaml (PeakReading)
Backend implementation for reference:
https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/82479
Tested: Build an image for nvl32-obmc machine with the following patches
cherry picked.
https://gerrit.openbmc.org/c/openbmc/openbmc/+/85490
https://gerrit.openbmc.org/c/openbmc/bmcweb/+/82449.
The patch cherry-picks the following patches that are currently under
review.
```
1. device tree
https://lore.kernel.org/all/aRbLqH8pLWCQryhu@molberding.nvidia.com/
2. mctpd patches
https://github.com/CodeConstruct/mctp/pull/85
3. u-boot changes
https://lore.kernel.org/openbmc/20251121-msx4-v1-0-fc0118b666c1@nvidia.com/T/#t
4. kernel changes as specified in the openbmc patch (for espi)
5. entity-manager changes
https://gerrit.openbmc.org/c/openbmc/entity-manager/+/85455
6. platform-init changes
https://gerrit.openbmc.org/c/openbmc/platform-init/+/85456
7. spi changes
https://lore.kernel.org/all/20251121-w25q01jv_fixup-v1-1-3d175050db73@nvidia.com/
```
```
> curl -s -k -u 'root:0penBmc' https://10.137.203.137/redfish/v1/Chassis/NVIDIA_GB200_1/Sensors/power_NVIDIA_GB200_GPU_0_Power_0
{
"@odata.id": "/redfish/v1/Chassis/NVIDIA_GB200_1/Sensors/power_NVIDIA_GB200_GPU_0_Power_0",
"@odata.type": "#Sensor.v1_2_0.Sensor",
"Id": "power_NVIDIA_GB200_GPU_0_Power_0",
"Name": "NVIDIA GB200 GPU 0 Power 0",
"PeakReading": 52.671,
"PeakReadingTime": 0,
"Reading": 27.214,
"ReadingRangeMax": 5000.0,
"ReadingRangeMin": 0.0,
"ReadingType": "Power",
"ReadingUnits": "W",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}%
````
Change-Id: I8c1ab6ce85f31419db4a1d931bf99722d24afbd7
Signed-off-by: Harshit Aghera <haghera@nvidia.com>
|
|
In order to get access to the EventLog on multi-host platforms,
add Journal EventLog to Manager.
This implementation is based on the discussion we had on
patch 76319 [1].
TLDR: On multi-host, we technically would have to split the event log
on a per host node basis, so that each host node has its own
specific event log.
However, this is currently not supported so we had to decide,
whether we put it on a specific ComputerSystem, or refactor the current
implementation of the EventLog, to allow for the EventLog LogService to
be part of the Managers resource.
We chose the latter one, because a), it is not clear on which
ComputerSystem to put the EventLog, as long as we aren't splitting the
event log per host node, and b), if that particular
ComputerSystem is not existing at runtime, there would be no access to
the EventLog at all.
This feature can be enabled with the redfish-eventlog-location meson
option. By default it is set to 'systems', which translates to the
EventLog being under the Systems resource.
To enable the EventLog under the Managers resource set
```
-Dredfish-eventlog-location=managers
```
This in turn, disables the EventLog under the ComputerSystem resource.
Tested: Redfish validation succeeded for both ComputerSystem and
Managers tree.
```
curl command:
curl -w "@curl-format.txt" -c cjar -b cjar -k -X GET 'https://'"${BMC}"':4443/redfish/v1/'"$ROUTE"'' \
-H 'X-Auth-Token: '"$BMCWEB_SESSION_TOKEN"''
GET /redfish/v1/Managers/bmc/LogServices
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices",
"@odata.type": "#LogServiceCollection.LogServiceCollection",
"Description": "Collection of LogServices for this Manager",
"Members": [
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/Journal"
},
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog"
}
],
"Members@odata.count": 2,
"Name": "Open BMC Log Services Collection"
}
GET /redfish/v1/Managers/bmc/LogServices/EventLog
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog",
"@odata.type": "#LogService.v1_2_0.LogService",
"Actions": {
"#LogService.ClearLog": {
"target": "/redfish/v1/Managers/bmc/LogServices/EventLog/Actions/LogService.ClearLog"
}
},
"DateTime": "2025-09-24T15:22:36+00:00",
"DateTimeLocalOffset": "+00:00",
"Description": "Manager Event Log Service",
"Entries": {
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries"
},
"Id": "EventLog",
"Name": "Event Log Service",
"OverWritePolicy": "WrapsWhenFull"
}
GET /redfish/v1/Managers/bmc/LogServices/EventLog/Entries
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries",
"@odata.type": "#LogEntryCollection.LogEntryCollection",
"Description": "Collection of Manager Event Log Entries",
"Members": [
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576",
"@odata.type": "#LogEntry.v1_9_0.LogEntry",
"Created": "2024-10-27T06:12:56+00:00",
"EntryType": "Event",
"Id": "1730009576",
"Message": "Host system DC power is off",
"MessageArgs": [],
"MessageId": "OpenBMC.0.1.DCPowerOff",
"Name": "Manager Event Log Entry",
"Severity": "OK"
},
...
],
"Members@odata.count": 2820,
"Members@odata.nextLink": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries?$skip=1000",
"Name": "Manager Event Log Entries"
}
GET /redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576
{
"@odata.id": "/redfish/v1/Managers/bmc/LogServices/EventLog/Entries/1730009576",
"@odata.type": "#LogEntry.v1_9_0.LogEntry",
"Created": "2024-10-27T06:12:56+00:00",
"EntryType": "Event",
"Id": "1730009576",
"Message": "Host system DC power is off",
"MessageArgs": [],
"MessageId": "OpenBMC.0.1.DCPowerOff",
"Name": "Manager Event Log Entry",
"Severity": "OK"
}
```
ClearLog action:
Log files are being successfully deleted from /var/log
[1] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/76319
Change-Id: If5b4fe10151b6bfd28a1b49c41f8cfcec1b9132c
Signed-off-by: Oliver Brewka <oliver.brewka@9elements.com>
|
|
Add support for ReadingBasis and Implementation sensor properties. These
properties are defined on xyz.openbmc_project.Sensor.Type which will be
optionally implemented by sensor.
DBus Interface definition
- https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/81658
Link to Redfish schema
- https://redfish.dmtf.org/schemas/v1/Sensor.v1_11_0.yaml
Tested: Build an image for gb200nvl-obmc machine with the following
patches cherry picked. This patches are needed to enable the mctp stack.
https://gerrit.openbmc.org/c/openbmc/openbmc/+/79422
Redfish service validator is passing.
```
> curl -s -k -u 'root:0penBmc' https://10.137.203.137/redfish/v1/Chassis/NVIDIA_GB200_1/Sensors/temperature_NVIDIA_GB200_GPU_0_TEMP_1
{
"@odata.id": "/redfish/v1/Chassis/NVIDIA_GB200_1/Sensors/temperature_NVIDIA_GB200_GPU_0_TEMP_1",
"@odata.type": "#Sensor.v1_2_0.Sensor",
"Description": "Thermal Limit(TLIMIT) Temperature is the distance in deg C from the GPU temperature to the first throttle limit.",
"Id": "temperature_NVIDIA_GB200_GPU_0_TEMP_1",
"Implementation": "Synthesized",
"Name": "NVIDIA GB200 GPU 0 TEMP 1",
"Reading": 56.59375,
"ReadingBasis": "Headroom",
"ReadingRangeMax": 127.0,
"ReadingRangeMin": -128.0,
"ReadingType": "Temperature",
"ReadingUnits": "Cel",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}%
root@gb200nvl-obmc:~# busctl introspect xyz.openbmc_project.GpuSensor /xyz/openbmc_project/sensors/temperature/NVIDIA_GB200_GPU_0_TEMP_1
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.Association.Definitions interface - - -
.Associations property a(sss) 1 "chassis" "all_sensors" "/xyz/openb... emits-change
xyz.openbmc_project.Inventory.Item interface - - -
.PrettyName property s "Thermal Limit(TLIMIT) Temperature is... emits-change
xyz.openbmc_project.Sensor.Type interface - - -
.Implementation property s "xyz.openbmc_project.Sensor.Type.Impl... emits-change
.ReadingBasis property s "xyz.openbmc_project.Sensor.Type.Read... emits-change
xyz.openbmc_project.Sensor.Value interface - - -
.MaxValue property d 127 emits-change
.MinValue property d -128 emits-change
.Unit property s "xyz.openbmc_project.Sensor.Value.Uni... emits-change
.Value property d 56.6836 emits-change writable
xyz.openbmc_project.Sensor.ValueMutability interface - - -
.Mutable property b true emits-change
xyz.openbmc_project.State.Decorator.Availability interface - - -
.Available property b true emits-change writable
xyz.openbmc_project.State.Decorator.OperationalStatus interface - - -
.Functional property b true emits-change
```
Change-Id: I61344e8d8c8ef36d7553f33afb5f84643ce1fe4d
Signed-off-by: Harshit Aghera <haghera@nvidia.com>
|
|
This commit is to populate link(s) to processor associated with given
PCIeDevice using the association of `{connecting/connected_to}` via
- https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/81914
(This PDI needs to go first).
This also updates the PCIeDevice schema version for `Links/Processors`
type in PCIeDevice schema.
An example commit is:
- https://gerrit.openbmc.org/c/openbmc/openbmc/+/81919
Tested:
- Validator passes
- GET on PCIe devices which have links to processors
Sample output:
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/PCIeDevices/pcie_card10
{
...
"Links": {
"Processors": [
{
"@odata.id": "/redfish/v1/Systems/system/Processors/cpu0"
}
],
"Processors@odata.count": 1
},
...
}
```
Change-Id: I5cb29087cdb9feedac6cc0d5662e2a6903c3228c
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
The EnvironmentMetrics schema[1] provides for efficient retrieval of
environmental metrics by separating them from performance metrics.
EnvironmentMetrics is a property of the Chassis schema since v1_15_0[2].
EnvironmentMetrics was added to Redfish release 2021.2 [3] to be used
instead of the deprecated Power schema.[4]
This commit adds PowerWatts property of the EnvironmentMetrics schema.
PowerWatts has been part of the EnvironmentMetrics schema since v1_1_0.
PowerWatts is a SensorPowerExcerpt[5].
Implementation notes: The new D-Bus interface
"xyz.openbmc_project.Sensor.Purpose" is used to find the sensor with the
"TotalPower" purpose.[6][7] The new utility function
sensor_utils::getSensorsByPurpose() returns a subset of an incoming list
of sensors which implement a specified purpose.
Multiple D-Bus calls are needed to find the sensor providing the
totalPower:
1. Retrieve list of power sensors associated with specified chassis
which implement the Sensor.Purpose interface using existing
getAllSensorObjects() function.
2. For each of those power sensors retrieve the actual purpose of the
sensor to find the sensor implementing totalPower purpose. Expect no
more than one sensor to implement this purpose. New utility function
getSensorsByPurpose() is used.
3. If a totalPower sensor is found then retrieve its properties to fill
in PowerWatts in the response using existing
sensor_utils::objectExcerptToJson() utility function.
If no sensor has the "TotalPower" purpose then PowerWatts is
not added to EnvironmentMetrics and no error is returned.
[1] https://redfish.dmtf.org/schemas/v1/EnvironmentMetrics.v1_3_2.json
[2] https://redfish.dmtf.org/schemas/v1/Chassis.v1_25_2.json
[3] http://redfish.dmtf.org/schemas/Redfish_Release_History.pdf
[4] https://redfish.dmtf.org/schemas/v1/Power.v1_7_3.json
[5] http://redfish.dmtf.org/schemas/v1/Sensor.v1_9_1.json#/definitions/SensorPowerExcerpt
[6] https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/75943
[7] https://gerrit.openbmc.org/c/openbmc/openpower-occ-control/+/77408
Tested:
- Updated unit tests for new environmentMetricsNode enum
- Redfish Service Validator passes (confirmed PowerWatts tested)
```
VERBOSE1 - ServiceRoot -> Chassis -> Members#4 -> EnvironmentMetrics, EnvironmentMetrics.v1_3_0, EnvironmentMetrics
VERBOSE1 - @odata.id PASS
VERBOSE1 - @odata.type PASS
VERBOSE1 - Id PASS
VERBOSE1 - Name PASS
VERBOSE1 - PowerWatts PASS
```
- No "TotalPower" sensor exists (system never powered on).
PowerWatts is not shown and no error is returned.
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"Id": "EnvironmentMetrics",
"Name": "Chassis Environment Metrics"
}
```
- "TotalPower" sensor exists (system powered on)
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Systems/system | grep PowerState
"PowerState": "On",
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"Id": "EnvironmentMetrics",
"Name": "Chassis Environment Metrics",
"PowerWatts": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/power_total_power",
"Reading": 191.0
}
}
```
DataSourceUri is a valid sensor:
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors/power_total_power
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/power_total_power",
"@odata.type": "#Sensor.v1_2_0.Sensor",
"Id": "power_total_power",
"Name": "total power",
"Reading": 191.0,
"ReadingType": "Power",
"ReadingUnits": "W",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
- "TotalPower" sensor exists but null value (system powered off)
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Systems/system | grep PowerState
"PowerState": "Off",
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/EnvironmentMetrics
{
"@odata.id": "/redfish/v1/Chassis/chassis/EnvironmentMetrics",
"@odata.type": "#EnvironmentMetrics.v1_3_0.EnvironmentMetrics",
"Id": "EnvironmentMetrics",
"Name": "Chassis Environment Metrics",
"PowerWatts": {
"DataSourceUri": "/redfish/v1/Chassis/chassis/Sensors/power_total_power",
"Reading": null
}
}
```
And again the DataSourceUri points to a valid sensor:
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassis/Sensors/power_total_power
{
"@odata.id": "/redfish/v1/Chassis/chassis/Sensors/power_total_power",
"@odata.type": "#Sensor.v1_2_0.Sensor",
"Id": "power_total_power",
"Name": "total power",
"Reading": null,
"ReadingType": "Power",
"ReadingUnits": "W",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
- Invalid chassis id ("TotalPower" sensor exists)
```
curl -k -H "X-Auth-Token: $token" https://${bmc}/redfish/v1/Chassis/chassisBAD/EnvironmentMetrics
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type Chassis named 'chassisBAD' was not found.",
"MessageArgs": [
"Chassis",
"chassisBAD"
],
"MessageId": "Base.1.19.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.19.ResourceNotFound",
"message": "The requested resource of type Chassis named 'chassisBAD' was not found."
}
}
```
Signed-off-by: George Liu <liuxiwei@inspur.com>
Signed-off-by: Janet Adkins <janeta@us.ibm.com>
Change-Id: Ibe84a5e7fe0d2b232f925e457a094c021ca85d36
|
|
Considering we seem to have a general consensus that this pattern is
tough to read, lets document it so that we have something to point to
in code reviews.
Change-Id: I7d2a45c5c1dfea29f612e716824c84789e21a510
Signed-off-by: Ed Tanous <etanous@nvidia.com>
|
|
This pattern shows up a lot in code review. Being able to have it
documented will help with code review time, and hopefully will reduce
the instances of this showing up.
Change-Id: Ia3b1498866cde25526b537916e2ac54ff0818a17
Signed-off-by: Ed Tanous <etanous@nvidia.com>
|
|
This commit implements Redfish Assembly schema.
This schema will be used to publish inventory data for FRUs which are
attached to a given Chassis and does not map to any specific schema
definition.
The properties which are published in this commit are LocationCode,
SparePartNumber, Model, SerialNumber and PartNumber.
One of the major use case to publish these properties via redfish is for
anyone to identify the inventory and its location in the system, which
in turn will help them in repair/replacement related to that FRU.
The validator has been executed on the change and no error has been
found.
As this has been tested on a development image some fields are empty
in the below pasted output for which warning was thrown by validator but
no errors.
Sample Output with [1]:
```
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly",
"@odata.type": "#Assembly.v1_5_1.Assembly",
"Assemblies": [
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/0",
"@odata.type": "#Assembly.v1_5_1.AssemblyData",
"Location": {
"PartLocation": {
"ServiceLabel": "U78DA.ND0.1234567-D0"
}
},
"Manufacturer": "",
"MemberId": "0",
"Model": "",
"Name": "base_op_panel_blyth",
"PartNumber": "",
"SerialNumber": "",
"Status": {
"Health": "OK",
"State": "Absent"
}
},
{
"@odata.id": "/redfish/v1/Chassis/chassis/Assembly#/Assemblies/1",
"@odata.type": "#Assembly.v1_5_1.AssemblyData",
"Location": {
"PartLocation": {
"ServiceLabel": "U78DA.ND0.1234567-D1"
}
},
"Manufacturer": "",
"MemberId": "1",
"Model": "6B86",
"Name": "lcd_op_panel_hill",
"PartNumber": "PN12345",
"SerialNumber": "YL6B86010000",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
],
"Assemblies@odata.count": 2,
"Id": "Assembly",
"Name": "Assembly Collection"
}
```
[1] https://gerrit.openbmc.org/c/openbmc/openbmc/+/83907
Change-Id: I2d462340fe1a0b0eb387697f0ff70fcafde3f8d9
Signed-off-by: Sunny Srivastava <sunnsr25@in.ibm.com>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
Solution to reduce compressed rofs size.
Conclusion: The compiler is better at reducing binary size than the rofs
compression is at deduplicating sections of already compiled binaries,
in the case of bmcweb.
What's been changed?
`bmcweb` and `bmcwebd` have been merged into `bmcweb`.
The webserver can be started with `bmcweb daemon`.
Commands used to check size
```
wc -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs
wc -c build/s8030/tmp/deploy/images/s8030/image-rofs
xz -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/rootfs/bin/bmcweb | wc -c
xz -c build/s8030/tmp/work/*-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/rootfs/usr/libexec/bmcwebd | wc -c
```
Base commit used for testing:
`2169e896448fac1b59c57516b381492e4b2161c7`
Results:
Before patch:
```
image-rofs compressed size:
25526272 build/s8030/tmp/work/s8030-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs
rootfs
25526272 build/s8030/tmp/deploy/images/s8030/image-rofs
bmcweb cli
95424
bmcwebd
1016004
```
After patch:
```
image-rofs compressed size:
25477120 build/s8030/tmp/work/s8030-openbmc-linux-gnueabi/obmc-phosphor-image/1.0/obmc-phosphor-image-1.0/static/image-rofs
rootfs
25477120 build/s8030/tmp/deploy/images/s8030/image-rofs
bmcweb cli
96
bmcwebd
1059556
```
Calculating the difference in compressed rofs
25526272 - 25477120 = 49152
which is around 0.2% in terms of the total image but around 4.6% in
terms of bmcwebd binary.
Tested: on yosemite4 qemu
`bmcweb` cli interactions work as before.
```
root@yosemite4:~# bmcweb --help
BMCWeb CLI
Usage: bmcweb [OPTIONS] SUBCOMMAND
Options:
-h,--help Print this help message and exit
Subcommands:
loglevel Set bmcweb log level
daemon Run webserver
root@yosemite4:~# bmcweb loglevel info
<6>[webserver_cli.cpp:97] logging level changed to: INFO
root@yosemite4:~# bmcweb loglevel
level is required
Run with --help for more information.
root@yosemite4:~# bmcweb loglevel debug
<6>[webserver_cli.cpp:97] logging level changed to: DEBUG
```
systemd service still working
```
root@yosemite4:~# systemctl status bmcweb
● bmcweb.service - Start bmcweb server
Loaded: loaded (/usr/lib/systemd/system/bmcweb.service; enabled; preset: enabled)
Active: active (running) since Thu 2025-04-03 13:35:45 PDT; 5 months 15 days ago
```
Change-Id: Ib5dde568ac1c12c5414294ed96404c6a69417424
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
|
This implements `LocationIndicatorActive` property for Fabric port using
the following methods.
- `getLocationIndicatorActive()`
- `setLocationIndicatorActive()`
Tested:
- Validator passes
- Run GET/PATCH of LocationIndicatorActive
```
$ curl -k -H "X-Auth-Token: $token" -X GET \
https://${bmc}/redfish/v1/Systems/system/FabricAdapters/pcie_cable_card10/Ports/cxp_top
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/ \
pcie_cable_card10/Ports/cxp_top",
"@odata.type": "#Port.v1_11_0.Port",
"Id": "Port",
"LocationIndicatorActive": true,
"Name": "cxp_top"
}
$ curl -k -H "X-Auth-Token: $token" -X GET \
https://${bmc}/redfish/v1/Systems/system/FabricAdapters/pcie_cable_card10/Ports/cxp_bot
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/ \
pcie_cable_card10/Ports/cxp_bot",
"@odata.type": "#Port.v1_11_0.Port",
"Id": "Port",
"LocationIndicatorActive": false,
"Name": "cxp_bot"
}
```
```
$ curl -k -H "Content-Type: application/json" -X PATCH -d \
'{"LocationIndicatorActive":false}' \
https://${bmc}/redfish/v1/Systems/system/FabricAdapters/pcie_cable_card10/Ports/cxp_top
$ curl -k -H "X-Auth-Token: $token" -X GET \
https://${bmc}/redfish/v1/Systems/system/FabricAdapters/pcie_cable_card10/Ports/cxp_top
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/ \
pcie_cable_card10/Ports/cxp_top",
"@odata.type": "#Port.v1_11_0.Port",
"Id": "Port",
"LocationIndicatorActive": false,
"Name": "cxp_top"
}
```
Change-Id: I2cfe8a807cd6dc3bf3d6e50658b0d27a1253b887
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
This commit is to add status and health information to Fabric Port like
other Redfish resources which implement State/Health and map them to
Present/Functional respectfully. State / Health of the Port is useful
information for inventory on a GUI/Debug/etc
If the `xyz.openbmc_project.Inventory.Item` interface does not exist,
the state status property is set to default "Enabled".
If the `xyz.openbmc_project.State.Decorator.OperationalStatus`
interface does not exist, the health status property is set to
default "OK".
Tested:
- Redfish Validator passed
- Check status from GET Port output
```
% curl -k -X GET https://${bmc}:18080/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4",
"@odata.type": "#Port.v1_7_0.Port",
"Id": "dp0_connector4",
"Location": {
"PartLocation": {
"ServiceLabel": "U78DA.ND0.WZS003T-P1-T4"
}
},
"Name": "dp0_connector4",
"Status": {
"Health": "OK",
"State": "Enabled"
}
}
```
Change-Id: Ibb625f2ef1378f77c9520426d2687e305b4f8be5
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
This commit is to add location information to Port of FabricAdapter.
If Port LocationCode property is not found, it will not be shown.
Tested:
- Redfish Validator passed
- Check Location from GET Port output
```
% curl -k -X GET https://${bmc}:18080/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4",
"@odata.type": "#Port.v1_7_0.Port",
"Id": "dp0_connector4",
"Location": {
"PartLocation": {
"ServiceLabel": "U78DA.ND0.WZS003T-P1-T4"
}
},
"Name": "dp0_connector4"
}
```
Change-Id: Ie015b19612c03a9c656ad14a3f607da04cb4f901
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
This implements 2 schemas for FabricAdapters [1][2].
The implementation uses `GetAssociatedSubTreePathsById` &
`GetAssociatedSubTreeById`.
- https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/69999
The association is defined via
- https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/62881.
The backend port examples are also committed via
- https://gerrit.openbmc.org/c/openbmc/openpower-vpd-parser/+/66540
- https://gerrit.openbmc.org/c/openbmc/openpower-vpd-parser/+/70888
- https://gerrit.openbmc.org/c/openbmc/openbmc/+/66541
The current submission only implements the basic properties of Port
(e.g. Id, Name etc) as a foundation of the future additional
properties.
- Location
- LocationIndicatorActive
- Status
One example of Ports is this cable card for the i/o expansion drawers
and modeling the 2 ports on the cable card [3]. These ports have an
identify led, a location code, and a status.
Tested:
- Redfish Validator passes
- perform GET methods like these:
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/FabricAdapters/disk_backplane0
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0",
"@odata.type": "#FabricAdapter.v1_4_0.FabricAdapter",
"Id": "disk_backplane0",
...
"Ports": {
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports"
},
...
}
```
```
curl -k -X GET https://${bmc}/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports",
"@odata.type": "#PortCollection.PortCollection",
"Members": [
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4"
},
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector5"
}
],
"Members@odata.count": 2,
"Name": "Port Collection"
}
```
```
curl -k -X GET https://${bmc}:18080/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4
{
"@odata.id": "/redfish/v1/Systems/system/FabricAdapters/disk_backplane0/Ports/dp0_connector4",
"@odata.type": "#Port.v1_7_0.Port",
"Id": "dp0_connector4",
"Name": "dp0_connector4"
}%
```
Also try the invalid port like
```
curl -k -X GET https://${bmc}:18080/redfish/v1/Systems/system/FabricAdapters/io_module1/Ports/INVALID
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The requested resource of type Port named 'INVALID' was not found.",
"MessageArgs": [
"Port",
"INVALID"
],
"MessageId": "Base.1.16.0.ResourceNotFound",
"MessageSeverity": "Critical",
"Resolution": "Provide a valid resource identifier and resubmit the request."
}
],
"code": "Base.1.16.0.ResourceNotFound",
"message": "The requested resource of type Port named 'INVALID' was not found."
}
}%
```
[1] https://redfish.dmtf.org/schemas/v1/PortCollection_v1.xml
[2] https://redfish.dmtf.org/schemas/v1/Port_v1.xml
[3] https://www.ibm.com/docs/en/power10?topic=details-pcie4-cable-adapter-fc-ej24-ccin-6b92
Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I8c64c16764e85c0716e264263708b18f897a2c0c
Signed-off-by: Myung Bae <myungbae@us.ibm.com>
|
|
Implements GET and PATCH support for ServiceIdentification in
Managers/bmc and service root.
Tested:
- Refish Service Validator passes
- Tested on romulus:
1. GET initial value
```
curl -k "https://$BMC/redfish/v1"
{
...
}
```
ServiceIdentification is not yet present in service root,
as expected
```
curl -k -H "X-Auth-Token: $XAUTH_TOKEN" "https://$BMC/redfish/v1/Managers/bmc"
{
...
"ServiceIdentification": "",
...
}
```
2. PATCH and GET with valid value
```
curl -k -X PATCH "https://$BMC/redfish/v1/Managers/bmc" -H "X-Auth-Token: $XAUTH_TOKEN" \
-H 'Content-Type: application/json' --data-raw '{"ServiceIdentification": "foo"}'
{
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The request completed successfully.",
"MessageArgs": [],
"MessageId": "Base.1.19.Success",
"MessageSeverity": "OK",
"Resolution": "None."
}
]
}
curl -k "https://$BMC/redfish/v1"
{
...
"ServiceIdentification": "foo",
...
}
curl -k -H "X-Auth-Token: $XAUTH_TOKEN" "https://$BMC/redfish/v1/Managers/bmc"
{
...
"ServiceIdentification": "foo",
...
}
```
3. PATCH and GET with invalid value
```
curl -k -X PATCH "https://$BMC/redfish/v1/Managers/bmc" -H "X-Auth-Token: $XAUTH_TOKEN" \
-H 'Content-Type: application/json' --data-raw '{"ServiceIdentification": "$$$"}'
{
"ServiceIdentification@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The value provided for the property ServiceIdentification is not valid.",
"MessageArgs": [
"ServiceIdentification"
],
"MessageId": "Base.1.19.PropertyValueError",
"MessageSeverity": "Warning",
"Resolution": "Correct the value for the property in the request body and resubmit the request if the operation failed."
}
]
}
curl -k -X PATCH "https://$BMC/redfish/v1/Managers/bmc" -H "X-Auth-Token: $XAUTH_TOKEN" \
-H 'Content-Type: application/json' --data-raw '{"ServiceIdentification": "2222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222"}'
{
"error": {
"@Message.ExtendedInfo": [
{
"@odata.type": "#Message.v1_1_1.Message",
"Message": "The string 'ServiceIdentification' exceeds the length limit 99.",
"MessageArgs": [
"ServiceIdentification",
"99"
],
"MessageId": "Base.1.19.StringValueTooLong",
"MessageSeverity": "Warning",
"Resolution": "Resubmit the request with an appropriate string length."
}
],
"code": "Base.1.19.StringValueTooLong",
"message": "The string 'ServiceIdentification' exceeds the length limit 99."
}
}
curl -k "https://$BMC/redfish/v1"
{
...
"ServiceIdentification": "foo",
...
}
curl -k -H "X-Auth-Token: $XAUTH_TOKEN" "https://$BMC/redfish/v1/Managers/bmc"
{
...
"ServiceIdentification": "foo",
...
}
```
Change-Id: I5b71a73e947ec64cabb8d93c8503a18fb43b8937
Signed-off-by: Corey Ethington <cethington@coreweave.com>
|
|
To better organize the docs and align with other repos [1],[2],[3],[4]
create a folder for documentation.
Links between the docs have been adjusted to match their new place.
References:
[1] https://github.com/openbmc/phosphor-logging/tree/master/docs
[2] https://github.com/openbmc/entity-manager/tree/master/docs
[3] https://github.com/openbmc/libpldm/tree/main/docs
[4] https://github.com/openbmc/sdbusplus/tree/master/docs
Change-Id: Ibf990d0d78548bc3407b7f98ccf6a650b1744939
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
|
Make ssl keys consistent (and write to the correct location)
Make sessions keyed by connection id
Clean up logging frameworks
Add new static files, and make firmware update work
Make sensors work again
Add better json handling
Change-Id: I531a0fd7d583e049949cf27aa71544808fd7642d
|
|
Fix static dependencies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
