I certainly wanted to use a feature that I paid for, so I started investigating the BIOS and here’s what I found out.

Update: There’s a 1.21 BIOS floating around that seems to have VT enabled natively. See below.

Under the hood

The InsydeH2O BIOS is no ordinary old-style BIOS. Instead, it’s based around the UEFI platform. This goes way beyond the old BIOS paradigm and turns system firmware into practically its own separate OS, that even runs in full 64-bit mode on 64-bit machines. Unfortunately, they make no effort to expose any of this to the user. The firmware has support for booting EFI executables, there’s an EFI shell, there’s an EFI boot manager… but I haven’t been able to figure out how to access any of this.

If you want to reverse engineer EFI stuff, downloading TianoCore’s EDK2 is a must. It contains source code for a lot of Intel’s framework, which is what most vendors use as a base for their EFI support. A lot of the code is exactly the same as what’s in the Insyde BIOS (read the spec here).

As for the Setup tool, it does indeed have a huge Advanced menu with even more options than your average desktop. There’s also a hidden Power menu. EFI defines a “form browser” protocol and formats for user input, which is what Insyde uses for their setup utility (spec here). I found these tables when disassembling the Setup binary and wrote a little dump utility to turn them into text. The result is a complete dump of the Setup hierarchy, including the Advanced menu, which also includes the offsets in the non-volatile storage corresponding to each setting. Insyde stores this configuration blob into an EFI variable named Setup. Here’s my dump: the first part is the hierarchy, while at the end I added a rough auto-calculated mapping from configuration offsets to setting names (grep for [0xOFFSET in the top section for better context - the format is [0xOFFSET<FIELD_WIDTH>] for all references to the storage blob). You’ll find the tools I used here, if you’re interested, but they’re rough and need quite a bit of manual help too.

I wasn’t able to find out how to enable the hidden menus, other than that their form Subclass is 5 instead of 0 (but I haven’t found what, if anything, checks for this and whether its behavior can be altered). However, manually enabling VT support in the Setup variable is easy enough, now that we have the offset of the VT Enable byte.

Enabling Intel VT

The easiest way to enable the setting as far as I can see is to dump out the entire BIOS, patch the setting into the Setup variable (which is part of the data storage section – we aren’t modifying any actual BIOS code, as this is the equivalent of changing a CMOS setting on other BIOSes), and then flash the resulting image. These laptops use a weird flash-behind-EC hardware solution for which there is no open flasher, so instead we can just use the normal BIOS flashing tool. In short, we’ll flash the existing BIOS back on, but in the process also modify a Setup setting.

FAIR WARNING: This might apply to other similar laptops, or it might not. It might work, it might do nothing, or it might brick your expensive laptop. Even if you own an Aspire 8930G, I take no responsiblity if your laptop dies, turns into an expensive brick, melts into a pool of slag, blows up, flicks you off, develops self-awareness, or becomes Skynet. You have been warned. I have only tested this on an Aspire 8930G with BIOS Version 1.10. If you want to try this on another system or BIOS you should make sure you understand EXACTLY what is going on and are prepared to spot any problems or fix things yourself.

First, dump the exiting BIOS out. It resides at the top of the 32-bit address space, and is 2MB in size. You can use dd to dump it out of /dev/mem:

$ dd if=/dev/mem of=original_bios.fd bs=1024 count=2048 skip=4192256

It is a very good idea to back up this BIOS somewhere safe outside the laptop. Note that it not only contains your existing BIOS code, but also all your settings and manufacturer data (serial number, software license if you run an OEM version of Vista, etc).

Next, run vtenable.py. This will attempt to locate the Setup EFI variable on the non-volatile storage section and patch the VT byte to one.

$ python vtenable.py original_bios.fd vt_bios.fd

You can edit the source code to make other changes to the variable, but make sure you know what you’re doing. It’s worth reiterating that this does not patch your BIOS code. It only makes a setting change, just as if you’d turned on the VT option in the BIOS had it been there. In fact, there are two variables: Setup and Custom, and Setup is the one that changes are committed to when you use the setup utility. Restoring defaults should turn VT back off (untested). It also appears that Custom is probably what the setup defaults are, so changing that should semi-permanently enable VT.

I highly recommend performing a sanity diff between the original and modified images using vbindiff:

$ vbindiff original_bios.fd vt_bios.fd

Only two or three bytes should change: one or two adjacent bytes for the checksum (they should be decremented by one when you look at them as a 16-bit unsigned integer), and the VT enable byte should change from 00 to 01. Right after the checksum bytes you should be able to see the Setup name in UTF-16 (something like S.e.t.u.p.).

Finally, flash vt_bios.fd using the vendor-supplied flash utility. I use the DOS version (FLASHIT.EXE) with FreeDOS and a grub menu option so I don’t need to mess around with external media. Grab a base image here, then you can use mtools to copy the bios into it:

$ bunzip2 freedos_flashit.img.bz2
$ mcopy -i freedos_flashit.img vt_bios.fd ::/vt_bios.fd

To boot it using GRUB, get MEMDISK, part of SYSLINUX, and put something like this in your grub.conf:

title=BIOS Update
root (hd0,0)
kernel (hd0,0)/boot/memdisk
initrd (hd0,0)/boot/freedos_flashit.img

Of course, copy memdisk and the boot image to your boot partition, and change (hd0,0) to your boot (or root) partition everywhere and remove the /boot part if you have a dedicated boot partition.

Once you’re in FreeDOS, just type FLASHIT vt<tab> and be happy that FreeDOS supports tab-completion

Caveat: by doing this, you’re flashing the entire BIOS image. The flash tool makes no attempt to flash only the parts that changed, and the “flash only variables” commandline option seems to have no effect. You’re effectively reflashing your entire BIOS back on, so the usual BIOS flashing caveats apply: don’t turn the power off, etc. This could be accomplished a lot more cleanly if we had drivers for the flash chip / EC, since then we could use the normal EFI variable store procedure to atomically update the variable, which is completely safe.

You can use the MSR Magic tool to check whether VT is indeed enabled on your CPU.

Update: Several people are working on improved, more general tools to perform this hack across a broader range of InsydeH2O-based BIOSes. Read the comments and check them out, they’ve done some very good work.
Update 2: There’s a 8930G 1.21 BIOS version floating around (not on Acer’s site yet) with build date 3/3/2011. This version seems to have VT enabled without any hacking required (I’ve checked the contents and everything seems to be kosher and a real update, not some hack). I haven’t come across an official update file, but I did find a dump made by someone. I’ve manually cleaned it up to remove the variables and serial numbers so it should be identical to an official 1.21 update file (it will keep your current config and serials). You can find it here.

This laptop is peculiar because it has built-in “5.1″ audio. Yes, it does really have 6 speakers, though you’d be hard pressed to get much spatial separation out of them (and they aren’t even placed around symmetrically). However, the speakers do end up making a very decent multiway audio system, by laptop standards: the “rear” pair (which is actually between the keyboard and the screen; the mind boggles) is good with the high end, the “front” and center speakers (front edge of the laptop) are your average mediocre speakers that can handle mid-end, and the “Tuba” not-so-”sub” woofer fills in enough low-end to equal a decent overall speaker, although of course with zero stereo/spatial separation since there’s only one of it (actual subwoofers can pull off mono because the human ear can’t really hear spatial position at low frequencies, but the Tuba is more like the only non-sucky speaker in the entire laptop).

What this boils down to is that you really want good audio support for all 6 speakers if you want to take advantage of the audio capabilities at all. Most importantly, stereo needs to be upmixed and a good portion of the normal audio needs to be routed to the Tuba. ALSA’s asound.conf makes this easy, assuming the actual hardware works fine. Of course, that’s not the case.

This thing uses (of course) Intel HDA audio with a Realtek ALC889 codec. This codec is fairly new and support is of course still a bit sketchy. There are two parts to getting things to work: the software needs to know how to talk to the ALC889 codec, and it also needs to know how to configure it to work with the laptop’s hardware design (i.e. how the chip’s outputs connect to the actual speakers and jacks, which varies). After reading up on HDA audio codec specs and looking for examples, the latter part wasn’t very hard. There’s even a tool called hda-analyzer which lets you tweak most HDA configuration on the fly with a nifty GUI. I also rendered a graph (warning: large image) of the codec’s internal audio routing.

Unfortunately, after verifying that I had mapped all of the connections properly and could get individual output through any one of the speakers and audio jacks, I hit a showstopper. The codec has 5 stereo DACs (10 channels total, nominally 7.1 plus an extra stereo connection) but only the first two DACs worked, which gave me 4.0 audio. They rest just appeared to be completely dead. I knew the problem was with the DACs because I could remap the audio outputs to use one of the first two DACs and that worked, and I could tell the first two DACs to play other channels from the input stream and that worked fine too. Audio was getting to the chip, and audio could get out from the chip, but somewhere during the digital-to-analog conversion for DACs 3-5 it was just disappearing. I searched the Realtek datasheet and ALC specs for info on how to turn DACs off or on but found no such thing. Of course, a standard wouldn’t be complete without a mechanism for vendor-specified proprietary extensions (and those standards that don’t have them are abused anyway). HDA has these things called coefficient registers, which is just a dumb name for vendor proprietary registers. ALSA already has some code to tweak these on other Realtek codecs, though nothing related to turning DACs on or off. At this point this was clearly Realtek’s fault for not documenting how to turn on DACs that are turned off by default. So I e-mailed them describing the issue in clear terms, and, in response, got treated like a clueless end-user. They kept sending me patched/modified versions of the realtek support for ALSA with useless changes like support for new laptops and the like and no actual changes to fix the DAC issue. Of course, none of it was helpful, and I gave up on playing along after a couple weeks of wasted time.

Eventually this annoyed me enough that I just desperately tried flipping every bit in every coefficient register. After about 45 minutes of mind-numbing tones (I made a little multichannel test tone using a pentatonic scale which looped a couple thousand times until I was done) I didn’t find the magic bit to turn on the DACs, but I found two registers able to kill the already-working DACs, guessed a bit, and found out that you need to clear both of them to enable the broken DACs. Success.

Long story short, this, along with proper support for the laptop’s hardware and such, should be in the next version of ALSA. If you’re impatient, grab this patch and apply it. The one thing that’s missing is internal mic support (it’s in there but I don’t think it works) – I tried a few things and came up dry, but I don’t really plan on using it anyway. You’ll also want an asound.conf to do the upmixing: this is what I use. Just place it in /etc (back up / merge your distro’s version, if any, before you overwrite it!).

Lastly, if you have another Acer laptop with similar audio capabilities, the code will probably work for you but it won’t autodetect the laptop. You’ll want to use the option “model=acer-aspire-8930g” when loading the snd-hda-intel module to force it. For example, it’s very likely that it will work with the 8920G. If it works, send the output of “lspci -v” or “sudo lspci -v” to me or an ALSA developer so it can be added to the list.

Update: I submitted another patch to fix input issues. This gives you the full 3 capture devices, one of which can capture the internal front microphone (the others can’t; that’s a chip limitation). The microphone is stereo but due to the weird sum/difference format I’ve hacked it to just output mono to the device. The stereo is useless anyway, since the mics are too close together. Grab the patch here.