docs: Cleanup of Design Doc
The google-drive -> markdown added those reference points and they are
not needed and show up. This removes them.
Change-Id: If7ab88a08b048e78b4cd8a2159e7e56180bd55a3
Signed-off-by: Patrick Venture <venture@google.com>
diff --git a/README.md b/README.md
index e31fad8..6c34c9e 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
[TOC]
-## Objective {#objective}
+## Objective
Develop a tray level fan control system that will use exhaust temperature and
other machine temperature information to control fan speeds in order to keep
@@ -11,7 +11,7 @@
Effectively porting the Chromium EC thermal code to run on the BMC and use the
OpenBMC dbus namespace and IPMI commands.
-## Background {#background}
+## Background
Recent server systems come with a general secondary processing system attached
for the purpose of monitoring and control, generally referred to as a BMC[^2].
@@ -33,7 +33,7 @@
control with a BMC. OEM commands are already lined up for certain other accesses
routed through the BMC, and can be upstreamed for others to use.
-## Overview {#overview}
+## Overview
The BMC will run a daemon that controls the fans by pre-defined zones. The
application will use thermal control, such that each defined zone is kept
@@ -50,7 +50,7 @@
The system will run a control loop for each zone with the attempt to maintain
the temperature within that zone within the margin for the devices specified.
-## Detailed Design {#detailed-design}
+## Detailed Design
The software will run as a multi-threaded daemon that runs a control loop for
each zone, and has a master thread which listens for dbus messages. Each zone
@@ -62,7 +62,7 @@
In this figure the communications channels between swampd and ipmid and
phosphor-hwmon are laid out.
-### OpenBMC Upstream {#openbmc-upstream}
+### OpenBMC Upstream
To be upstreamed to OpenBMC for use on open-power systems, we need to follow the
OpenBMC code style specification[^9] and leverage the dbus framework for reading
@@ -79,7 +79,7 @@
we're using for Quanta-Q71l (the first system) only allows writing PWM. This
can be controlled either directly or via dbus.
-### Zone Specification {#zone-specification}
+### Zone Specification
A configuration file will need to exist for each board, likely in YAML[^12].
Similar information will also be necessary for gsys, such that it knows what
@@ -96,7 +96,7 @@
The internal thermometers specified will be read via sysfs.
-#### A proposed configuration file: {#a-proposed-configuration-file}
+#### A proposed configuration file:
```
{ZONEID}:
@@ -140,12 +140,12 @@
slew_positive: 0
```
-### Chassis Delta {#chassis-delta}
+### Chassis Delta
Due to data center requirements, the delta between the outgoing air temperature
and the environmental air temperature must be no greater than 15C.
-### IPMI Command Specification {#ipmi-command-specification}
+### IPMI Command Specification
Gsys needs the ability to send to the BMC, the margin information on the devices
that it knows how to read that the BMC cannot. There is no command in IPMI that
@@ -154,7 +154,7 @@
The state of the BMC readable temperature sensors can be read through normal
IPMI commands and is already supported.
-#### OEM Set Control {#oem-set-control}
+#### OEM Set Control
Gsys needs to be able to set the control of the thermal system to either
automatic or manual. When manual, the daemon will effectively wait to be told to
@@ -185,7 +185,7 @@
`04` | `padding` | `0x00`
`07` | `Mode` | `If Set, Value 1 == Manual Mode, 0 == Automatic Mode`
-#### OEM Get Failsafe Mode {#oem-get-failsafe-mode}
+#### OEM Get Failsafe Mode
Gbmctool needs to be able to read back whether a zone is in failsafe mode. This
setting is read-only because it's dynamically determined within Swampd per zone.
@@ -209,7 +209,7 @@
`04` | `padding` | `0x00`
`07` | `failsafe` | `1 == in Failsafe Mode, 0 not in failsafe mode`
-#### Set Sensor Value {#set-sensor-value}
+#### Set Sensor Value
Gsys needs to update the thermal controller with information not necessarily
available to the BMC. This will comprise of a list of temperature (or margin?)
@@ -217,17 +217,17 @@
real sensors in the system, the set sensor handler can simply broadcast the
update as a properties update on dbus when it receives the command over IPMI.
-#### Set Fan PWM {#set-fan-pwm}
+#### Set Fan PWM
Gsys can override a specific fan's PWM when we implement the set sensor IPMI
command pathway.
-#### Get Fan Tach {#get-fan-tach}
+#### Get Fan Tach
Gsys can read fan_tach through the normal IPMI interface presently exported for
sensors.
-### Sensor Update Loop {#sensor-update-loop}
+### Sensor Update Loop
The plan is to listen for fan_tach updates for each fan in a background thread.
This will receive an update from phosphor-hwmon each time it updates any sensor
@@ -238,7 +238,7 @@
short though is still TBD. We'll also be updating phosphor-hwmon to support pwm
as a target.
-### Thermal Control Loops {#thermal-control-loops}
+### Thermal Control Loops
Each zone will require a control loop that monitors the associated thermals and
controls the fan(s). The EC PID loop is designed to hit the fans 10 times per
@@ -249,7 +249,7 @@
fans. TBD on how frequently we'll be reading the fan sensors and the impact this
will have.
-### Main Thread {#main-thread}
+### Main Thread
The main thread will manage the other threads, and process the initial
configuration files. It will also register a dbus handler for the OEM message.
@@ -265,7 +265,7 @@
To the recipe.
-## Project Information {#project-information}
+## Project Information
This project is designed to be a daemon running within the OpenBMC environment.
It will use a well-defined configuration file to control the temperature of the
@@ -273,18 +273,18 @@
coordinate with gsys and OpenBMC. Providing a host-side service upstream to talk
to the BMC is beyond the scope of this project.
-## Security Considerations {#security-considerations}
+## Security Considerations
A rogue client on the host could send invalid thermal information causing
physical damage to the system. There will be an effort to sanity check all input
from gsys to alleviate this concern.
-## Privacy Considerations {#privacy-considerations}
+## Privacy Considerations
This device holds no user data, however, you could profile the types of jobs
executed on the server by watching its temperatures.
-## Testing Plan {#testing-plan}
+## Testing Plan
Testing individual code logic will be handled through unit-tests, however some
pieces of code rely on abstractions such that we can swap out dbus with