Need a new repository for openpower-cable-management

[jinuthomas]

IBM is developing a high end machine with multi nodes connected via FSI cables and SMP cables. we would like to have the cable management code started and so the ask for this repo.

details for the cable as well as the design can be seen in the below: https://www.ibm.com/docs/en/power9/9080-M9S?topic=menus-validating-cables-in-9080-m9s-system https://patents.google.com/patent/US20180054362A1/en?oq=US20180054362A1

Maintainers - jinu.joy.thomas@in.ibm.com

[williamspatrick]

Why openpower? Other systems also have cables, right? We can't write this in a way that doesn't have FSI specifics in it (or those are one particular detection method)?

Do you have any design intentions for the repository itself? I'm not reading a patent to guess at what your software might do.

[williamspatrick]

Does anyone know if this ever got implemented? I don't recall seeing it. It seems like we could enhance this design (and implement it)?

https://github.com/openbmc/docs/blob/275f271fc44ae3cb52fcbc1ff82e067881482a24/designs/gpio-based-cable-presence.md?plain=1#L9

[jinuthomas]

Why openpower? Other systems also have cables, right? We can't write this in a way that doesn't have FSI specifics in it (or those are one particular detection method)?

I had a long thought if we could have this in phosphor, the issue is that the FSI requires many specifics that is IBM only used, unless we have some other companies which use it, this is very unlikely as the FSI line is slow and nowadays pice is extensively used it does not hold ground for the community. Secondly the validation requires FSI link to be tied to the cable as well as need CFAM-S for verification. This is on a multi node architecture with redundant BMCs. and FSI cable going to all nodes available. The SMP cable could be used out side but that has its own downside when IBM has an active cable and a passive cable for SMP, the connectors itself has ID bits. Also the active cable has a vpd chip in it , and it contains IPZ or keyword vpd. So this would also have some specifics in it. further any new cable could come but I doubt it will be of industry standard, as we had UPIC Cables delivering power between node and the control unit , and also clock cables for supply of the clock between controller to all nodes. Due to the above reasons I thought it would be fit in openpower , further I have not seen any cable repo yet , so could conclude either the other systems (made by companies associated with openbmc) have downstream code for cable detection, validation and verification or do not use cables at all.

Do you have any design intentions for the repository itself? I'm not reading a patent to guess at what your software might do.

Yes i am in the process of finalising the design doc, further the patent had the validation flow shown as a flowchart which would have been easy to understand and so that was shared. We do have it already implemented in proprietary code. will need to get it standardised and align to the openbmc packages.

Does anyone know if this ever got implemented? I don't recall seeing it. It seems like we could enhance this design (and implement it)?

This design is IPMI specific, i could only reuse the part on how the cables will be shown on dbus and be compatible with redfish. Also we will be using phosphor inventory manager for hosting the DBus and do not plan to use entity manager for it.

[williamspatrick]

Yes i am in the process of finalising the design doc.

Good.

...further the patent had the validation flow shown as a flowchart which would have been easy to understand and so that was shared.

I don't want to read your patent because I don't have any patent protection and I don't want to accidentally let any parts of the patent into a design I might work on. The minute you contribute code / design under Apache, we (the community) now have some patent protection.

This design is IPMI specific, i could only reuse the part on how the cables will be shown on dbus and be compatible with redfish.

I do see a lot of IPMI words in the document, but I think the dbus parts are the important / reusable parts. Hopefully that can be leveraged in whatever you're proposing.

I had a long thought if we could have this in phosphor, the issue is that the FSI requires many specifics that is IBM only used...

We have lots of cases of plugin/configuration support for machine-specifics.

[mdmillerii]

@jinuthomas thinking about the redfish model and how cable validation might fit in.

To me the steps are

1. Selecting a plan to validate
2. Establish communication with the remote end(s)
3. Optional Verify both ends have a cable present
4. Condition one end to identify a specific cable be it wiggle a gpio , force signals active/released,, or initiate a data flow across it (Ethernet LLCP,)
5. Verify the expected response and hence the specific cable is connected per the plan . Repeat 4 and 5 for this cable with additional steps.
6. Optionally check if a response was identified on another port indicating a misplug or swapped cable
7. Notify the remote and to terminate identification of the current cable
8. Reoeat 3-7 for each additional cable

Note the above procedure works for passive cables be they custom, Ethernet, or some vendor specific connections as long as an independent communication path can be established (or a dependent path used for just consistentcy cross check)

Maybe add step 2b stablish or verify state (9 release to normal function ) if the identification interferes with normal operation.

Am I missing something significant? Is this significantly more function than you anticipated? Can you consider factoring the current private code along these lines?

I could see this framework applied to Ethernet cables (with LLCP , link up/down, or per interface network traffic), PCI-e cables, power cords from smart PDU outlets to power supplies (Redundant PSU or just expected controller disappeared/reappeared with expected uptime, or minimally power rack to establish a management network then individual expected controllers), not that you would be expected to implement any of those.

https://github.com/openbmc/docs/blob/275f271fc44ae3cb52fcbc1ff82e067881482a24/designs/gpio-based-cable-presence.md?plain=1#L9

I agree the only thing useful is dbua cable representation qs it was only a cable is present and how to represent it in the limited ipmi space when Redfish neither has limits or expects to be combined nor PMC to my knowledge.

[jinuthomas]

@mdmillerii thanks for the reply, I do agree what you have mentioned above is a very generically high level , the issue is that I have a lot of extra fittings for IBM and am still trying to figure where each piece can come in , It will not be so easy to write it in the above format. Let me take my time to get something up.

[williamspatrick]

Closing until design document is available. Please reopen when you have time to submit this.