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

[Jerry Hoemann]

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