<div dir="ltr"><div dir="ltr">Thanks Mike, to follow up with your response,<br></div><div dir="ltr"><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>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.<br></div><div><br></div><div>[0]: <a href="https://github.com/PMBusOrg/format-language-evaluation/tree/master/dhall">https://github.com/PMBusOrg/format-language-evaluation/tree/master/dhall</a> <br></div><div><br> </div><div>-Vivek Gani (<a href="https://vivekgani.com/vivek_gani_resume.pdf">CV</a>)</div><div><a href="mailto:vivek@gani.org">vivek@gani.org</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 27, 2021 at 1:01 PM Mike Jones <<a href="mailto:proclivis@gmail.com">proclivis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Jason<br><div><br><blockquote type="cite"><div>On Apr 27, 2021, at 10:20 AM, Jason Ling <<a href="mailto:jasonling@google.com" target="_blank">jasonling@google.com</a>> wrote:</div><br><div><div dir="ltr">Thanks Mike for the feedback<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div>Ack, although the library was written for a use-case that involves obmc, it doesn't <i>require</i> obmc. Should work just fine in general Linux.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.</blockquote>This would be great, especially if this is codified in the pmbus spec. Right now the library provides a pmbus interface but <i>part programming</i> is specific to each device class...no guarantee of a common interface across multiple parts.<br></div></div></blockquote><div><br></div><div>The vendors will never agree to an industry specification for programming beyond the standard STORE_USER_ALL. Most real world programming is MFR.</div><div><br></div><div>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.</div><div><br></div><div>The problem with STORE_USER_ALL is if the power fails or the NVM fails.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr"><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1) I am interested in anything that enables our work</blockquote><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr"><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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</blockquote><div>Sounds good, feel free to reach out to me on an individual basis. </div></div></div></div></blockquote><div><br></div>Ok. Vivek is on the same list, and he can reach out for an official invite.</div><div><br></div><div>Mike<br><blockquote type="cite"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 7:33 PM Mike Jones <<a href="mailto:proclivis@gmail.com" target="_blank">proclivis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jason,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Imagine that programming might be done for:<br>
<br>
- ICT<br>
- Proto Builds<br>
- Engineering Bringup<br>
- Remote upgrades<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
My interest is two part:<br>
<br>
1) I am interested in anything that enables our work<br>
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<br>
<br>
Mike<br>
<br>
<br>
<br>
> On Apr 23, 2021, at 4:22 PM, Jason Ling <<a href="mailto:jasonling@google.com" target="_blank">jasonling@google.com</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> 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).<br>
> <br>
> 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).<br>
> <br>
> The idea is that more and more classes get added that will support different pmbus devices. <br>
> General idea is that each device that gets support can expose methods to allow device upgrade, black box retrieval, etc..<br>
> <br>
> Anyways, wanted to gauge community interest in this so I can determine how motivated I should be to upstream it.<br>
> <br>
<br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>