systemd: no installation in templated targets

Upstream yocto introduced a change via e510222 (systemd-systemctl:
fix instance template WantedBy symlink construction).

This fixes a bug that we in OpenBMC had been taking advantage of in that
we were able to document our templated target dependencies without it
actually doing anything. The real installation of services within
targets occurs in our bitbake recipes due to the complexity of chassis
and host instances on a per machine basis.

Leave the dependency information in the service files but comment them
out. It's useful to be able to look at a service and understand which
targets it's going to be installed into by the bitbake recipes.

In some cases, we had hard coded the target instance, which does install
the service correctly, but only in that one target. All services should
be installed via the bitbake recipe to ensure the service is properly
installed in all instances of the target. Once the bump for this commit
goes into openbmc/openbmc, I will ensure the recipe is updated to
install all services correctly.

Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
3 files changed
tree: 4ee0bc7d9789698352c559ed2017548f57915f64
  1. cold-redundancy/
  2. example/
  3. org/
  4. phosphor-power-sequencer/
  5. phosphor-power-supply/
  6. phosphor-regulators/
  7. power-sequencer/
  8. power-supply/
  9. services/
  10. test/
  11. tools/
  12. .clang-format
  13. .gitignore
  14. .shellcheck
  15. argument.hpp
  16. device.hpp
  17. device_monitor.hpp
  18. elog-errors.hpp
  19. file_descriptor.hpp
  20. gpio.cpp
  21. gpio.hpp
  22. LICENSE
  23. meson.build
  24. meson_options.txt
  25. names_values.hpp
  26. OWNERS
  27. pmbus.cpp
  28. pmbus.hpp
  29. README.md
  30. types.hpp
  31. utility.cpp
  32. utility.hpp
README.md

Overview

This repository contains applications for configuring and monitoring devices that deliver power to the system.

  • cold-redundancy: Application that makes power supplies work in Cold Redundancy mode and rotates them at intervals.
  • phosphor-power-sequencer: Applications for configuring and monitoring power sequencer and related devices that support JSON-driven configuration.
  • phosphor-power-supply: Next generation power supply monitoring application.
  • phosphor-regulators: JSON-driven application that configures and monitors voltage regulators.
  • power-sequencer: A power sequencer monitoring application.
  • power-supply: Original power supply monitoring application.
  • tools/power-utils: Power supply utilities.

Build

To build all applications in this repository:

  meson build
  ninja -C build

To clean the repository and remove all build output:

  rm -rf build

You can specify meson options to customize the build process. For example, you can specify:

  • Which applications to build and install.
  • Application-specific configuration data, such as power sequencer type.
  • Whether to build tests.

Power Supply Monitor and Util JSON config

Several applications in this repository require a PSU JSON config to run. The JSON config file provides information for:

  • Where to access the pmbus attributes
  • Which attribute file in pmbus maps to which property and interface in D-Bus
  • Which kernel device directory is used on which PSU

There is an example psu.json to describe the necessary configurations.

  • inventoryPMBusAccessType defines the pmbus access type, which tells the service which sysfs type to use to read the attributes. The possible values are:
    • Base: The base dir, e.g. /sys/bus/i2c/devices/3-0069/
    • Hwmon: The hwmon dir, e.g. /sys/bus/i2c/devices/3-0069/hwmon/hwmonX/
    • Debug: The pmbus debug dir, e.g. /sys/kernel/debug/pmbus/hwmonX/
    • DeviceDebug: The device debug dir, e.g. '/sys/kernel/debug/./`
    • HwmonDeviceDebug: The hwmon device debug dir, e.g. /sys/kernel/debug/pmbus/hwmonX/cffps1/
  • fruConfigs defines the mapping between the attribute file and the FRU inventory interface and property. The configuration example below indicates that the service will read part_number attribute file from a directory specified by the above pmbus access type, and assign to PartNumber property in xyz.openbmc_project.Inventory.Decorator.Asset interface.
      "fruConfigs": [
        {
          "propertyName": "PartNumber",
          "fileName": "part_number",
          "interface": "xyz.openbmc_project.Inventory.Decorator.Asset"
        }
      ]
    
  • psuDevices defines the kernel device dir for each PSU in inventory. The configuration example below indicates that powersupply0's device is located in /sys/bus/i2c/devices/3-0069.
      "psuDevices": {
        "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0" : "/sys/bus/i2c/devices/3-0069",
      }