I am trying to read FRU information via openipmi and I am not able to get any. Neither openipmish nor my code shows any FRU although other tools like ipmiutil and ipmitool show something reasonable.
I guess the problem is the FRU I want to read is not associated to an entity but it is associated to MC. When I run openipmish and open domain I can get FRU via raw commands to MC
I am trying to read FRU information via openipmi and I am not able to
get any. Neither openipmish nor my code shows any FRU although other
tools like ipmiutil and ipmitool show something reasonable.
I guess the problem is the FRU I want to read is not associated to an
entity but it is associated to MC. When I run openipmish and open
domain I can get FRU via raw commands to MC
But the fru commands deal with entities and not with MCs and there is
no entity with a FRU on my system.
Is there a possibility to get FRU from MC? Or is my hardware wrong
because there is no entity with FRU?
Well, your hardware is wrong, but I think you can still get the FRU
data. OpenIPMI does a fairly strict interpretation of the IPMI spec,
and ipmitool tends to be a bit looser to accommodate bad hardware.
You can use the "domain fru" command to create your own FRU data
instance. For instance:
domain fru domain1 1 0x20 0 0 0 0
You have to set "is_logical" to true, the device address is the BMC
address on the IPMB, generally 0x20, and the rest generally default to
zero. The device_id is the FRU device id in the read/write commands, it
should be zero for what you want.
I will do the same by the ipmi_domain_fru_alloc() and it s callback in my code.
I understand the openipmi is strict - but I am not a standard expert so it is difficult to blame HW for me. Could you point me to standard what requiremnt the standard violates?
Milan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will do the same by the ipmi_domain_fru_alloc() and it s callback in
my code.
I understand the openipmi is strict - but I am not a standard expert
so it is difficult to blame HW for me. Could you point me to standard
what requiremnt the standard violates?
Well, it's hard to nail down some of these, but this one is clear, even
if it is hidden in a strange place. The IPMI spec is very informal and
it's hard to nail down exact "requirements". But general text about
this is in:
1.7.14 Linkage between Events and FRU Information
The in the following:
Table 43-7, FRU Device Locator Record - SDR Type 11h
in the description of byte 7 you have:
[7:0] - Number identifying FRU device within given IPM Controller. FFh =
reserved.
The primary FRU device for a management controller is always device #0 at
LUN 00b. The primary FRU device is not reported via this FRU Device Locator
record - its presence is identified via the Device Capabilities field in the
Management Controller Device Locator record.
which pretty clearly states that you need a Management Controller Device
Locator record with the FRU device enabled. If one of those exists, end
the entity is present (through the fairly complex entity presence
rules) OpenIPMI should fetch the FRU data for it.
Thanks again!
It looks as a good argument. I will try to force HW vendor to update its firmware.
Nevertheless it is good to know that I have possibility to read FRU even with the misbehaving hardware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
I am trying to read FRU information via openipmi and I am not able to get any. Neither openipmish nor my code shows any FRU although other tools like ipmiutil and ipmitool show something reasonable.
I guess the problem is the FRU I want to read is not associated to an entity but it is associated to MC. When I run openipmish and open domain I can get FRU via raw commands to MC
Get FRU Inventory Area Info
But the fru commands deal with entities and not with MCs and there is no entity with a FRU on my system.
Is there a possibility to get FRU from MC? Or is my hardware wrong because there is no entity with FRU?
Zaboj
On 12/11/2015 09:07 AM, Zaboj Campula wrote:
Well, your hardware is wrong, but I think you can still get the FRU
data. OpenIPMI does a fairly strict interpretation of the IPMI spec,
and ipmitool tends to be a bit looser to accommodate bad hardware.
You can use the "domain fru" command to create your own FRU data
instance. For instance:
domain fru domain1 1 0x20 0 0 0 0
You have to set "is_logical" to true, the device address is the BMC
address on the IPMB, generally 0x20, and the rest generally default to
zero. The device_id is the FRU device id in the read/write commands, it
should be zero for what you want.
-corey
Thanks. It works.
I will do the same by the ipmi_domain_fru_alloc() and it s callback in my code.
I understand the openipmi is strict - but I am not a standard expert so it is difficult to blame HW for me. Could you point me to standard what requiremnt the standard violates?
Milan
On 12/15/2015 04:19 AM, Zaboj Campula wrote:
Well, it's hard to nail down some of these, but this one is clear, even
if it is hidden in a strange place. The IPMI spec is very informal and
it's hard to nail down exact "requirements". But general text about
this is in:
1.7.14 Linkage between Events and FRU Information
The in the following:
Table 43-7, FRU Device Locator Record - SDR Type 11h
in the description of byte 7 you have:
[7:0] - Number identifying FRU device within given IPM Controller. FFh =
reserved.
The primary FRU device for a management controller is always device #0 at
LUN 00b. The primary FRU device is not reported via this FRU Device Locator
record - its presence is identified via the Device Capabilities field in the
Management Controller Device Locator record.
which pretty clearly states that you need a Management Controller Device
Locator record with the FRU device enabled. If one of those exists, end
the entity is present (through the fairly complex entity presence
rules) OpenIPMI should fetch the FRU data for it.
-corey
Thanks again!
It looks as a good argument. I will try to force HW vendor to update its firmware.
Nevertheless it is good to know that I have possibility to read FRU even with the misbehaving hardware.