| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The metadata common to all IBM systems is confusingly split between
meta-ibm and meta-witherspoon. Move everything to meta-ibm.
The meta-ibm README is re-written to more accurately reflect the scope
of the layer.
Allow the configuration samples (bblayers.conf.sample,
local.conf.sample) to be sourced from either meta-ibm or
meta-witherspoon until such a time that any workflows and tooling have
had the opportunity to move to meta-ibm.
(From meta-ibm rev: 6e05ef2e90b214eaf4e43ee7027bbbb1d8d09442)
Change-Id: I3ec890d5300f9649c974ea6b9dca93a2e8a889ab
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Support to set the value for ClearSecurityKeys property which can be used to
indicate when certain security keys need to be cleared or reset those values
back to its default state from the system by the host. This property is mapped
to an IPMI sensor and default value will be zero. Setting this property does
not gurantee a successful operation as additional conditions like the physical
presence pin or jumper settings will be checked by the host to clear/reset the
sensitive data.
Tested: Verified that the property is getting created with the expected
default value as zero and can be updated to different values using ipmitool
or busctl command.
1. Default value output:
busctl get-property xyz.openbmc_project.Settings
/org/open_power/control/host0/ClearHostSecurityKeys
org.open_power.Control.TPM.SecurityKeys ClearHostSecurityKeys
y 0
ipmitool -I lanplus -H 9.3.185.33 -U root -P 0penBmc raw 0x04 0x2D 0xE8
00 40 00 00
2. Set to a new value as 5 using busctl command:
busctl set-property xyz.openbmc_project.Settings
/org/open_power/control/host0/ClearHostSecurityKeys
org.open_power.Control.TPM.SecurityKeys ClearHostSecurityKeys y 5
3. After setting to a new value as 5:
ipmitool -I lanplus -H 9.3.185.33 -U root -P 0penBmc raw 0x04 0x2D 0xE8
05 40 00 00
4. ipmitool command to set the value as 4
ipmitool -I lanplus -H 9.3.185.33 -U root -P 0penBmc raw 0x04 0x30 0xE8
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ipmitool -I lanplus -H 9.3.185.33 -U root -P 0penBmc raw 0x04 0x2D 0xE8
09 40 00 00
5. Invalid value test o/p:
ipmitool -I lanplus -H 9.3.185.33 -U root -P 0penBmc raw 0x04 0x30 0xE8
0x00 0x12C 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Given data "0x12C" is invalid.
(From meta-ibm rev: 81a9143100d5d4a7d97350afa1794be694d45590)
Signed-off-by: Jayashankar Padath <jayashankar.padath@in.ibm.com>
Change-Id: I9e12b6e5abb3a9b198921847605a74b771fd9945
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
This commit adds the xyz.openbmc_project.Inventory.Item.Accelerator
interface to IPMI GPU functional sensors.
This was something done earlier by commit
f510f7b6b708b22db1f08faf369994f01edd0ddc.
The same is being ported now to the new sensor config YAML.
Tested:
Loaded this change up on a witherspoon. Verified that the
inventory objects created by host-ipmid now implement the
xyz.openbmc_project.Inventory.Item.Accelerator interface.
busctl call xyz.openbmc_project.ObjectMapper /xyz/openbmc_project/object_mapper
xyz.openbmc_project.ObjectMapper GetSubTree sias
"/xyz/openbmc_project/inventory" 0 1
"xyz.openbmc_project.Inventory.Item.Accelerator"
a{sa{sas}} 6
"/xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card0"
....
....
(From meta-ibm rev: 2b99559bff775f719fb79a5a770b5267bbbd6dcc)
Signed-off-by: Santosh Puranik <santosh.puranik@in.ibm.com>
Change-Id: Ic132c417aca171e23f5d72705461fe3378e194b0
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
YAML configuration files exist scattered throughout the OpenBMC tree and
how they are used is controlled with layers dependencies of virtuals and
preferred providers.
Most of the time the above scheme is very difficult to comprehend. This
patch continues a re-thinking of that approach towards a more
centralized scheme.
Specifically this patch implements a single YAML config recipe for the
ACx22 systems. The logic contained in the recipe was pulled from
all over the OpenBMC tree - the ability to comprehend how the different
YAML files are generated and consumed should be greatly eased.
A couple notable details:
- Specialized tasks for doing deep YAML dictionary merges existed in
the upstream recipes (-hardcoded.yaml, -config.yaml), but it was
observed that simply concatenating the YAML files produced the same
results, so the specialized deep merge logic was not copied here and can
be deprecated upstream.
- Unlike the upstream recipes, acx22-yaml-config is a target recipe and
as such enables MACHINE based overrides.
YAML files were copied from different locations in the tree, and run
through a styling application (pyyaml dump(load(yaml))):
phosphor-ipmi-fru-read-bmc-inventory-native:bmc-fru-config.yaml ->
acx22-yaml-config:acx22-ipmi-fru-bmc.yaml
phosphor-ipmi-fru-read-not-sent-by-host-inventory-native:fru-config-not-sent-by-host.yaml ->
acx22-yaml-config:acx22-ipmi-fru-not-sent-by-host.yaml
phosphor-ipmi-host:occ_sensors.hardcoded.yaml ->
acx22-yaml-config:acx22-ipmi-occ-sensors.yaml
phosphor-ipmi-host:hwmon_sensors.hardcoded.yaml ->
acx22-yaml-config:acx22-ipmi-hwmon-sensors.yaml
phosphor-ipmi-host:witherspoon_hwmon_sensors.hardcoded.yaml ->
acx22-yaml-config:ac922-ipmi-extra-hwmon-sensors.yaml
phosphor-ipmi-sensor-inventory-mrw-config-native:config.yaml ->
acx22-yaml-config:acx22-ipmi-sensors-mrw.yaml
(From meta-ibm rev: 3cb4a62140dca941e801026f447f13374cf68968)
Change-Id: Id0584812bbf40c0118c8c4383d9dd67c38a45dec
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
