Yes, we are adding some information to the baseboard FRU. We would want it to be updated on the baseboard.
On Jarrell boards, OpenIPMI returns the following entities (complete list on earlier email): 7.1 (IMM Module FRU) fru present 7.2 (system_board) unknown not present On the older boards we have: 7.1 (Basbrd Mgmt Ctlr) mc present Since 7.2 says unknown, not present. We're assuming 7.1 will always represent the baseboard mc (device id = 0; which we know now is not). Actually the list does not contain an entity classified as mc (unlike in the old system). Is the mini-BMC associated to an entity? Also because these are the only entities returned, we use this entity (7.1) to retrieve/update the fru infomation (during system setup). On boot, we look at this fru info, to determine which system config file to load. ipmiutil is not part of our RedHat install. Just installed an rpm for that and will look into this. Thanks. Michael ---- Original message ---- >Date: Mon, 22 Jan 2007 17:16:01 -0500 >From: "Cress, Andrew R" <[EMAIL PROTECTED]> >Subject: RE: [Openipmi-developer] FRU dev id on IMM Module >To: <[EMAIL PROTECTED]>, <[email protected]> > >Sure, to find the MC dev id you just read the SDR IPMB MC Locator record >(shown on the second line of the fruconfig output) to get the IMM FRU >information. > >However, loading the FRU information from fru device id 0 WILL still >give you the baseboard FRU information. So, reading FRU data from >FruDeviceId 0 will still work fine, in all IPMI systems, and that is the >last section of the output I attached. > >The baseboard is where all of the devices and sensors connect, so most >likely that is really what you want to do anyway. Is that what you >meant by FRU updates and appropriate FRU entries? You don't really use >the IMM FRU entries except as inventory for that plugin card. > >Andy > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Monday, January 22, 2007 5:05 PM >To: Cress, Andrew R; [email protected] >Subject: RE: [Openipmi-developer] FRU dev id on IMM Module > >Andy, > >Thanks for the clarification. > >Wouldn't this configuration pose as a problem: FRU updates are done to >the active bmc, w/c is device id 1; yet on bootup, we expect it to be at >device id 0. > >Anyway, to retrive the active bmc device id? Or to determine that the >mini-bmc is overriden? > >The code is used on both type of machines, I have to be able to >programmatically detect which device id is actually active and retrieve >the appropraite FRU entries. Thanks. > >Michael, > >On the Jarrell motherboard where the IMM resides, there is a default >mini-BMC and then the IMM plugin with IPMI 2.0 and the advanced >features. So, there are actually two BMCs, but only one is active at a >time. That is why the IMM has a FRU Device ID of 1, since the mini-BMC >occupied FRU ID 0. > >This should not pose a problem, and attached is the output from >'fruconfig' (from ipmiutil) on a TIGI2U system with an IMM. You can see >from the attached immfru.txt that the SlaveAddress/ChannelNumber for the >IMM BMC is 20/00, while the SlaveAddress/FruDeviceID is 20/01. > >The IPMI 1.5 text you reference is similar to text in section 37.7 about >the FRU Device ID, and is still true, since the mini-BMC on that >motherboard is FRU Device ID 0, but it is inactive. > >Andy ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
