[UNLOCKED] Acer Aspire 5517 bios unlock

[_helix]

Hey forcrz6 I downloaded your zip and tried to run the InsydeFlash.exe but I get this error message

IHISI: get support mode fail SMI !

If anyone knows what is going on please help me out. I might add that I have upgraded the CPU and Ram on this laptop as well as the HDD. Also I fried my board a while ago when replacing the CPU and bought a new one I remember the borads being physically different will the newer on having more chips n such on it but it was still labeled as a Acer Aspire 5517 Mobo. Anyway if any one can help thanks.

[aferraro21]

Confirming I ran the Insideflash posted by forcrz6 in post #7 on my Acer 5532, and it worked perfectly. I was already on the most current 1.11 factory/oe bios, and the one posted here on bios-mods.com successfully unlocked a few areas including an advanced CPU management setting, including the ability to enable "c1e" and "svm".

I'm not overclocked, and dare not to run without these energy saving settings on this older machine, especially with a very weakly designed heatsink. But this custom bios is really nice to have.

Is there any possibility to unlock the virtualization capabilities of my upgraded processor via the bios? Most Turion S1G1 upgrades (which DO support virtualization) from the standard TF-20 processors that came with the computer (which do not support virtualization), are severely limited on these machines. I can tell virtualization is still disabled in my Windows settings, and unless I'm able to unlock it via the bios, I'm not sure what else I can do to unlock this much needed capability.

The goal is to run Mac OS on a virtual machine efficiently to utilize applications that I use which are not supported by Windows.

Thank you for the help and support bios-mods, if anyone can assist with my request for the ability to enable virtualization, I would appreciate it.

[aferraro21]

Is there any chance someone can come through with a bios that allows a user to enable virtualization on these machines? Confirmed in a post above that the Insideflash zip posed by forcrz6, also works on the acer 5532 laptop and allows for some additional modifications not previously available in the manufacturer bios.

Please help if you can.

[aferraro21]

Would anyone be willing to help with modifying this bios to allow for the virtualization setting to be enabled?

[e_favero]

The Virtualization is olny shown in the BIOS, if the cpu supports it. Doesn't? The TF-20 CPU doesn't supports virtualization...

[s⚡dub]

I've performed the upgrade in post #7 to flash the modified BIOS and have confirmed that the C1E and SVM options are now displayed in the processor settings tab. However, when I run the Microsoft hardware-assisted virtualization detection tool (located at https://www.microsoft.com/en-us/download...spx?id=592), it reports that virtualization support isn't enabled.

I suspect that the modification to the BIOS code in that post changes an unconditional jump instruction to one that doesn't bypass the code for the additional menu functionality. Quite obviously, the modified menu sets the motherboard's nonvolatile memory properly and thus appears to work at first glance, but the appropriate flags in the CPU machine state register aren't being updated to reflect the NVRAM setting for enabled virtualization support.

I think what remains missing is the module that sets the SVM flag in the MSR on POST. It may have been bypassed in a manner not unlike the hidden menu settings. Some casual browsing of CPU programming manuals (which are freely available on the manufacturers' websites) suggest that setting the SVM flag and its lock bit is a fairly easy task to accomplish.

While I don't have the necessary knowledge of assembly language along with the tools to build a fully functional fix, I hope someone else is inspired to do so. Like software, hardware too should be free; the end user should be freely able to do as he wishes with the components he purchased—including adding nonstandard extras.

[aferraro21]

Thanks for the response sdub.  Unfortunate that there isn't a way to unlock virtualization on the 5516, 5517, 5532 Acer notebooks.

e_favero, you are correct, the TF-20 does not support virtualization, however on the 5516, 5517, and 5532 notebooks, you can upgrade to a dual core Turion TL-XX model CPU that does support virtualization.  The issue is, that the BIOS will not allow you to enable that functionality.

[s⚡dub]

Only to get a sense for how much effort making a proper, fully-functional modification would take, I downloaded a copy of the appropriate manuals for my processor family (I have the AMD Turion TL-64) and perused it for steps to enable virtualization. These are:

• AMD64 Architecture Programmer’s Manual, Volume 2: System Programming
  
• AMD64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions
  

Page 447 (499 in Acrobat Reader) of Volume 2 contains a C snippet illustrating how to detect whether or not SVM can be enabled. I emulated the steps using Crystal CPUID to access the model-specific register and the feature flags.

For the step:

Code:

if (CPUID Fn8000_0001_ECX[SVM] == 0)

I have the values in the CPUID Information box:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
80000001 00060f81 000005a3 0000011f ebd3fbff

0000011f is the value of ECX (100011111 in binary), and this shows a value of 1 for the SVM bit. The table is in Volume 3, page 607 (643).

For the step (skipping the second step because we know no software is currently using SVM):

Code:

if (CPUID Fn8000_000A_EDX[SVML] == 0)

I have the values:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
8000000a 00000001 00000040 00000000 00000002

00000002 is the value of EDX (10 in binary), and this shows a value of 0 for the SVML bit. This table is in Volume 3, page 617 (653). I understand this to mean that the Turion doesn't support unlocking SVM after the lock bit has been set. According to Volume 2, some architectures do support unlocking after the lock has been set by writing a 64-bit key into a register in the next segment or two prior to resetting the lock and SVM enable/disable bits.

The MSR address c0010114 is responsible for these states, and it has a value of 00000018 (11000 in binary). Volume 2, page 525 (577) shows what these bits are for; the bits SVMDIS and LOCK both being set confirms that the BIOS explicitly disables this feature in all cases and can't be altered by the MSR Editor or any other software.

I used the Phoenix BIOS Tool 2.5.6 to disassemble the NCWxx111.FD file into individual modules and examine the overall structure of the BIOS in an easy-to-read format. I've noted the layout of the driver modules and the various executables within, including one for the POST. While I haven't examined enough BIOSes to know whether or not I'm missing a large driver, I have a hunch that simply changing the data that is written into c0010114 to all zeroes would be sufficient to enable virtualization. It isn't as professional a hack as would be a full integration with the appropriate menu, but it provides the needed feature, and editing data is far less risky than altering any of the actual code.

I'm willing to continue poking around with this if any of the experienced members of this forum are willing guide me in this undertaking.

[shivakumar]

Only to get a sense for how much effort making a proper, fully-functional modification would take, I downloaded a copy of the appropriate manuals for my processor family (I have the AMD Turion TL-64) and perused it for steps to enable virtualization. These are:

• AMD64 Architecture Programmer’s Manual, Volume 2: System Programming
  
• AMD64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions
  

Page 447 (499 in Acrobat Reader) of Volume 2 contains a C snippet illustrating how to detect whether or not SVM can be enabled. I emulated the steps using Crystal CPUID to access the model-specific register and the feature flags.

For the step:

Code:

if (CPUID Fn8000_0001_ECX[SVM] == 0)

I have the values in the CPUID Information box:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
80000001 00060f81 000005a3 0000011f ebd3fbff

0000011f is the value of ECX (100011111 in binary), and this shows a value of 1 for the SVM bit. The table is in Volume 3, page 607 (643).

For the step (skipping the second step because we know no software is currently using SVM):

Code:

if (CPUID Fn8000_000A_EDX[SVML] == 0)

I have the values:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
8000000a 00000001 00000040 00000000 00000002

00000002 is the value of EDX (10 in binary), and this shows a value of 0 for the SVML bit. This table is in Volume 3, page 617 (653). I understand this to mean that the Turion doesn't support unlocking SVM after the lock bit has been set. According to Volume 2, some architectures do support unlocking after the lock has been set by writing a 64-bit key into a register in the next segment or two prior to resetting the lock and SVM enable/disable bits.

The MSR address c0010114 is responsible for these states, and it has a value of 00000018 (11000 in binary). Volume 2, page 525 (577) shows what these bits are for; the bits SVMDIS and LOCK both being set confirms that the BIOS explicitly disables this feature in all cases and can't be altered by the MSR Editor or any other software.

I used the Phoenix BIOS Tool 2.5.6 to disassemble the NCWxx111.FD file into individual modules and examine the overall structure of the BIOS in an easy-to-read format. I've noted the layout of the driver modules and the various executables within, including one for the POST. While I haven't examined enough BIOSes to know whether or not I'm missing a large driver, I have a hunch that simply changing the data that is written into c0010114 to all zeroes would be sufficient to enable virtualization. It isn't as professional a hack as would be a full integration with the appropriate menu, but it provides the needed feature, and editing data is far less risky than altering any of the actual code.

I'm willing to continue poking around with this if any of the experienced members of this forum are willing guide me in this undertaking.

can you explain about this in detail please , if possible by snapshots
whatever you said right. i gone through those AMD architectures book.
but setting SVM enable by MSRWR of Crystal CPUID, doesn't allow.
after that i am not able understand yours passage
canyou help this 

"
 Phoenix BIOS Tool 2.5.6 to disassemble the NCWxx111.FD file into individual modules and examine the overall structure of the BIOS in an easy-to-read format. I've noted the layout of the driver modules and the various executables within, including one for the POST. While I haven't examined enough BIOSes to know whether or not I'm missing a large driver, I have a hunch that simply changing the data that is written into c0010114 to all zeroes would be sufficient to enable virtualization. It isn't as professional a hack as would be a full integration with the appropriate menu, but it provides the needed feature, and editing data is far less risky than altering any of the actual code.
"

Thanking you

[joseant]

Well, the settings for my Acer Apire E 15
According with the link you posted
I have the values in the CPUID Information box:
Code:
CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
80000001 00660f51 00000000 2FaBBFFF 2FD3FBFF

For the step (skipping the second step because we know no software is currently using SVM):
Code:
if (CPUID Fn8000_000A_EDX[SVML] == 0)

2FaBBFFFf is the value of ECX (0010 1111 1010 1011 1011 1111 1111 1111 in binary), and this shows a value of 1 for the SVM bit. The table is in Volume 3, page 607 (643).

I have the values:
Code:
CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
8000000a 00000001 00008000 00000000 0001BCFF


Bits Field Name Description
2 SVML SVM lock. Indicates support for SVM-Lock. See “Enabling SVM.”

0001BCFFis the value of EDX (0000 0000 0000 0001 1011 1100 1111 1111 in binary), and this shows a value of 0 for the SVML bit. This table is in Volume 3, page 617 (653).

So "F" in EDX register means it does support SVM lock.
So what should I do from here?

Only to get a sense for how much effort making a proper, fully-functional modification would take, I downloaded a copy of the appropriate manuals for my processor family (I have the AMD Turion TL-64) and perused it for steps to enable virtualization. These are:

• AMD64 Architecture Programmer’s Manual, Volume 2: System Programming
  
• AMD64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions
  

Page 447 (499 in Acrobat Reader) of Volume 2 contains a C snippet illustrating how to detect whether or not SVM can be enabled. I emulated the steps using Crystal CPUID to access the model-specific register and the feature flags.

For the step:

Code:

if (CPUID Fn8000_0001_ECX[SVM] == 0)

I have the values in the CPUID Information box:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
80000001 00060f81 000005a3 0000011f ebd3fbff

0000011f is the value of ECX (100011111 in binary), and this shows a value of 1 for the SVM bit. The table is in Volume 3, page 607 (643).

For the step (skipping the second step because we know no software is currently using SVM):

Code:

if (CPUID Fn8000_000A_EDX[SVML] == 0)

I have the values:

Code:

CPUID -- EAX ---- EBX ---- ECX ---- EDX ----
8000000a 00000001 00000040 00000000 00000002

00000002 is the value of EDX (10 in binary), and this shows a value of 0 for the SVML bit. This table is in Volume 3, page 617 (653). I understand this to mean that the Turion doesn't support unlocking SVM after the lock bit has been set. According to Volume 2, some architectures do support unlocking after the lock has been set by writing a 64-bit key into a register in the next segment or two prior to resetting the lock and SVM enable/disable bits.

The MSR address c0010114 is responsible for these states, and it has a value of 00000018 (11000 in binary). Volume 2, page 525 (577) shows what these bits are for; the bits SVMDIS and LOCK both being set confirms that the BIOS explicitly disables this feature in all cases and can't be altered by the MSR Editor or any other software.

I used the Phoenix BIOS Tool 2.5.6 to disassemble the NCWxx111.FD file into individual modules and examine the overall structure of the BIOS in an easy-to-read format. I've noted the layout of the driver modules and the various executables within, including one for the POST. While I haven't examined enough BIOSes to know whether or not I'm missing a large driver, I have a hunch that simply changing the data that is written into c0010114 to all zeroes would be sufficient to enable virtualization. It isn't as professional a hack as would be a full integration with the appropriate menu, but it provides the needed feature, and editing data is far less risky than altering any of the actual code.

I'm willing to continue poking around with this if any of the experienced members of this forum are willing guide me in this undertaking.