Lines Matching full:bmc
17 This document describes a protocol for host to BMC communication via the
34 the host and the BMC via the Aspeed mailbox registers. This protocol is used
37 Prior to the mbox protocol, the host uses a backdoor into the BMC address space
44 update it on each BMC generation, have all the quirks for all the flash
46 the one in the BMC itself.
49 host and the BMC.
51 3. It's very hard to support "BMC reboots" when doing that
56 risk. It means the host can access any address on the BMC internal bus and
57 implant malware in the BMC itself. So if the host is a "bare metal" shared
59 reflashed when switching from one customer to another, but the entire BMC
64 When using this mechanism, the BMC is solely responsible for directly accessing
66 BMC and the BMC only. (We can allow direct reads from flash under some
69 The host uses the mailbox registers to send "commands" to the BMC, which
74 When set for writing, the BMC makes the window point to a chunk of RAM instead.
75 When the host "commits" a change (via MBOX), then the BMC can perform the
90 * A write window has to be a chunk of BMC memory. The minimum size is not
92 should support larger block sizes in the future). When the BMC receive the
93 command to map the write window at a given offset of the flash, the BMC should
97 The host can then write to that window directly (updating the BMC memory) and
125 of control registers, one accessible by the host the other by the BMC.
126 Interrupts can also be raised per write to each data register, for BMC and
140 Byte 15: BMC controlled status reg
143 Note: when the BMC is writing a response to the mbox registers (as described
152 What we essentially have is a set of registers which either the host or BMC can
156 1. Commands sent from the Host to the BMC
157 2. Responses sent from the BMC to the Host in response to commands
158 3. Asynchronous events raised by the BMC
162 Messages usually originate from the host to the BMC. There are special
163 cases for a back channel for the BMC to pass new information to the
170 generate an interrupt to the BMC by using bit 0 of its control register and
176 Register) the BMC should read the message from the general registers
178 responding the BMC must ensure that the sequence number is the same as
179 the one in the request from the host. The BMC must also ensure that
181 BMC should then use its control register to generate an interrupt for
184 ### Asynchronous BMC to Host Events
186 BMC to host communication is also possible for notification of events
187 from the BMC. This requires that the host have interrupts enabled on
191 BMC (see BMC Event notifications in Commands for detail). Events which are
197 When a host wants to communicate with the BMC via the mbox protocol the first
213 transaction, the BMC may raise asynchronous events with the host to
219 multiple of block size it is necessary for the host and BMC to agree on a
221 4K, in V2 the BMC chooses and in V3 the host is allowed to request a specific
227 When invoking `MBOX_GET_INFO` the host must provide the BMC its highest
228 supported version of the protocol. The BMC must respond with a protocol version
231 must not continue to communicate with the BMC. Otherwise, the protocol version
232 returned by the BMC is the agreed protocol version for all further
241 or otherwise set this argument to zero. The BMC must respond with the LPC bus
244 window commands the BMC must guarantee that the window provided contains data
251 from a write window and the BMC must guarantee that the window reflects what
256 If the host closes an active write window then the BMC must perform an
269 The BMC has no method for intercepting writes that occur over the LPC bus. Thus
270 the host must explicitly notify the BMC of where and when a write has
271 occurred. The host must use the MARK_WRITE_DIRTY command to tell the BMC where
274 need to write 0xFF. The BMC must ensure that if the host
278 implicitly or explicitly by the host or the BMC. The BMC may at any time
288 BMC must ensure that a write performs as expected - that is if an erase is
289 required before a write then the BMC must perform this itself (unless the
290 no_erase flag is set in the MARK_WRITE_DIRTY command in which case the BMC will
300 Locked flash regions must persist across a BMC reboot or daemon restart. It is
303 ### BMC Events
305 The BMC can raise events with the host asynchronously to communicate to the
307 possible for the given event) acknowledge it to inform the BMC it has been
310 If the BMC raises a BMC Reboot event then the host must renegotiate the
311 protocol version so that both the BMC and the host agree on the block size.
312 A BMC Reboot event implies a BMC Windows Reset event.
313 If the BMC raises a BMC Windows Reset event then the host must
315 active window it has been closed by the BMC and if it was a write window
319 The BMC may at some points require access to the flash and the BMC daemon must
320 set the BMC Flash Control Lost event when the BMC is accessing the flash behind
321 the BMC daemons back. When this event is set the host must assume that the
366 valid. The BMC's response to a command must contain the same sequence number
370 above. However, it is not an error if the BMC receives a `GET_MBOX_INFO` with an
371 invalid sequence number. For all other cases, the BMC must respond with
384 SYSTEM_ERROR - Error in BMC performing system action
437 This command is designed to inform the BMC that it should put
439 use it. Currently, this means pointing back to BMC flash
478 it should wait after issuing a command to the BMC before it
480 which the BMC thinks it could take to service any command which
482 the BMC does not wish to provide a hint in which case the host
542 indicates the actual size of the window. The BMC may
553 BMC is free to create any sized window but it must contain
577 write window then the BMC must perform an implicit flush.
580 hints to the BMC. Defined Values:
584 this will depend on BMC implementation. In
585 the event that the BMC performs some caching
586 the BMC daemon could mark data contained in a
606 The BMC has no method for intercepting writes that
652 Args 0: Bits in the BMC status byte (mailbox data
657 The host should use this command to acknowledge BMC events
713 ### BMC Events in Detail:
715 If the BMC needs to tell the host something then it simply
723 0x01: BMC Reboot
724 0x02: BMC Windows Reset (V2)
727 Events which cannot be ACKed (BMC will clear when no longer
730 0x40: BMC Flash Control Lost (V2)
731 0x80: BMC MBOX Daemon Ready (V2)
738 let the BMC know that they have been received and understood.
740 0x01 - BMC Reboot:
741 Used to inform the host that a BMC reboot has occurred.
745 0x02 - BMC Windows Reset: (V2)
755 BMC_EVENT_ACK with these bits set will have no effect. The BMC
758 0x40 - BMC Flash Control Lost: (V2)
759 The BMC daemon has been suspended and thus no longer
761 other process on the BMC required direct access to the
762 flash and has suspended the BMC daemon to preclude
764 The BMC daemon must clear this bit itself when it regains
769 0x80 - BMC MBOX Daemon Ready: (V2)
770 Used to inform the host that the BMC daemon is ready to
772 this bit through an acknowledge command, the BMC daemon must
777 Note that this bit being set is not a guarantee that the BMC daemon
778 will respond as it or the BMC may have crashed without clearing