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

[Jean Delvare]

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.

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