Hi Paul,
Last year you had an email exchange with Julian to inquire about how to program a serial number into the IPMC. I think the problem comes from the fact that the FRU provided by the (remote) compilation, always uses the same number, and you were looking for a way to provide an individual one to each card. Did I remember correctly?
What I would like to know now, is how you are dealing with serial numbers today. Have you made use of the Python script Julian sent you?
Julian is unfortunately still on sick leave, so I was discussing this with Markus and Stefan. Our idea was to provide all cards that we distribute from now on with a part and serial number programmed into the FRU Product Info Area. Would that work for you? Would you still override them?
In addition, there is a part and serial number in a reserved area of the IPMC EEPROM, which can be accessed by CERN OEM commands (if you have the right version of the software compiled). Of course, those numbers would be programmed to the same values as the FRU Product Data. In principle, the user would not have to modify them. They are strictly intended for our use of tracking the cards, whenever you have a problem with them, and we would need to test them again.
Please let me know what the opinion on this is in the L1Calo? Please feel free to add other colleagues to this exchange as necessary.
Cheers,
Ralf.
Hi Ralf, adding Dave Sankey in Cc.,
We never used the script from Julian. As best I remember it was intended to come with the CERN IPMC software/website but there were some issues and no “official” version appeared. Presently we are registering the mac addresses of all our P1 IPMCs and keeping track of the SNs in a spreadsheet.
I think having a more convenient way to check the SN than extracting the module would be very useful and welcome thanks. So, if I get your proposal, the idea is to program new cards with the SN/part info in the EEPROM and FRU. Presumably, the web compilation default should no longer overwrite the FRU unless explicitly requested.
In general I think the EEPROM info is the most robust. When we have several module types in a system it is very easy to try to load the wrong image on a module. Indeed, this happened at our test lab recently. The image did not load correctly(sensor information was from original image thankfully) but the FRU info appears to get overwritten straight away by the upgrade procedure regardless of whether the firmware “sticks”.
We are in the process of upgrading to v1.3. If that version can be used to write the SN to the EEPROM(is there an additional hw version from when it works?) then a script to do that would be very useful (the same script you will use to set new cards up presumably?). Similarly, a script to copy the EEPROM to the FRU info would also be useful. The FRU info is certainly the most convenient since it can be read generically by our OPC servers. However, an OEM command is also useful and can be simply executed over modules in a shelf by an expert. This is as far as LAPP IPMC got. So, if you wanted to be very generic, your OEM to FRU copying script could also be used on LAPP IPMC cards (by substituting the OEM command).
Hope that helps,
Cheers,
Paul
Hi Paul,
Thanks for your reply.
I think we should make the OEM Get MAC Address, Get Part Number, and Get Serial Number commands public. We could make them available in ipmc-project/ipmc-user/user-oem.c for all user projects to pick it up from there. Together with corresponding ipmitool "raw" commands one should then be able to read those numbers from the card. I will discuss this with my colleagues.
You are right about the image produced during the (remote) compilation, which also contains the FRU data and which overwrites on the IPMC. This makes sense for general and version data, but is annoying for the serial number data. We should provide a script, that reads the serial number from the EEPROM, and overwrites the FRU data. This should then be run every time you program the IPMC with a new image. I think Julian had started to provide something along those lines, but I will see with Markus if he can prepare a script with that function.
The FRU data is definitely what should be used from inside the system, i.e. via shelf and system manager. There are ipmitool commands to read the FRU data. You can also write it, but I would suggest to use that very carefully (except for the script mentioned above).
Cheers,
Ralf.