FRU VPD - MAC and UUID

Thu Apr 21 18:44:49 AEST 2016

The question is "Which eeprom maps to FRU: 0x03".

Unless this is part of some MRW and things like that, there needs to be
some way to communicate the eeprom info to HB.

Thanks

-------------------------------------------------------------------------------------

Thanks and Regards,
Vishwanath.
Advisory Software Engineer,
Power Firmware Development,
Systems &Technology Lab,
MG2-6F-255 , Manyata Embassy Business Park,
Bangalore , KA , 560045
Ph: +91-80-46678255
E-mail: vishwanath at in.ibm.com
----------------------------------------------------------------------------------

From:	Yi TZ Li/China/IBM
To:	Vishwanatha Subbanna/India/IBM at IBMIN
Cc:	anoo at us.ibm.com, OpenBMC Members, openbmc at lists.ozlabs.org
Date:	21/04/2016 01:53 pm
Subject:	Re: FRU VPD - MAC and UUID

For question #1, is the FRU with ID "0x3"  for motherboard (Planar) VPD
(Area CHASSIS_3)? It is managed by Hostboot.

Thanks,

Yi Li (Adam)
OpenBMC Developer
Office: 86-21-60928951
Mobile: 13524695440
Email: shliyi at cn.ibm.com

 ----- Original message -----
 From: Vishwanatha Subbanna/India/IBM
 To: "Adriana Kobylak" <anoo at us.ibm.com>
 Cc: OpenBMC <openbmc at lists.ozlabs.org>, OpenBMC Members
 Subject: Re: FRU VPD - MAC and UUID
 Date: Thu, Apr 21, 2016 3:19 PM

 Answering #2:

 IPMI FRU format has 2 more sections namely, INTERNAL and MULTI although we
 have not been using this in our code.

 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.

 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.

 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.

 Also, if this VPD is readable by HB, I am guessing we would need to tell
 HB on this format.

 We do not want to append MAC to product area since it overlaps with multi
 area and will result in corruption..

 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....

 Thanks

 -------------------------------------------------------------------------------------

 Thanks and Regards,
 Vishwanath.
 Advisory Software Engineer,
 Power Firmware Development,
 Systems &Technology Lab,
 MG2-6F-255 , Manyata Embassy Business Park,
 Bangalore , KA , 560045
 Ph: +91-80-46678255
 E-mail: vishwanath at in.ibm.com
 ----------------------------------------------------------------------------------

 "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

 From: "Adriana Kobylak" <anoo at us.ibm.com>
 To: OpenBMC <openbmc at lists.ozlabs.org>
 Date: 21/04/2016 02:22 am
 Subject: FRU VPD - MAC and UUID
 Sent by: "openbmc" <openbmc-bounces
 +vishwanath=in.ibm.com at lists.ozlabs.org>

 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:

 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).

 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?
 _______________________________________________
 openbmc mailing list
 openbmc at lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/openbmc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160421/4c934848/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160421/4c934848/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0D523044.gif
Type: image/gif
Size: 167616 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160421/4c934848/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0D543284.jpg
Type: image/jpeg
Size: 19808 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160421/4c934848/attachment-0001.jpg>