
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Jason<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 27, 2021, at 10:20 AM, Jason Ling <<a href="mailto:jasonling@google.com" class="">jasonling@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Thanks Mike for the feedback<div class=""><br class=""></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 class="">Ack, although the library was written for a use-case that involves obmc, it doesn't <i class="">require</i> obmc. Should work just fine in general Linux.</div><div class=""><br class=""></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 class="">part programming</i> is specific to each device class...no guarantee of a common interface across multiple parts.<br class=""></div></div></blockquote><div><br class=""></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 class=""></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 class=""></div><div>The problem with STORE_USER_ALL is if the power fails or the NVM fails.</div><div><br class=""></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 class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""><div class=""><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 class="">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 class=""></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 class=""></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 class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""> </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 class="">Sounds good, feel free to reach out to me on an individual basis. </div></div></div></div></blockquote><div><br class=""></div>Ok. Vivek is on the same list, and he can reach out for an official invite.</div><div><br class=""></div><div>Mike<br class=""><blockquote type="cite" class=""><div class=""><br class=""><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" class="">proclivis@gmail.com</a>> wrote:<br class=""></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 class="">

<br class="">

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 class="">

<br class="">

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 class="">

<br class="">

Imagine that programming might be done for:<br class="">

<br class="">

- ICT<br class="">

- Proto Builds<br class="">

- Engineering Bringup<br class="">

- Remote upgrades<br class="">

<br class="">

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 class="">

<br class="">

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 class="">

<br class="">

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 class="">

<br class="">

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 class="">

<br class="">

My interest is two part:<br class="">

<br class="">

1) I am interested in anything that enables our work<br class="">

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 class="">

<br class="">

Mike<br class="">

<br class="">

<br class="">

<br class="">

> On Apr 23, 2021, at 4:22 PM, Jason Ling <<a href="mailto:jasonling@google.com" target="_blank" class="">jasonling@google.com</a>> wrote:<br class="">

> <br class="">

> Hi all,<br class="">

> <br class="">

> 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 class="">

> <br class="">

> 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 class="">

> <br class="">

> The idea is that more and more classes get added that will support different pmbus devices. <br class="">

> General idea is that each device that gets support can expose methods to allow device upgrade, black box retrieval, etc..<br class="">

> <br class="">

> Anyways, wanted to gauge community interest in this so I can determine how motivated I should be to upstream it.<br class="">

> <br class="">

<br class="">

</blockquote></div>

</div></blockquote></div><br class=""></body></html>