All of lore.kernel.org
 help / color / mirror / Atom feed
* BIOS/UEFI host firmware interfaces into OpenBMC (x86)
@ 2021-03-05  3:38 Garrett, Mike (HPE Server Firmware)
  2021-03-07  1:31 ` Jeremy Kerr
  0 siblings, 1 reply; 3+ messages in thread
From: Garrett, Mike (HPE Server Firmware) @ 2021-03-05  3:38 UTC (permalink / raw)
  To: openbmc

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Hello all,



I'm interested in BIOS/UEFI host firmware interfaces into OpenBMC (x86) for POST-time data transfer.  I've been searching the email list archives and Discord for any discussion of this and haven't found much.



In the vendor-proprietary firmware world, the BMC firmware is often coupled closely with the vendor's host UEFI firmware using a non-standard but high-performance interface instead of the slow and primitive IPMI over KCS.  OpenBMC doesn't have natural BIOS partner, and as best I can tell, this means that POST time data transfer is least-common denominator KCS.  We could add the vendor specific support we need into our OpenBMC port to handle our UEFI firmware's POST-time data transfers, but would prefer to first understand if there's an emerging consensus on what replaces IPMI over KCS for x86.  This will become even more important when open source host firmware (CoreBoot or Min Platform or other) is running and all of the vendor specific ways of doing this disappear.  I'm interested in something standard (even de-facto) to transfer the big data items like SMBIOS and Remote BIOS Configuration data.



From what I can tell from reading, the Open Power folks are going with PLDM over MCTP over some interface (KCS or BT?) to enable host firmware to BMC comms.  I am just curious if there is a consensus on a successor to IPMI/KCS for x86.  If there is a lode of rich info on this topic, can someone point me to it?  I'm interested in the community's thoughts.



Thanks,



Mike


[-- Attachment #2: Type: text/html, Size: 3877 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BIOS/UEFI host firmware interfaces into OpenBMC (x86)
  2021-03-05  3:38 BIOS/UEFI host firmware interfaces into OpenBMC (x86) Garrett, Mike (HPE Server Firmware)
@ 2021-03-07  1:31 ` Jeremy Kerr
  2021-03-07  3:26   ` Andrew Jeffery
  0 siblings, 1 reply; 3+ messages in thread
From: Jeremy Kerr @ 2021-03-07  1:31 UTC (permalink / raw)
  To: Garrett, Mike (HPE Server Firmware), openbmc

Hi Mike,

> We could add the vendor specific support we need into our OpenBMC
> port to handle our UEFI firmware’s POST-time data transfers, but
> would prefer to first understand if there’s an emerging consensus
> on what replaces IPMI over KCS for x86.

We've implemented a PLDM-over-MCTP stack for host-firmware-to-BMC
communication:

 https://github.com/openbmc/docs/blob/master/designs/mctp/mctp.md

for the PLDM specifics:

 https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md


> From what I can tell from reading, the Open Power folks are going
> with PLDM over MCTP over some interface (KCS or BT?) to enable host
> firmware to BMC comms.

This isn't really OpenPOWER-specific; you should be able to do the same
on x86, where just the hardware channel can be platform-specific.

In the implementations I've been working on, the hardware binding is a
hybrid of the KCS channel (for synchronisation) plus the AST2x00
hardware-based LPC memory-map (for the data transfers):

  https://github.com/openbmc/libmctp/blob/master/astlpc.c

- where that same code can be used on both the host-firmware and BMC
sides, and should be fine for x86.

We have a serial MCTP binding implemented too, and there's also some
development happening on an i2c binding, if either of those are a
better fit.

Cheers,


Jeremy


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: BIOS/UEFI host firmware interfaces into OpenBMC (x86)
  2021-03-07  1:31 ` Jeremy Kerr
@ 2021-03-07  3:26   ` Andrew Jeffery
  0 siblings, 0 replies; 3+ messages in thread
From: Andrew Jeffery @ 2021-03-07  3:26 UTC (permalink / raw)
  To: Jeremy Kerr, Garrett, Mike (HPE Server Firmware), openbmc



On Sun, 7 Mar 2021, at 12:01, Jeremy Kerr wrote:
> Hi Mike,
> 
> > We could add the vendor specific support we need into our OpenBMC
> > port to handle our UEFI firmware’s POST-time data transfers, but
> > would prefer to first understand if there’s an emerging consensus
> > on what replaces IPMI over KCS for x86.
> 
> We've implemented a PLDM-over-MCTP stack for host-firmware-to-BMC
> communication:
> 
>  https://github.com/openbmc/docs/blob/master/designs/mctp/mctp.md
> 
> for the PLDM specifics:
> 
>  https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md
> 
> 
> > From what I can tell from reading, the Open Power folks are going
> > with PLDM over MCTP over some interface (KCS or BT?) to enable host
> > firmware to BMC comms.
> 
> This isn't really OpenPOWER-specific; you should be able to do the same
> on x86, where just the hardware channel can be platform-specific.
> 
> In the implementations I've been working on, the hardware binding is a
> hybrid of the KCS channel (for synchronisation) plus the AST2x00
> hardware-based LPC memory-map (for the data transfers):
> 
>   https://github.com/openbmc/libmctp/blob/master/astlpc.c
> 
> - where that same code can be used on both the host-firmware and BMC
> sides, and should be fine for x86.

In addition the binding is documented here (which might be an easier read):

https://github.com/openbmc/libmctp/blob/192752301b9d98b8699e88ede61d75e96eaed4bb/docs/bindings/vendor-astlpc.md

Andrew

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-03-07  3:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-05  3:38 BIOS/UEFI host firmware interfaces into OpenBMC (x86) Garrett, Mike (HPE Server Firmware)
2021-03-07  1:31 ` Jeremy Kerr
2021-03-07  3:26   ` Andrew Jeffery

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.