<html><body><p>Answering #2:<br><br>IPMI FRU format has 2 more sections namely, INTERNAL and MULTI although we have not been using this in our code.<br><br><img src="cid:1__=EABBF50FDFB544568f9e8a93df938690918cEAB@" width="242" height="328"><br><br>I would vote for appending the MAC as part of product or board and then updating the offsets+size accordingly in the area specific header that would now tell the size including the MAC data. What this also means is that common header meta data would change.<br><br>Another approach would be looking at what areas have *not* been populated for some FRU that is on the board and then squeeze this new one into that un-populated area and populate that area specific header and common header.<br><br>All the FRU's may not necessarily have all the areas populated. What I have seen most is just 2 areas ( Board, Product) / ( Chassis, Board) / (Chassis, Product) so we can use whatever that is not populated and put this new one there.<br><br>Also, if this VPD is readable by HB, I am guessing we would need to tell HB on this format.<br><br>We do not want to append MAC to product area since it overlaps with multi area and will result in corruption..<br><br>Last resort,  we can either use INTERNAL -or- MULTI but using INTERNAL area looks a more cleaner -but- that needs a code change since we have not been supporting it. So I would nto vote for this....<br><br>Thanks<br><br>-------------------------------------------------------------------------------------<br>Thanks and Regards,<br>Vishwanath.<br>Advisory Software Engineer,<br>Power Firmware Development, <br>Systems &Technology Lab,<br>MG2-6F-255 , Manyata Embassy Business Park, <br>Bangalore , KA , 560045<br>Ph: +91-80-46678255<br>E-mail: vishwanath@in.ibm.com<br>----------------------------------------------------------------------------------<br><br><img width="16" height="16" src="cid:2__=EABBF50FDFB544568f9e8a93df938690918cEAB@" border="0" alt="Inactive hide details for "Adriana Kobylak" ---21/04/2016 02:22:18 am---Mfg will be storing the MAC address and UUID of the Bar"><font color="#424282">"Adriana Kobylak" ---21/04/2016 02:22:18 am---Mfg will be storing the MAC address and UUID of the Barreleye system in  the FRU VPD so that we can</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">"Adriana Kobylak" <anoo@us.ibm.com></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">OpenBMC <openbmc@lists.ozlabs.org></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">21/04/2016 02:22 am</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">FRU VPD - MAC and UUID</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">"openbmc" <openbmc-bounces+vishwanath=in.ibm.com@lists.ozlabs.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Mfg will be storing the MAC address and UUID of the Barreleye system in the FRU VPD so that we can persist it better. Couple questions:<font size="4"><br></font><br>1. The UUID is planned to be stored in the motherboard VPD. Anybody has the info on which eeprom is the motherboard VPD? Seems the only chips under /sys/bus/i2c/devices/ with vpd are the ones from the i/o, expander, and hdd cards (0-0050, 6-0055, 6-0051).<font size="4"><br></font><br>2. The MAC is planned to be stored at the end of the i/o board VPD. All of the FRU VPD follow the format of header->chassis_info->board_info->product_info. The header contains the offset to the *_info areas. Without an offset to the MAC (which would be stored after the product_info area), we could just read passed the product_area and if it's not 0s, assume it's the MAC. Would it be better to ask Mfg to add the offset to the MAC to header although this breaks the IPMI formatting, or get the MAC into one of the custom fields inside the product info area. Thoughts?<tt>_______________________________________________<br>openbmc mailing list<br>openbmc@lists.ozlabs.org<br></tt><tt><a href="https://lists.ozlabs.org/listinfo/openbmc">https://lists.ozlabs.org/listinfo/openbmc</a></tt><tt><br></tt><br><br><BR>
</body></html>