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.