Lines Matching full:the
5 This design provides an efficient method to transfer MCTP packets between the
6 host and BMC over the LPC bus on ASPEED BMC platforms.
10 The following referenced documents are indispensable for the application of this
28 Defined by the MCTP base specification as the smallest maximum packet size all
33 A hardware-defined flag bit in a KCS device's Status Register (STR). The IBF
34 flag indicates that a value has been written by the host to the corresponding
39 One of the three register interfaces exposed by a KCS device. The IDR is a one
40 byte buffer which is written by the host and read by the BMC.
44 A set of bit definitions and operation of the registers typically used in
45 keyboard microcontrollers and embedded controllers. The term "Keyboard
46 Controller Style" reflects that the register definition was originally used as
47 the legacy "8742" keyboard controller interface in PC architecture computer
49 microcontrollers. Data is transferred across the KCS interface using a per-byte
60 application memory cycles with respect to the LPC bus. The ASPEED BMCs allow
61 remapping of the LPC firmware cycles onto arbitrary regions of the BMC's
66 The largest payload the link will accept for a packet. The Maximum Transmission
67 Unit represents a value that is at least as large as the BTU. Negotiation of MTU
68 values larger than the BTU may improve throughput for data-intensive transfers.
72 A hardware-defined flag bit in a KCS device's Status Register (STR). The OBF
73 flag indicates that a value has been written by the BMC to the corresponding
78 One of the three register interfaces exposed by a KCS device. The ODR is a one
79 byte buffer which is written by the BMC and read by the host.
83 One of the three register interfaces exposed by a KCS device. STR is a
84 BMC-controlled, eight-bit register exposed to both the BMC and the host for
85 indication of IBF and OBF events on the input (IDR) and output (ODR) buffers.
92 versions of the protocol unless marked otherwise.
98 The basic components used for the transfer are:
100 - An interrupt mechanism using the IPMI KCS interface
101 - A window of the LPC FW address space, where reads and writes are forwarded to
102 BMC memory, using the LPC2AHB hardware
104 In order to transfer a packet, either side of the channel (BMC or host) will:
106 1. Write the packet to the LPC FW window
107 - The BMC will perform writes by writing to the memory backing the LPC window
108 - The host will perform writes by writing to the LPC bus, at predefined
110 2. Trigger an interrupt on the remote side, by writing to the KCS data buffer
112 On this indication, the remote side will:
114 1. Read from the KCS status register, which shows that the single-byte KCS data
116 2. Read the provided command from the KCS data buffer, acknowledging the
118 3. Read the MCTP packet from the LPC FW window
122 The document limits itself to describing the operation of the binding protocol.
123 The following issues of protocol ABI are considered out of scope:
125 1. The LPC IO address and Serial IRQ parameters of the KCS device
126 2. The concrete location of the control region in the LPC FW address space
130 The KCS hardware on the ASPEED BMCs is used as a method of indicating, to the
131 remote side, that a packet is ready to be transferred through the LPC FW
134 The KCS hardware consists of two single-byte buffers: the Output Data Register
135 (ODR) and the Input Data Register (IDR). The ODR is written by the BMC and read
136 by the host. The IDR is the obverse.
138 The KCS unit also contains a status register (STR), allowing both host and BMC
139 to determine if there is data in the ODR or IDR. These are single-bit flags,
141 hardware when data has been written to the corresponding ODR/IDR buffer (and
144 While the IBF and OBF flags are managed in hardware, the remaining
145 software-defined bits in the status register are used to carry other required
146 protocol state. A problematic feature of the KCS status register is described in
147 the IPMI specification, which states that an interrupt may be triggered on
148 writes to the KCS status register but hardware implementations are not required
149 to do so. Comparatively, writes to the data registers must set the corresponding
152 To ensure interrupts are generated for status updates, we exploit the OBF
154 updating the status register, as outlined below.
158 The window of BMC-memory-backed LPC FW address space has a predefined format,
161 - A control descriptor, describing static data about the rest of the window
165 The control descriptor contains a version, and offset and size data for the
166 transmit and receive areas. These offsets are relative to the start of the LPC
169 Full definition of the control area is defined below, and it will be the base
190 The magic value marking the beginning of the control area is the ASCII encoding
206 In all versions of the protocol, the transmit and receive areas contain a
208 immediately by the MCTP packet data to be transferred. The full MCTP packet,
209 including MCTP header, is considered to be the payload for the purpose of the
218 A medium-specific packet trailer must immediately follow the payload. The length
219 of the trailer is not accounted for in the length field of the medium-specific
220 packet header: The length of the trailer is implied by the negotiated protocol
223 For protocol versions 1 and 2, the medium-specific trailer length is zero.
225 For protocol version 3, the medium-specific trailer comprises a CRC-32 checksum
226 of the payload.
234 Where the CRC-32 implementation is defined by the following characteristics (or
237 1. The polynomial
239 2. Initialising the remainder state to `2^32 - 1`
240 3. Incrementally shifting and `XOR`ing data bytes through the reversed
242 4. `XOR`ing the calculated remainder with `2^32 - 1`
244 For all defined versions, only a single MCTP packet is present in the Rx and Tx
245 areas. This may change for future versions of the protocol.
247 #### Negotiation of the Maximum Transmission Unit
249 Version 1 of the protocol offers no mechanism for negotiation of the maximum
250 transmission unit. The Rx and Tx buffers must be sized to accommodate packets up
251 to the Baseline Transmission Unit, and the implementation assumes that the MTU
252 is set to the BTU regardless of the values of `rx_size` and `tx_size`.
254 Version 2 of the protocol exploits the `rx_size` and `tx_size` fields in the
255 control region to negotiate the link MTU. Note that at the time that the MTU is
256 under negotiation the protocol version has not been finalised, so the process is
259 The relevant property that each endpoint must control is the MTU of packets it
260 will receive, as this governs how the remote endpoint's packetisation impacts
261 memory pressure at the local endpoint. As such while the BMC MUST populate
262 `rx_size` for backwards compatibility with version 1, the host MAY write
263 `rx_size` without regard for its current value if the host supports version 2.
264 The BMC controls the value of `tx_size`, and MAY choose to adjust it in response
265 to the host's proposed `rx_size` value. As such, when `Channel Active` is set by
266 the BMC, the host MUST read both `rx_size` and `tx_size` in response to ensure
267 both the BMC and the host have a consistent understanding of the MTU in each
268 direction. It is convention for `rx_size` and `tx_size` to be set to the same
269 value by the BMC as part of finalising the channel, though it is not invalid to
272 For all protocol versions, the following properties must be upheld for the Rx
275 - Intersect neither eachother nor the control region
276 - Not extend beyond the window allocated to MCTP in the LPC FW address space
279 The BMC MAY choose to fail channel initialisation if these properties are
280 violated in the negotiation process.
284 The KCS status flags and command set govern the state of the protocol, defining
285 the ability to send and receive packets on the LPC bus.
311 The host sends commands to the BMC to signal channel initialisation, begin
316 | 1 | The host writes a command value to IDR |
317 | 2 | The hardware sets IBF, which triggers a BMC interrupt |
318 | 3 | The BMC reads the status register for IBF |
319 | 4 | If IBF is set, the BMC reads the host command from IDR |
320 | 5 | The interrupt is acknowledged by the data register read |
324 The BMC sends commands to the host to begin transmission of a packet or to
329 | 1 | The BMC writes a command value to ODR |
330 | 2 | The hardware sets OBF, which triggers a host interrupt |
331 | 3 | The host reads the status register for OBF |
332 | 4 | If OBF is set, the host reads the BMC command from ODR |
333 | 5 | The interrupt is acknowledged by the data register read |
337 The BMC sends status updates to the host to signal loss of function, loss of
338 channel state, or the presence of a command in the KCS data register.
342 | 1 | The BMC writes the status value to the status register |
343 | 2 | The BMC writes the dummy command to ODR |
344 | 3 | The hardware sets OBF, which triggers a host interrupt |
345 | 4 | If OBF is set, the host reads the BMC command from ODR |
346 | 5 | The interrupt is acknowledged by the data register read |
347 | 6 | The host observes the command is the dummy command |
348 | 7 | The host reads the status register to capture the state change |
352 Because the LPC FW window is shared between the host and the BMC we need strict
357 - The control data is only written during initialisation. The control area is
358 never modified once the channel is active.
359 - Only the BMC may write to the Rx buffer described in the control area
360 - Only the host may write to the Tx buffer described in the control area
362 During packet transmission, the follow sequence occurs:
364 1. The Tx side writes the packet to its Tx buffer
365 2. The Tx side sends a `Tx Begin` message, indicating that the buffer ownership
367 3. The Rx side now owns the buffer, and reads the message from its Rx area
368 4. The Rx side sends a `Rx Complete` once done, indicating that the buffer
369 ownership is transferred back to the Tx side.
373 The binding operation is not symmetric as the BMC is the only side that can
374 drive the status register. Each side's initialisation sequence is outlined
377 The sequences below contain steps where the BMC updates the channel status and
378 where commands are sent between the BMC and the host. The act of updating status
379 or sending a command invokes the behaviour outlined in
382 The packet transmission sequences assume that `BMC Active` and `Channel Active`
389 | 1 | The BMC initialises the control area: magic value, BMC versions and buffer parameters |
390 | 2 | The BMC sets the status to `BMC Active` |
396 | 1 | ✓ | ✓ | ✓ | The host waits for the `BMC Active` state …
397 | 2 | ✓ | ✓ | ✓ | The host populates the its version fields …
398 | 3 | | ✓ | ✓ | The host derives and writes to `rx_size` the packet size associated with…
399 | 4 | ✓ | ✓ | ✓ | The host sends the `Initialise` command …
400 | 5 | ✓ | ✓ | ✓ | The BMC observes the `Initialise` command …
401 | 6 | ✓ | ✓ | ✓ | The BMC calculates and writes `negotiated_ver` …
402 | 7 | | ✓ | ✓ | The BMC calculates the MTUs and updates neither, one or both of `rx_size…
403 | 8 | ✓ | ✓ | ✓ | The BMC sets the status to `Channel Active` …
404 | 9 | ✓ | ✓ | ✓ | The host observes that `Channel Active` is set …
405 | 10 | ✓ | ✓ | ✓ | The host reads the negotiated version …
406 | 11 | | ✓ | ✓ | The host reads both `rx_size` and `tx_size` to derive the negotiated MTU…
412 | 1 | | | ✓ | The host calculates the CRC-32 over the packet data …
413 | 2 | ✓ | ✓ | ✓ | The host waits on any previous `Rx Complete` message …
414 | 3 | ✓ | ✓ | ✓ | The host writes the packet data and medium-specific metadata to its Tx a…
415 | 4 | ✓ | ✓ | ✓ | The host sends the `Tx Begin` command, transferring ownership of its Tx …
416 | 5 | ✓ | ✓ | ✓ | The BMC observes the `Tx Begin` command …
417 | 6 | ✓ | ✓ | ✓ | The BMC reads the packet data and medium-specific metadata from the its …
418 | 7 | ✓ | ✓ | ✓ | The BMC sends the `Rx Complete` command, transferring ownership of its R…
419 | 8 | ✓ | ✓ | ✓ | The host observes the `Rx Complete` command …
420 | 9 | | | ✓ | The BMC validates the provided CRC-32 over the packet data …
426 | 1 | | | ✓ | The BMC calculates the CRC-32 over the packet data …
427 | 2 | ✓ | ✓ | ✓ | The BMC waits on any previous `Rx Complete` message …
428 | 3 | ✓ | ✓ | ✓ | The BMC writes the packet data and medium-specific metadata to its Tx ar…
429 | 4 | ✓ | ✓ | ✓ | The BMC sends the `Tx Begin` command, transferring ownership of its Tx b…
430 | 5 | ✓ | ✓ | ✓ | The host observes the `Tx Begin` command …
431 | 6 | ✓ | ✓ | ✓ | The host reads the packet data and medium-specific metadata from the hos…
432 | 7 | ✓ | ✓ | ✓ | The host sends the `Rx Complete` command, transferring ownership of its …
433 | 8 | ✓ | ✓ | ✓ | The BMC observes the `Rx Complete` command …
434 | 9 | | | ✓ | The host validates the provided CRC-32 over the packet data …
438 On the BMC the initial prototype implementation makes use of the following
442 - The reserved memory mapped by the LPC2AHB bridge via the [aspeed-lpc-ctrl
444 - The astlpc binding found in [libmctp][libmctp]
452 From the host side, the LPC Firmware and KCS IO cycles are driven by
454 implementing the driver hooks for direct access to the LPC devices.
458 ### The KCS MCTP Binding (DSP0254)
460 The KCS hardware (used as the full transfer channel) can be used to transfer
464 ### The MCTP Serial Binding (DSP0253)
466 We could use the VUART hardware to transfer the MCTP packets according to the
467 existing MCTP Serial Binding. However, the VUART device is already used for
469 the complexity introduced would make low-level debugging both more difficult and
472 ### The BT interface
474 The BT interface allows for block-at-time transfers. However, the BT buffer size
475 is only 64 bytes on the AST2500 hardware, which does not allow us to comply with
476 the MCTP Base Specification (DSP0236) that requires a 64-byte payload size as
477 the minimum. The 64-byte BT buffer does not allow for MCTP and transport
480 Additionally, we would like to develop the MCTP channel alongside the existing
481 IPMI interfaces, to allow a gradual transition from IPMI to MCTP. As the BT
485 ### Using the AST2500 LPC Mailbox
487 This would require enabling the SuperIO interface, which allows the host to
488 access the entire BMC address space, and so introduces security vulnerabilities.