Re: [dmidecode] OEM type 236 for HPe Gen10(+) servers

[Erwan Velu]

Jerry, can you share that with us please ?

Le lun. 9 nov. 2020 à 18:29, Erwan Velu <erwanaliasr1@gmail.com> a écrit :

> Thanks Jerry,
> Would it be possible to get the definition of the other fields including
> why we have different structure sizes ?
> Erwan,
>
> Le lun. 9 nov. 2020 à 18:18, Jerry Hoemann <jerry.hoemann@hpe.com> a
> écrit :
>
>> On Mon, Nov 09, 2020 at 05:52:37PM +0100, Jean Delvare wrote:
>> > On Mon, 9 Nov 2020 16:31:54 +0100, Erwan Velu wrote:
>> > > > +                      *  0x05  | WWID       | 64B   | SAS Expander
>> WWWID
>> > > >
>> > > > Following the convention that is used in the other tables in this
>> > > > function, the "B" stands for bytes, not bits, so that should be
>> "8B".
>> > > >
>> > > I fixed with QWORD which sounds more accurate right ?
>> >
>> > Yes, QWORD would work too :-)
>> >
>> > > > > (...)
>> > > > > +                     /* If the record isn't 0x15, that's
>> suspicious */
>> > > > > +                     if (h->length != 0x15) break;
>> > > >
>> > > > If I counted right, you actually only decode 4 + 15 = 19 bytes. Any
>> > > > idea what's left in the last 2 bytes that lead to length = 21
>> (0x15)?
>> > >
>> > > I have to admit I reversed the output, with their agreement, of an HPe
>> > > tooling so I might got wrong here.
>> > > HPe didn't share the spec to me on this.
>> > > So the first byte is maybe at 0x3 and not 0x4, this could explain 1
>> missing
>> > > byte.
>> >
>> > The useful payload definitely starts at offset 0x4, as is the case of
>> > all DMI structures, because the first 4 bytes are used for a standard
>> > header (1 byte for the type, 1 byte for the size, 2 bytes for the
>> > handle, see section 6.1.2 "Structure header format" in the SMBIOS
>> > specification).
>> >
>> > > About the Total Bays, the size of the structure is unknown to me, I
>> > > suspected a WORD as it worked on my system.
>> > > That's possibly wrong.
>> >
>> > OK, then my guess would be that the Total Bays value is encoded on 1
>> > byte (offset 4 + 0x0D), and the following byte (offset 4 + 0x0E, which
>> > has value 0 for you but not for me) stands for something different.
>>
>>
>> From the documentation:
>>         Total Bays is a byte in size.
>>         Fields following are "reserved"
>>
>>
>>
>> >
>> > > > (...)
>> > > > I2C addresses are 7-bit numbers. For all the type 236 examples I've
>> seen
>> > > > so far, the values are even numbers in the 0xA0-0xAE range, which
>> does
>> > > > NOT fit in 7 bits. I suspect the 7-bit value is left-aligned (which
>> > > > happens often in the I2C literature, because that's how the address
>> is
>> > > > sent on the wire, with bit 0 representing the transfer direction).
>> > > >
>> > > > Therefore you should right-shift the value by 1 bit before you print
>> > > > it, so that it matches the actual I2C address.
>> > >
>> > > I see what you mean but in the sample I have from HPe, 0xAE is read as
>> > > 0xAE, I don't see any shift in their usage...
>> >
>> > Well, some people are used to left-aligned I2C addressed, because it is
>> > found in some documentation. Maybe the author of the tool you looked at
>> > is used to that. But in the Linux world, we always right-align I2C
>> > addresses for consistency.
>> >
>> > > Maybe they code it in 10bits so I should consider the byte at
>> position 3
>> > > while I starts at 4...
>> >
>> > I don't think so. 10-bit I2C addressing is rare and usually avoided in
>> > major standards because not all controllers support it. In the examples
>> > I have, when there are 2 type 236 records, the first one has I2C
>> > address 0xA0 and the second 0xA2. Note that both have bit 0 set to 0,
>> > and the difference is 2. Now just shift by one bit to the right, you
>> > get 0x50 and 0x51, which are common, consecutive 7-bit I2C addresses.
>> >
>> > --
>> > Jean Delvare
>> > SUSE L3 Support
>> >
>> > _______________________________________________
>> > https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
>>
>> --
>>
>>
>> -----------------------------------------------------------------------------
>> Jerry Hoemann                  Software Engineer   Hewlett Packard
>> Enterprise
>>
>> -----------------------------------------------------------------------------
>>
>