[pmbusplus] userspace i2c, pmbus interactions

[Mike Jones]

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 <mailto: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 <mailto: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/909a6f10/attachment-0001.htm>