Jan, I would really appreciate if you could answer my question and if you could carefully read what I wrote. I did not deny that the two entries are part of the SMBIOS structure.
Again: The 2nd checksum is for the 2nd part of the SMBIOS structure. If the 2nd part (offset 0x10 ... offset 0x1e) change and the 2nd checksum at offset 0x15 is adapted then the 1st checksum at offset 0x04 does NOT need to be adapted because adaption of the value at offset 0x15 neutralized the other changes within the 2nd part. The same applies for the BIOS checksum which is not part of the SMBIOS specification but would need to be adapted for the same reason. I might be wrong but if so then please tell me exactly _what_ I didn't get. So, please, to save us both from wasting more time: Which is the Windows tool which complained about a wrong checksum? Thanks, Frank On Monday 02 April 2012 18:06:56 Jan Schunk wrote: > Yes, the DMI Entry is part of the SM entry, as I also wrote (31 = 0x1f). > But the second checksum at 15h is only for the 15 Bytes (0x0f) stating > at 10h. > The entries we are talking about are part of SMBIOS specification, so > the values inside are described in the document. > There may be a BIOS checksum but not here. > > Frank Mehnert wrote: > > Of course there is a BIOS checksum but this is not mentioned in the > > SMBIOS specification because the SMBIOS is only a part of the normal > > system BIOS. > > > > Furthermore, as you can see in the source code, 'Entry Point Length' > > is 0x1f so it includes the following DMI table. Therefore the checksum > > at offset 04 includes also the DMI table. > > > > Which Windows tool did you use to check the SMBIOS checksum? > > > > Thanks, > > > > Frank > > > > On Monday 02 April 2012 17:10:52 Jan Schunk wrote: > >> Additionally I looked at the definition in the standards document. > >> There is no BIOS checksum in the structure. Both checksums are only > >> checksum of the EP itself. > >> > >> This means, other calculation has also to be changed: > >> - for (unsigned i = 0; i< pThis->cbPcBios; i++) > >> > >> + for (unsigned i = VBOX_DMI_TABLE_OFFSET; i< > >> VBOX_DMI_TABLE_OFFSET + 0x10; i++) > >> > >> > >> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134v2.5F > >> ina l.pdf > >> > >> 04h Entry Point Structure BYTE > >> Checksum of the Entry Point Structure (EPS). > >> This value, when Checksum added to all other bytes in the EPS, > >> will result in the value 00h (using 8-bit addition calculations). > >> Values in the EPS are summed starting at offset 00h, for Entry Point > >> Length bytes > >> > >> 15h Intermediate Checksum BYTE > >> Checksum of Intermediate Entry Point Structure (IEPS). > >> This value, when added to all other bytes in the IEPS, > >> will result in the value 00h (using 8-bit addition calculations). > >> Values in the IEPS are summed starting at offset 10h, for 0Fh bytes. > > _______________________________________________ > vbox-dev mailing list > [email protected] > https://www.virtualbox.org/mailman/listinfo/vbox-dev -- Dr.-Ing. Frank Mehnert Senior Manager Software Development Desktop Virtualization, VirtualBox ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
