Hi, according to ACPI specifications the table checksum byte is at offset 9h of table AND IT MUST SET that the ENTIRE table sums to zero. Not a zero byte!!! Most of the SLIC's floating around the net got here a zero byte. Or even a wrong checksum like ACER "47" Result: Checksum errors or no activation. That's the reason why ASUS SLIC is favored. (It' has got the right checksum.) Win hex is able to calculate: Mark entire table (crtl+A) and calculate (ctrl+F2) checksum 8-bit. The calculated value MUST BE ZERO!! If not, change byte at offset 9h till calculated checksum will be zero. So ACER has to be "CD" NOT "47" !!!! We should mod more different SLIC'S. I think 90% of the mods have got ASUS SLIC. Yen
Are you 100% positive about this? I have made VMware bioses for every available SLIC table, just for the purpose to test if the OEM Certificates available matched... all of them activated just fine! I have not found one SLIC table that complained about checksums whatsoever
Yes, seems you are right about this... Noticed this after applying the AWARD static mod to my own bios using slic table with wrong checksum offset Using ACPIScope no SLIC was shown, after fixing the checksum as you mentioned isame ACPIScope displayed SLIC table correctly. nice find!
Yen, are you saying that the other 10% with other OEM SLIC has checksum error even tho vista is reported activated? is there a way to check?
No, I meant there are lots of ASUS mods. The other 10% I guess are of other OEM'S. Some of the SLIC got wrong checksums and show errors or don't activate. This is probably the reason why ASUS is / was preferred to use.. Vista = activated = sum is correct or not used to validate You can check the slics floating around. Sony and dell were never wrong. ASUS also Yen.
Most current AMI and AWARD revisions contain routines to dynamically apply OEMID and OEMTableID strings to the ACPI tables pointed to by the RSDT/XSDT and therefore update the checksum byte during the initialization phase as well. So not patching in SLIC tables with correct checksum bytes is likely to cause problems on some older AMI/AWARD revisions and several of the more exotic BIOS vendors only.
I search a response to this: I download the VISTA BIOS for ACER ASPIRE M1100. I unpacked it using AWDBEDIT (award bios editor) I found inside the BIOS the SLIC2 table. I compared the SLIC2 TABLE extracted from BIOS with the other known table. The checksum is 2D and not 00! I dont' understand, the checksum must me 00??? The SLIC table inside the BIOS is correct so where is the trouble?
Checksum Errors Hey Yen, I had a couple questions to clarify things a little bit. Fzeven is trying to create a SLIC table so that I can activate Vista on my new PC. The motherboard is a EVGA 610i / 7050 Motherboard with built in nVidia graphics. He has tried about 8 orso times, but each time is always checksum error, and sometimes even invalid bios code = 51. GraceSLIC has also tried with no luck back in May. Same issue exists with the EVGA 630i model that is posted on the "tested slic" list. My understanding after reading your post, is that if the entire bin file needs to return a checksum of 0. By hitting "CTRL + A" you are selecting the entire doccument. By selecting checksum and then 8-bit, you are returning an 8-bit checksum value. When I do a checksum for the entire "NF72V15.BIN" in WinHex, I get a value of B8. When I flash the bios, I get no errors. This file is from the EVGA website. Now, when Fzeven and GraceSLIC created modded bin files, they had different checksums as well. I am curious if we make the file come back with a B8 checksum, if it will stop giving us the error? Or if we need to find a different solution... I am trying to understand why checksum errors are created and what we can do to make this work. Your help would be most appreciated! Maybe we can work on this together Dylan
Checksums are created to make sure that you have got the original code. There are many types of checksums like 8-bit, 32 bit, CRC, SHA-256, MD5…….. Checksums are related to a defined amount / range / piece of code. (A file, a whole CD /DVD, modules, ACPI tables like SLIC). The 8 bit checksum of a ACPI table MUST sum to zero...... If one byte of the defined code has been changed, you’ll get another checksum…… You can also say checksums are protecting the original code…………….. Which tool have you used to flash the mod? Please provide the link to the original bios. IMO the 8 bit checksum is usually not verified at bios…………
Hi again! Where do you get the checksum error? At flashing the bios? Or at boot? What were the settings of winflash? Do you have a floppy drive?