dmidecode-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Erwan Velu
Subject: Re: [dmidecode] OEM type 236 for HPe Gen10(+) servers
Date: Mon, 9 Nov 2020 18:29:33 +0100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]