[pmbusplus] userspace i2c, pmbus interactions

[Vivek Gani]

Thanks Mike, to follow up with your response,

I agree that most real-world configuration ends up being mfr-specific. Over
time specs like PMBus Application Profiles may help on some aspects but
from personal experience there's variation between vendors on aspects like
detection of PMBus devices, or occasionally complexity around command
timing & order. This has led us to think around a need of defining a
standardized file format with the possibility of conventions around how
procedures are named (e.g. configure, identify, on/off, etc.) and naming
side-effects (e.g. requires power-cycle or boot stage) to make things
easier for a systems engineer to orchestrate.

We've been facilitating calls around what we'd want in a format and making
some initial rough prototypes for discussion. Most recently we looked at a
format [0] that could decouple IC vendor and system engineer aspects,
facilitate real-world scenarios of needing human-editability, and export to
JSON for use obmc runtime configuration.

This week we're trying to pick up where we left off a month ago so this is
a great time to bring up any opinions/ideas. I want to extend the
invitation out to anyone interested, send me an email and I can arrange to
get you on our mailing list or would if like me to reach-out after our next
meeting to share some highlights of what's happening.

[0]:
https://github.com/PMBusOrg/format-language-evaluation/tree/master/dhall

-Vivek Gani (CV <https://vivekgani.com/vivek_gani_resume.pdf>)
vivek at gani.org

On Tue, Apr 27, 2021 at 1:01 PM Mike Jones <proclivis at gmail.com> wrote:

> Jason
>
> On Apr 27, 2021, at 10:20 AM, Jason Ling <jasonling at google.com> wrote:
>
> Thanks Mike for the feedback
>
> And the context is more than CPU based systems, but includes Networking,
>> other boards with ASICS, etc. So broad context. Hence, it has to work
>> within linux without OBMC.
>
> Ack, although the library was written for a use-case that involves obmc,
> it doesn't *require* obmc. Should work just fine in general Linux.
>
>  Now, imagine the IC manufacturer's tool produces a file that can
>> represent a qualified algorithm that is known to work under all possible
>> scenarios, including CRC errors in parts, corrupt NVM, etc. This is what
>> all the vendors do today. They take care of all the things that can go
>> wrong. In the case of ADI, if power was lost while programming, and the BMC
>> or linux can boot from an aux supply, our data files (encoding algorithms),
>> can repair the part under ALL possible random values in the corrupt part.
>
> This would be great, especially if this is codified in the pmbus spec.
> Right now the library provides a pmbus interface but *part programming* is
> specific to each device class...no guarantee of a common interface across
> multiple parts.
>
>
> The vendors will never agree to an industry specification for programming
> beyond the standard STORE_USER_ALL. Most real world programming is MFR.
>
> This is the reason for a description file, it enables each vendor to
> innovate, yet the end user can process the file with a single engine.
>
> The problem with STORE_USER_ALL is if the power fails or the NVM fails.
>
> For example, some companies just change a few commands, say voltage, and
> then store. But if power is lost during the store, the other 99 values are
> corrupted and need repair, and the part may not even have an address on the
> bus without special commands to reset a few things. Or it might be write
> protected. Or PEC might be required, Etc.
>
>
> 1) I am interested in anything that enables our work
>
> Sure, I'll start carving out more time to make this work suitable for
> upstreaming. At the very least it should give you a mockable interface to
> allow for strong unit testing of upper layers.
>
>
> ADI has code that can implement its proprietary programming via /dev/i2c.
> All that is needed is standard SMBus code. If the programming happens in
> user space, we imagined the data processing engine using that.
>
> In that context, it would be interesting to know what you are doing, as
> you are adding value for sure. If there is an API that delineates the
> function implemented, it would be nice to review it so I can understand
> your work.
>
>
>
>> 2) I am interested in inviting someone from the community, not IC vendor,
>> to our meetings to offer advice and help us define something useful
>
> Sounds good, feel free to reach out to me on an individual basis.
>
>
> Ok. Vivek is on the same list, and he can reach out for an official invite.
>
> Mike
>
>
> On Mon, Apr 26, 2021 at 7:33 PM Mike Jones <proclivis at gmail.com> wrote:
>
>> Jason,
>>
>> I am interested, because within the PMBus Specification Committee, we are
>> working on a data language intended for device programming. And there is
>> hope that eventually it can become adopted into linux and/or OBMC.
>>
>> There is a particular use model that is being driven by the IC suppliers
>> and their tools. One reason is that all the vendors have proprietary tools,
>> but they see no competitive advantage, and would rather support a universal
>> standard.
>>
>> Imagine that programming might be done for:
>>
>> - ICT
>> - Proto Builds
>> - Engineering Bringup
>> - Remote upgrades
>>
>> And the context is more than CPU based systems, but includes Networking,
>> other boards with ASICS, etc. So broad context. Hence, it has to work
>> within linux without OBMC.
>>
>> My view is it is a linux library anyone can use, and OBMC is the piping
>> if it were exposed to a web service, state management, etc.
>>
>> Now, imagine the IC manufacturer's tool produces a file that can
>> represent a qualified algorithm that is known to work under all possible
>> scenarios, including CRC errors in parts, corrupt NVM, etc. This is what
>> all the vendors do today. They take care of all the things that can go
>> wrong. In the case of ADI, if power was lost while programming, and the BMC
>> or linux can boot from an aux supply, our data files (encoding algorithms),
>> can repair the part under ALL possible random values in the corrupt part.
>>
>> Furthermore, an integrator (CM, Design House, software team) has to deal
>> with segmented I2C busses, muxes, etc. And the integrator wants to write a
>> wrapper file that integrates all the vendor files. So this integration file
>> has to take care of muxes, order of operations, calling vendor files, etc.
>>
>> My interest is two part:
>>
>> 1) I am interested in anything that enables our work
>> 2) I am interested in inviting someone from the community, not IC vendor,
>> to our meetings to offer advice and help us define something useful
>>
>> Mike
>>
>>
>>
>> > On Apr 23, 2021, at 4:22 PM, Jason Ling <jasonling at google.com> wrote:
>> >
>> > Hi all,
>> >
>> > What started as an attempt to create a simple command line tool to
>> perform pmbus device upgrades over i2c has turned into the start of a
>> user-space i2c library (with some pmbus support).
>> >
>> > I've already reused this library in some other obmc applications and
>> it's been fairly well unit-tested. It also comes with all the public
>> interfaces mocked (so you can unit test your own code).
>> >
>> > The idea is that more and more classes get added that will support
>> different pmbus devices.
>> > General idea is that each device that gets support can expose methods
>> to allow device upgrade, black box retrieval, etc..
>> >
>> > Anyways, wanted to gauge community interest in this so I can determine
>> how motivated I should be to upstream it.
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20210427/50a6faf1/attachment.htm>