Feedback on Current OpenBMC and Proposing Some Improvements ---- Difficulties and Issue Examples

[Alex Qiu]

(Splitted from main email thread "Feedback on Current OpenBMC and Proposing
Some Improvements")

Difficulties

The current architecture allows different JSON configuration files to be
loaded to represent varieties of FRUs and boards, however, the architecture
still emphasizes individual sensors internally, and there are no solid
concepts of individual FRUs and entities as a whole object in memory. This
data-driven architecture starts to cause difficulties on the implementation
when some sensors require specialized treatments according to requirement
of hardware platforms.

Due to having no place for code as control flow around the sensors or data
purely generated based on configuration files:

   1.

   When the current configuration format cannot express a hardware topology
   or topology discovery logic, a new schema is added case by case. This not
   only causes burden to the configuration files themselves but also the
   configuration file parser. In practice, some code is often preferred to
   intervene around the hardware topology.
   2.

   It is hard for developers to debug against a certain hardware, as the
   developer has to filter the log for it based on various condition
   statements.
   3.

   It is hard for new developers to ramp up on debugging, because there is
   no symbol for developers to quickly look up and find the code related to
   one hardware or module to put debug statements.
   4.

   Unfortunately, debugging hardware issues occupy the life of BMC
   developers quite often, then debug codes are sometimes asked to be turned
   into workarounds which will stay in the code base. The harder to debug, the
   even harder it is to put up an elegant workaround for hardware issues.
   5.

   If the OpenBMC framework does not provide enough flexibility to
   accommodate specialized code for specific requirements, they quickly become
   downstream patches and technical debts, and they cause cost on maintenance
   as an open source software.

Issue Examples

In this section, I will describe issues that we’re facing with the existing
dynamic software stack, and they should all be well handled by
"Improvements".
Configuring device registers according to needs

For the context, related discussions can be found in the mailing list
archive
<https://lists.ozlabs.org/pipermail/openbmc/2020-January/020078.html>
“Configuring shunt_resistor in hwmon”. Although we managed to properly
adjust the IPMI readouts using scales, we later realized that it would
still be better to configure it directly in hwmon sysfs. If we configure it
in hwmon, we can have the correct reading right from the bottom. On the
other hand, an implementation using the device tree is probably against the
idea of having the dynamic software stack to configure hardware only when
discovered.

Also, hardware engineers came up with requests to configure the voltage
regulator outputs, and from my understanding, this is not what hwmon sysfs
interface intended to do, and we needed that within a very short time
period. I had to use shell script to configure the device registers by
issuing raw I2C commands using i2ctools.

All these requirements ended up in shell scripts run as standalone services
aside from OpenBMC applications, which had their own hardware topology
discovery logic inside them. This may be redundant to what we do in the
dynamic software stack.
Handling special requirements and logics

As our hardware program progresses, we are maintaining more and more
patches in Yocto to apply upon entity-manager and dbus-sensors.

We had to replace some code logic due to various reasons, for example, we
found the existing 8-bit / 16-bit addressable EEPROM detection logic is not
stable enough, and we were left with 8-bit addressable EEPROMs with their
content corrupted in the first byte.


(Continuing to thread "Feedback on Current OpenBMC and Proposing Some
Improvements ---- "Improvements" Ideas")


- Alex Qiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200618/7c5d1ff3/attachment-0001.htm>