FRU VPD - MAC and UUID

[Vishwanatha Subbanna]

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



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/da7a6fc5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0C765961.jpg
Type: image/jpeg
Size: 19808 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160421/da7a6fc5/attachment-0001.jpg>
-------------- 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/da7a6fc5/attachment-0001.gif>