Hi Greg, > FWIW, we did raise greybus as an approach to various HW vendors; I > assume there were reasons behind OBMF-ICP, and assume some prior-art > assesment was involved, but I don't have specifics for those reasons. > > HW peeps: This would be an excellent opportunity for elaboration on the > motivation there, either for LSTP or OBMF-OCP.
I have been doing some asking around, and a few items came up around motivations for OBMC-ICP over Greybus. My motivation here is entirely around OBMF-ICP; the NVIDIA contributions for LSTP somewhat comes under this, and so we're working on composing a unified solution. Collating some of those items here: As a bit of background, the typical use case for OBMF-ICP is for platform pre-boot environments, with limitations in capabilities of both the hardware and software stack. Microcontroller and mask-ROM implementations of either side of the protocol are potential targets. This leads to the structure of OBMF-ICP being intentionally light-weight; the channel configuration (ie, definition of the encapsulated devices) is static, and the channel-level messaging is kept simple, mainly through a requirement of only one message in flight per channel. [Greg, this is related to one of your points around why not use a multi-function USB device for individual, separate devices: the typical device-side hardware does not have support for enough USB endpoints to do so. Like greybus, the intention is to be able to support multiple downstream peripherals without constraints from USB hardware on existing SoC devices] There are a few design points that lead to the preference for OBMF-ICP: The front-loaded configuration mechanism means less state to manage on both sides of the protocol; the channel set and channel-specific parameters (like individual GPIO descriptors and flash geometry) being stable over the lifetime of the device means simpler core protocol support and channel driver implementations. The simpler channel communication protocol is better suited to lower-complexity interfaces that are needed for the pre-boot environments (GPIO control, uart, IPMI, flash access) than the greybus targets for mobile device runtime, with higher-bandwidth communication requirements (camera, audio, display). For example, typical platform management functions generally involve a lot of short i2c operations - ICP messages for these are around half the length of greybus equivalents. For the platform-boot use-cases, we would need to provide a bunch of new channel definitions for greybus. This certainly isn't a showstopper in itself, but the specification does not appear to be in active development; last change was 10 years ago, and the spec repository has since been archived as far as I can tell (and so is read-only). With OBMF-ICP's super-minimal core protocol, and the use-case appropriate channels, seems like a suitable approach to me. The USB-IF has a class ID allocated for OBMF-ICP interface descriptors, with the intention that we have multiple vendor implementations of the common protocol; we would like Linux to be one of those. Cheers, Jeremy _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
