openbmc/openbmc-tools

This repository is not one integrated application; it is a toolbox of mostly independent OpenBMC utilities and one-off scripts. The main architectural boundary is per-directory: each top-level folder is its own small tool, with its own runtime, packaging, and dependencies.

The repository is organized around a few recurring interaction surfaces in OpenBMC: D-Bus, journald/log files, IPMI, sensor/I2C hardware, and boot/reboot workflows. Most tools are thin adapters that either query one of those surfaces, transform captured data, or automate a repeated operator task.

A large subset is low-level hardware and sensor tooling. Examples include adcapp, pwmtachtool, bi2cp, i2c/tree.py, and sensor_yaml_config. These tools map directly onto device interfaces such as ADCs, PWM/tachometer control, I2C topology, and sensor configuration files. Their data flow is typically “read hardware or config -> report/transform values” rather than service-to-service orchestration.

Another important subsystem is D-Bus capture and visualization. dbus-pcap captures bus traffic into packet-capture form, while dbus-vis and dbusView consume those captures and render timelines/interactive views in a browser/JS stack. This forms a clear offline analysis pipeline: live bus activity -> capture file -> visualization.

Logging and diagnostics are handled by small, file-oriented analyzers such as pretty-journal, check_journal, and nginx-log-analysis. These tools read existing logs, normalize or summarize them, and emit human-readable diagnostics. They are not daemons; they are operator-facing post-processing tools.

Boot and reboot automation is another distinct cluster. reboot, reboot-ping-pong, netboot, prepare-emmc-qemu, and pldm/pdrdump.sh all support firmware bring-up, reboot validation, or test-environment preparation. The typical flow here is “drive a board/QEMU/system action -> observe boot outcome or generated state.”

There is a command-line management layer for interacting with OpenBMC itself. openbmctool is the main example; it is a Python CLI with a policyTable.json that suggests command/permission mapping or request shaping. witherspoon-debug, altitude, overlay, and bbdbg are similarly specialized utilities for board-specific or platform-specific debugging.

Several directories are meta-tooling for repository and process automation rather than OpenBMC runtime interaction. tof-voters analyzes Gerrit reviews/commits against configured patterns, cla-signers manages CLA-related signer data, and openbmc-autobump automates version or dependency bumps. These tools connect to external developer workflow systems such as Gerrit and operate on repository metadata rather than device state.

There is also a set of format/transform helpers: autojson, format-yaml, expectedJsonChecker, and ddconvnotrunc. These are small conversion/validation utilities that sit between raw data and the structured formats used elsewhere in the repo.

Implementation technologies are intentionally mixed and lightweight. Python dominates most of the scripts, with shell wrappers for automation, C/C++ for performance- or device-facing utilities, and JavaScript/HTML/CSS for the D-Bus visualization frontend. Build systems are per-tool and independent: autotools, Meson, Makefiles, and simple executable scripts coexist without a shared monorepo build.

Operationally, the repo has very weak coupling by design. There is no shared application server, no central runtime, and no common data store. The architectural picture is a collection of command-line entry points and small UI tools that each ingest one kind of OpenBMC artifact, perform a narrow transformation, and write to stdout, files, or a browser UI.

For an architecture diagram, the most accurate abstraction is: “operator/dev tooling repository” at the center, with separate spokes to OpenBMC device interfaces, log/capture files, boot environments, and Gerrit/CLA workflow services. Each folder is an independent leaf rather than a module in a single system.