Jerry, can you share that with us please ? Le lun. 9 nov. 2020 à 18:29, Erwan Velu <erwanalia...@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.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