hello again I also updated bios in HP6820s (F.0B A) and now I can not activate: / EDIT: i call to service, a downgrade bios is safe, i back to F.09 and works.
Hi flagmax. I'm assuming at the new bios there isn't a SLIC anymore, so WoW doesn't work. I thought about to make a universal patch to introduce a fresh SLIC. First I've seen that right behind the XSDT there are mostly 8 bytes free to insert a new call (to SLIC). This should be verified. I'll check it again.... Secondly, even more important: Some acpi tables are called from RSDT AND from XSDT! The RSDT and the XSDT point to MCFG, for example. (Both tables have got THE SAME entry to MCFG, except the address length). Additionally our first mods were made to replace this table. So the idea: Since there are two calls to MCFG (from RSDT AND XSDT) what about to replace the call to MCFG at XSDT to the new written SLIC at a free place? The MCFG will be remained since it's called from RSDT as well. The fresh introduced SLIC will be called from XSDT (only) so activation should work. Result: MCFG will not get lost, SLIC will be there to activate.... So the new code should check for RSDP revision 2, find XSDT, after that locate call from XSDT to MCFG. Find a free place for SLIC, write SLIC, replace call to MCFG with call to SLIC at XSDT. Finally patch OEM and OEM table ID's to be the same of SLIC. What do you think? IMO it sounds promising Edit: To make it even more universal your new code can find a 'double called' acpi table by itself (called from RSDT and XSDT, just find a equal address entry). So the only premise must be RSDP revision 2. AFAIK all newer bioses have got the revision 2, at least Notebook bioses.
Yen: That does look very promising as long as MCFG will still be called from RSDT. One thing on my mind is where to find 176h bytes of free space. I wish my PC had XSDT table to test. Can we test this idea with RW first since we got the scripter and it won't take much time to make .rw file?
My HP550 has a XSDT, I will help you if you can give me detailed instruction, because I'm new with this stuff.
Thanks for your offer to help. If you don't mind you can post your AcpiScope report file to have a look at it. Thanks! @flagmax Sure, but unfortunately I don't have XSDT, too We can ask petar for additional help, since he's got XSDT and is familiar with all the needed tools already.... To get the free space to write SLIC I suggest to scan for highest address entry of XSDT and to add let's say a fixed amount (500h) bytes secure offset. Additionally check if calculated needed space consists of FFh bytes. (If not add again 500h and recheck)-->loop. Finally write SLIC and replace its start address at XSDT (where MCFG entry was located). Or simply add 100000h (1Mbyte) to highest address entry, no check at all..... Practically you can write SLIC to any writeable FFh bytes physical memory you want to. According to ACPI specification the OSPM - Operating System-directed Power Management will later at boot process notice it as used (allocated) acpi namespace......this you can't simulate perfectly using rw everything, since boot process of OS is already done and the calculated space for SLIC could be used by drivers or programs already. The chain to find SLIC destination is: OSPM--->RSDP--->XSDT--->SLIC The present code to patch a SLIC (wow) I would use as well. First search if SLIC is present, if yes, use the code, if no jump to new.. Flagmax, I know it's a easy speaking I'm doing here. I'm not able to program anything regarding that matter. I don't know if my approach / ideas are going too far or aren't realisable.... I'll PM petar and ask for support.....petars original *.ats report is located somewhere at this thread.....
Yen: Your pseudocode is right on the money. It's how it should be done. One thing I don't understand is memory layout. My PC has 1gb of RAM. Thats 3FFFFFFFh/1073741823d bytes total. My RSDT lives at 3FFFC000. How do I know when to stop scanning for FF's? What happens when you add 1meg and it goes over 1gb, I tried HWDirect to read at 40000000h and my PC rebooted.
Upgrading RAM will affect Wow patch? Hello Flagmax! What I noticed from your below post is that this Wow patch is in some way connected to the RAM installed on the system to work properly. I mean the codes in the Wow patch is using some portion of RAM to reside and work properly. Is this true? Say for instance, if I applied Wow patch when my system was installed with 2 G.B. of RAM and later, if I upgrade the RAM to 3 G.B. on the same system, than will this affect the Wow patch in any way since the RSDT earlier used to reside at a different location on 2 G.B. RAM? Probably, I'll be requiring some clarification with the way Wow patch actually works and where exactly does all the files residing inside Wow patch affect on the system at Hardware & Software level. I had used WoW_1.04_HP_530 to activate Vista on my HP 530. Regards, Apoorva.
I give up with vista for the moment, I have xp pro sp3 on my new laptop , ... but I'm glad to help.. I will send you a PM with my email address, if you need me and I'm not present here.
@flagmax I had a look at a memdump made of an old PC. Maybe if we have a look at different AcpiScope reports we can find a universal condition, like before RSDT there is always free space....will do more dumps.... Btw: Free areas consist of 00 bytes, not FFh, I missed that.
@petar Can you please dump right before your RSDT table to have a look if there are at least 176h bytes of free space (00 bytes). Thanks.
Thanks petar. Flagmax, what about to get RSDT address minus 176h, have a look for 00 bytes then write it there. If not empty, go down 176h*2 and have a look again....minus 176h*X till found....no worry about to get out of range. Range must sum to zero.... If there is anything else to do, let me know.....
I also checked space before RSDT on two PCs and there is enough space for SLIC and plenty more earlier in Ram. I will start on the project sometime this week. First I will try to replace MCFG table entry in XSDT later will try to extend it. Thanks guys.