veatnik wrote:I have a Sony SZ370P with the same processor and same problem. (Rant: why they disable a key feature on a premium laptop I cannot understand. /Rant)
I suspect it's to simplify their support options, since VT is variable across individual models (in the FE41 range, only the "Z" suffix has a CPU with hardware VT).
veatnik wrote:I used to do this kind of system design/hacking a number of years ago but am a little out of touch as to what tools to use.
I downloaded all the integrated BIOS image-installers (.exe executable CAB files) from the Sony Japan FTP site (
ftp.vaio.sony.co.jp), and then use
cabextract to extract the BIOS image.
It goes something like this:
Code: Select all
$ ls
PHBSYS-01101528-UN.exe
$ cabextract PHBSYS-01101528-UN.exe
PHBSYS-01101528-UN.exe: library not compiled to support large files.
PHBSYS-01101528-UN.exe: library not compiled to support large files.
Extracting cabinet: PHBSYS-01101528-UN.exe
extracting PhlashNT.sys
extracting R0200J3.WPH
extracting WBFLASH.exe
extracting WBFLASH.SCR
extracting WinPhlash.exe
All done, no errors.
$ ls
PHBSYS-01101528-UN.exe PhlashNT.sys R0200J3.WPH WBFLASH.exe WBFLASH.SCR WinPhlash.exe
R0200J3.WPH is the binary image. WPH is the acronym for
Win
PHlash, the Windows BIOS utility Phoenix provide. You can feed this file into Phoenix BIOS Editor v2.2 (using Wine) and extract the individual modules, images, and relocation information.
veatnik wrote:So I just thought I should try it in the Sony first. Short story is that each of the memory banks correctly can use it as a full 2G module. The bad news is that if you put two 2G modules in, that the system will only see 3Gs of RAM.
Assuming this isn't a hardware limit (address lines tied to zero) then there are two configuration services I can think of that might enable the BIOS recognition of the additional memory:
- BIOS Interrupt 0x15 0xE820 function report (aka BIOS-e820)
- ACPI DSDT system memory maps (load a custom DSDT)
Do you get the same 3GB limit using a 64-bit operating system? I ask since 32-bit Linux will usually limit userspace to 3GB of RAM because the kernel relocates to the area above that.
veatnik wrote:What size are the Bios images on your FE?
If this is a partial image, what tool would you suggest I use to grab the bios image. (I primarily use Linux but will run XP if needed.)
The R0xxxJ3 BIOSs are 1 megabyte. I described above how I usually isolate them. You could read directly from /dev/mem but since a subset of the BIOS modules is paged into the traditional memory space (0xC8000-0x100000), you would have to identify the mapped location of the entire 1MB image and be sure it hadn't had any run-time fix-ups applied.
veatnik wrote:Let me know what I can do to help. In the meantime I'll work on getting tools and getting back up to speed. (If you have suggestions for specific tools that also would be appreciated. I'm happy to write a few tools (on linux only, prefer using LGPL) if you have any ideas for something useful that does not exist (on unix/linux).)
If you're interested in taking this further then I'd suggest a valuable contribution could be made by developing on my original idea to identify and use the NVRAM Token symbols. That work could be incorporated into a support library that other tools (such as my vt-enable) could call upon for symbolic access to BIOS settings.
It would provide all compatible Phoenix BIOS users with a safe method of interacting with their NVRAM settings using a generic tool. Currently it requires quite a bit of hacking (as you've seen) to identify even one Token with confidence.
From what I've seen so far it'd mainly be a big job of collecting older Phoenix BIOS images from all manufacturers and extracting the symbol tables and then deducing how to apply the information to newer BIOS images that don't contain those symbol tables (The DOS symcmos utility looks for them, and will use the symbols if available - ask me if you want my symcmos code notes). I started the quest but those symbol tables are rare so I suspended my search in favour of more productive hacking.
If it proves infeasible to do it that way, then it'll need a tool that extracts the BIOS modules and then parses them to identify which Token represents which function. My idea would be to do that once on the collected Phoenix BIOS images and create an array of lookup tables in the library code that uses DMI to obtain the running BIOS version and from that determines which entry in the table array matches the BIOS.
You could possibly build on my
SNC driver research in doing that.
Now I've got a mechanism to identify the specific NVRAM Token used to enable VT I don't intend taking the Token identification further since I've achieved what I set out to do.
I'll be releasing my vt-enable tool once the Ubuntu Gutsy release is over and I can relax for a while. Some polishing of libx86 has been done so I should be able to use it without a hitch now.