Skip to content

Category: dsdt

1

Published on 1 Comment on WMI is a dead end

Just as a quick update, we've tried yesterday to get access to the device specific methods of the both graphics cards through the WMI interface wrapper, but it failed. Some methods of the WMI wrapper work, but there's a stupid bug in the DSDT program that prevents executing the really interesting stuff. For the technically interested ones, this is the head of the 'WMMX' method in device WMI1:


  Method (WMMX, 3, NotSerialized)
 {
   CreateDWordField (Arg2, Zero, FUNC)
   ...

Further down we find this:


   If (LEqual (FUNC, 0x4D53445F))
   {
     CreateField (Arg2, Zero, 0x80, MUID)
     CreateDWordField (Arg2, 0x10, REVI)
     CreateDWordField (Arg2, 0x14, SFNC)
     CreateDWordField (Arg2, 0x18, PARM)
     If (LEqual (Arg1, 0x10))
     {
       Return (^^OVGA._DSM (MUID, REVI, SFNC, PARM))
     }

This code block just splits Arg2 of method WMMX into sub arguments and calls the '_DSM' method of the built in graphics adapter. But there we find:


  If (LNotEqual (Arg0, Buffer (0x10)
  {
    /* 0000 */    0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D, 
    /* 0008 */    0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4
  }))
  {
    Store (0x80000002, RBUF)
    Return (Local0)
  }

So, the code in WMMX copies the first 128 bit of Arg2 into MUID, which in '_DSM' is compared to the byte array above. But wait, isn't FUNC also created by copying a DWORD from the start of Arg2? Hmmm. So, obviously the start of Arg2 cannot contain the function signature ('_DSM') and a MUID starting with 0xa0, 0xa0, 0x95 ... Consequently, every access to this method fails and just returns 0x80000002 to the caller. This part of the ACPI DSDT is just broken.

Now, obviously this is not the path Vista is using, unless they are replacing the original DSDT with something that works (and I cannot believe that). Maybe through a BIOS update? Does anybody know about graphics card related problems with Vista that are solved through a BIOS update? Or can some kind soul provide a DSDT dump while the system runs Vista?

Anyway, I'll continue my quest over the weekend, weather will not be good anyway. I think it should be possible to access the _DSM method of the chipset graphic card directly using its path, via acpi_evaluate_object(). We're going to try that next, stay tuned.

1

Published on 1 Comment on Success: Sony Vaio VGN-Z21 3G modem with Linux!

I'm happy to report that my hack to the sony-laptop kernel module works. We were able yesterday to make the first UMTS data connection with my wifes' Z21, using HSOconnect on openSUSE 11.1. Her detailed description of installing openSUSE 11.1 on the Z21 can be found here, you can also download the source code of the sony-laptop.ko. It's a very rough first version, don't expect packages or inclusion into mainline kernels soon. Still, it gets you where you want.

Loading the module will generate a new file /sys/devices/platform/sony-laptop/snc_wwanpower, you can switch the modem power with "echo 1" and "echo 0".

I'm still working on the graphic card problem, hopefully I'll have a solution soon.

1

Published on 1 Comment on Sony Vaio Z21 DSDT fun

My wife urged me today to work on her new Sony Vaio Z21, which is, as anyone able to use Google will know, not particularly well supported by any recent Linux distribution. This is not exactly due to the completely fancy hardware components, rather by the completely undocumented methods of how to switch them on and off.

As an example, the Z21 has a builtin 3G modem, an Option Globetrotter, which is connected to an internal PCIe slot, which means it should just show up on the USB bus. Unfortunately it does not, not under Linux at least. The reason is that Sony chose to switch the modems power supply through an embedded controller chip on the motherboard. This embedded controller is nonstandard and therefore not managed through standard ACPI methods you would find under /proc/acpi, however there is a small kernel module, sony-laptop.ko, which provides an interface to some of the Sony proprietary device functions. The Z21 is unfortunately not supported yet by this module.

Well, it was not difficult to make the module detect the Z21, but the fun just started at this point: None of the functions provided by this module worked. Nada. Zero. OK. Turned out that while the Z21 contains the same "Sony Notebook Controller" as other Vaios, it did not react to any of the known ACPI method calls. So, I started looking deeper into the DSDT. I had never done that in depth before, but looking at the decompiled DSDT ASL, knowing that the DSDT is really not a table but rather byte code, it wasn't difficult to understand that the "SN07" method of "SNC" device was the key to switching the modem on and off. After traversing several levels of If/Else statements I found that calling "SN07" with 0x9f070803 as argument switches on the 3G modem, while 0x00000803 turns it off again.

Unfortunately this is not the end of the story. While the modem is now accessible via USB and even recognized by the hso.ko driver module, and even while we're able to talk AT commands via ttyHS0, we have yet to make the first data connection.

The biggest challenge will however be to understand the weird inner workings of the graphics adapters. The Z21 has two of them, an Intel GM45, and and some Nvidia with a name that I currently cannot remember. Under Vista you can dynamically switch between them, and unfortunately the BIOS lacks any preset, so when you cold boot into Linux, both of them are active which completey confuses the drivers and disables direct rendering. I know the answer is somewhere inside the DSDT devices and methods, but it's hard to understand this from reading the disassembled bytecode, without comments or sensible variable names.