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.hoem...@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 > > ----------------------------------------------------------------------------- > _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
