I think it was a combination of where the slic info was placed and the checksum of the file. The last one was a SSV2 with different slic location, and different checksum changes. I also resized one of the modules a bit different. I dont know exactly the problem, but as long as it works for you...It was success. I am very glad it worked..I hope this one lasts you a while!! How did you flash this mod.. edit: I think the tool mods were broken because of checksum. I think maybe I was overwriting some code, allocate in memory on boot, with slic table before. After thinking about it, the biggest difference between the SSV2 mods were the slic placement. I think the checksum would have just not flashed if this were the problem.
Sorry. Since written lots of posts have appeared! Just to get this straight. Your first try - SSV3 with 0.92 - did you use AMIMMWIN or MMTOOL (ie was the mmtool checkbox ticked)?? If you used AMIMMWIN then that screwed the checksum - the BIOS has $512 in the bootblock. The newer versions pick this up. 0.92 only played with the checksum for SSV2 methods. Andy
OK tryed this on my asus rampage formula bios and successfuly flashed with ezflash method, BUT it complains about "invalid boot block" unless you use mmtool method and insert 1B module with it. ATM im using SSV3 is there any point of trying dynamic method? Thanks for your hard work on this tool!
Hi. Thanks. You mean that EZflash complained about the boot block, right? Which version of the bios did you try? Andy
I am pretty sure the original SSV3 failure was due to the AMIMMWIN damage. Was your first attempt an SSV3 mod with MMTool? I note that there are some random short byte sequences after the AMIBIOSC section that are lost after MMTool. I suspect these might be the cause of the problems - I believe some are referenced from the 80h module but am just figuring out how to parse it. Where did you try putting the SLIC for SSV2 until you settled on 60000h? This was due to the header for module 6h having an error in the original BIOS (the sizes don't match) and my tool skipped it - however it appears that this doesn't matter so I have updated the code. Andy
Try the new version. I have not tested as I have no boards this old so make sure you know how to recover however running it through the 4 core 6/7 bioses I can find the changes look sound. Andy
@ andyp, just tried it with my bios file loaded it no problem and loaded the asus SLIC patched ok but i can't really try it andy till i get new bios chip or old bios chip reprogrammed, but as far as i'm concerned excellent a program that works with amibios 7 take a lot of work off the guys having to do it manually, hopefully some one on the forum can verify it is working before i can get my bios chip back. Keep up the good work
It seems that dynimic also works for rampage formula, cant check atm since i would need to go reinstall vista, but at least it boots/upgrades normaly + i see slic: FieldValue ACPI Table Properties ACPI SignatureSLIC Table DescriptionSoftware Licensing Description Table Memory AddressAFF8AE50h Table Length374 bytes OEM ID_ASUS_ OEM Table IDNotebook OEM Revision11000624h Creator IDMSFT Creator Revision00000097h why i actualy went to try this was, was playing with memory timings in windows, computer locked up and it seems that it moved date to year 2000, half of licenses became not functional and before i noticed that date is moved, i already tryed different methods of slics alocation. So word of advice, you might break vista activation compleatly if you play around with changing date to much... but funny thing is, that win7 beta activation didnt broke.
Hi. I have fixed the potential problem. It was a little tricky. It looks like v6 BIOSes have a 12 byte module header. v7 BIOSes have a 20 byte module header. If you use the old AMIMM program on a v7 BIOS it will curtail the headers to 12 bytes - but there is code in the bootblock of the v7 BIOSes that expects 20 byte headers. Luckily the v2 of MMTOOL can be used with command line options. The next problem was it appears v7 has an 8 byte module checksum whereas MMTOOL v2 puts in a 32 bit checksum. Again there is code in the bootblock that expects a 8 bit checksum so the program now recalculates all module checksums to be 8 bit where appropriate. I think I have covered all the bases now! Cheers, Andy
Please upgrade to latest version. It checks that AMIMMWIN will not damage module 80h. This has potentially caused a bad flash. Andy
yeh was just starting to figure this out, every time you replace some module with mmtool, modules 80h will increase for ~40bytes on my bios (from 104 bytes to 144) and causes some problems with some bios options, however i didnt notice any problems with amimmwin. Is this bug in MMtool? Thing is, i want to replace some other modules in bios (ich, jmicron modules), if im doing it with mmtool i get corrupted 80 module, if i try to do with amimmwin i get incorrect EBB checksum. How does slictool repairs this things? are there some kind of options that im missing in amimmwin?