1.\" $OpenBSD: ipmi.4,v 1.15 2020/03/29 11:24:53 kettenis Exp $ 2.\" 3.\" Copyright (c) 2005 Marco Peereboom <marco@openbsd.org> 4.\" Text was heavily borrowed from the IPMI spec V1.5 5.\" 6.\" Permission to use, copy, modify, and distribute this software for any 7.\" purpose with or without fee is hereby granted, provided that the above 8.\" copyright notice and this permission notice appear in all copies. 9.\" 10.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES 11.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF 12.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR 13.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 14.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 15.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 16.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 17.Dd $Mdocdate: March 29 2020 $ 18.Dt IPMI 4 19.Os 20.Sh NAME 21.Nm ipmi 22.Nd Intelligent Platform Management Interface driver 23.Sh SYNOPSIS 24.Cd "ipmi0 at mainbus0" 25.Cd "ipmi0 at acpi?" 26.Cd "ipmi0 at iic?" 27.Cd "ipmi0 at fdt?" 28.Sh DESCRIPTION 29The 30.Nm 31term Intelligent Platform Management refers to autonomous monitoring and 32recovery features implemented directly in platform management hardware and 33firmware. 34The key characteristics of Intelligent Platform Management is that 35inventory, monitoring, logging, and recovery control functions are available 36independent of the main processor, BIOS, and operating system. 37.Pp 38Platform status information can be obtained and recovery actions initiated 39under situations where vendor "in-band" management mechanisms are unavailable. 40The independent monitoring, logging, and access functions available through IPMI 41provide a level of manageability built in to the platform hardware. 42This can support systems where there is no systems management software 43available for a particular operating system. 44.Pp 45At the heart of the IPMI architecture is a microcontroller called 46the Baseboard Management Controller (BMC). 47The BMC provides the intelligence behind Intelligent Platform Management. 48The BMC manages the interface between system management software 49and the platform management hardware, provides autonomous monitoring, 50event logging, and recovery control and serves as the gateway 51between systems management software and hardware. 52.Sh IPMI MESSAGING 53IPMI uses message-based interfaces for the different interfaces to the platform 54management subsystems. 55All IPMI messages share the same fields in the message "payload", 56regardless of the interface (transport) that they're transferred over. 57IPMI messaging uses a request/response protocol. 58IPMI request messages are commonly referred to as commands. 59The use of request/response protocol facilitates the transfer of 60IPMI messages over different transports. 61IPMI commands are grouped into functional command sets 62using a field called network function code. 63There are command sets for sensor and event related commands, 64chassis commands etc. 65This functional grouping makes it easier to organize and manage 66the assignment and allocation of command values. 67.Sh SENSOR MODEL 68Access to monitored information such as temperatures, voltages, fan status 69etc., is provided via the IPMI Sensor Model. 70Instead of providing direct access to the monitoring hardware, 71IPMI provides access by abstracted sensor commands 72such as the "Get Sensor Reading" command, 73implemented via a management controller. 74This approach isolates the software from changes in the 75platform management hardware implementation. 76.Pp 77Sensors are classified according to the type of readings they provide 78and/or the type of events they generate. 79A sensor can return either an analog or discrete reading. 80Sensor events can be discrete or threshold-based. 81.Sh SYSTEM EVENT LOG AND EVENT MESSAGES 82The BMC provides a centralized non-volatile System Event Log, or SEL. 83Having the SEL and logging functions managed by the BMC 84helps ensure that post-mortem logging information is available 85should a failure occur that disables the systems processor(s). 86.Pp 87A set of IPMI commands allows the SEL to be read and cleared 88and for events to be added to the SEL. 89The common request message (command) 90used for adding events to the SEL is referred to as an Event Message. 91.Sh SENSOR DATA RECORDS & CAPABILITIES COMMANDS 92IPMI's extensibility and scalability mean that 93each platform implementation can have 94a different population of management controllers and sensors and 95different event generation capabilities. 96The design of IPMI allows system 97management software to retrieve information from the platform 98and automatically configure itself to the platform's capabilities. 99.Pp 100Information that describes the platform management capabilities 101is provided via two mechanisms: 102Capabilities Commands and Sensor Data Records (SDRs). 103Capabilities commands are commands within the IPMI command sets that return 104fields that provide information on other commands and functions the controller 105can handle. 106.Sh SYSTEMS INTERFACES 107IPMI defines three standardized systems interfaces that systems software uses 108for transferring IPMI messages to the BMC. 109In order to support a variety of microcontrollers, 110IPMI offers a choice of systems interfaces. 111The system interfaces are similar enough so that 112a single driver can handle all IPMI system interfaces. 113.Bl -tag -width Ds 114.It Keyboard Controller Style (KCS) 115The bit definitions and operation of the registers follows that used in the 116Intel 8742 Universal Peripheral Interface microcontroller. 117The term "Keyboard Controller Style" reflects the fact that 118the 8742 interface was used as the legacy keyboard controller interface 119in PC architecture computer systems. 120This interface is available built in to several commercially available 121microcontrollers. 122Data is transferred across the KCS interface using a per-byte handshake. 123.It System Management Interface Chip (SMIC) 124The SMIC interface provides an alternative 125when the implementer wishes to use a microcontroller for the BMC 126that does not have the built-in hardware for a KCS interface. 127This interface is a three I/O port interface that can be 128implemented using a simple ASIC, FPGA, or discrete logic devices. 129It may also be built in to a custom-designed management controller. 130Like the KCS interface, 131a per-byte handshake is also used 132for transferring data across the SMIC interface. 133.It Block Transfer (BT) 134This interface provides a higher performance system interface option. 135Unlike the KCS and SMIC interfaces, 136a per-block handshake is used for transferring data across the interface. 137The BT interface also provides an alternative to using 138a controller with a built-in KCS interface. 139The BT interface has three I/O mapped ports. 140A typical implementation includes hardware buffers for holding 141upstream and downstream message blocks. 142The BT interface can be implemented using an ASIC or FPGA 143or may be built in to a custom-designed management controller. 144.It SMBus System Interface (SSIF) 145The SSIF interface provides access to the BMC over an SMBus interface. 146.El 147.Sh WATCHDOG 148IPMI provides 149.Xr watchdog 4 150timer functionality. 151Once configured, if the watchdog is not reset within 152a certain period of time, 153it will timeout and the server will reset. 154The reset will occur regardless of the recoverability of the hang or crash. 155.Pp 156Example of enabling a watchdog: 157.Pp 158.Dl # sysctl kern.watchdog.period=10 159.Pp 160In this case if the watchdog is not reset, 161it'll reboot the server after roughly 10 seconds. 162.Pp 163Example of disabling the watchdog: 164.Pp 165.Dl # sysctl kern.watchdog.period=0 166.Sh SEE ALSO 167.Xr watchdog 4 , 168.Xr sensorsd 8 , 169.Xr sysctl 8 170.Sh HISTORY 171The 172.Nm 173driver first appeared in 174.Ox 3.9 175and conforms to the IPMI 1.5 specification. 176.Sh AUTHORS 177The 178.Nm 179driver was written by 180.An Jordan Hargrave Aq Mt jordan@openbsd.org . 181