The latest 64-bit version of most vendor's drivers now work fine without following these instructions or using GobiLoader. I updated my Thinkpad to Win7 Retail x64 using Lenovo System Update to install all the drivers and now my Gobi card works great even after a sleep/hibernate.</Update>
I have been surprised by the extremely small number of compromises that I've had to make after installing Windows 7. One of the more painful for myself however is the problem with support for my laptop's internal WWAN card which is based on the Qualcomm Gobi chipset. It looks like this chipset is used on some HP laptops as well as my Lenovo Thinkpad (W500) and my Boss' X301 for both Verizon and/or AT&T. This chipset is new from Qualcomm and is supposedly a global radio supporting any provider on both CDMA and GSM by using a dynamic firmware capability.
During the time of the Windows 7 beta and now the recent RC1 there have been some rumblings from people that need this support to be able to use Windows 7 full-time. Reading through the posts and trying to get this to work I've found there to be two blocking issues getting this card to work, the first is getting the drivers to install on Windows 7, and the second is getting the dynamic firmware to load onto the card.
Installing the DriversThe problem with installing the drivers is caused by a library that Qualcomm uses to support the installation called difxapi. The supporting DLL for this API is included in the installation package and it conflicts with the Windows 7 version, this conflict causes a custom action in the installation routine to fail and forces a rollback of the installation.
To fix the problem we need only to replace this DLL with the one from your Windows 7 installation. If you don't have it already you need to download the driver installation package from your laptop manufacturer's support site and extract it somewhere.
Starting from where you unarchived your package look for a directory similar to "\Driver\Source\Module Retargetable Folder\QCUSB-Lenovo\DriverPackage\Microsoft\DIFxAPI". Now you just need to replace the difxapi.dll here with the one from "c:\windows\system32". If you are running 64-bit Windows then copy the DLL into the amd64 subdirectory, for 32-bit installations copy the DLL into the x86 directory, if you're not sure you can safely copy it into both directories.
Once you replace this DLL the setup.exe under the "Driver" directory should now run successfully. Once the installation finishes verify that you have the "QCUSB-*" and "QDLService" directories under "c:\QUALCOMM".
Loading the FirmwareI've somewhat mimicked two Linux programs and wrote a tool called GobiLoader for Windows 7 that is able to successfully load firmware onto the card for any of the supported wireless providers (see More About the Firmware for more info).
Since the Qualcomm service is not able to load the firmware properly we will need to disable it so that it doesn't conflict with GobiLoader. Bring up the "Services" control panel and in the list of services find the one labeled "Qualcomm Gobi Download Service". Double click the service to bring up the properties, if it is running click the stop button; to disable the service change the "Startup type" drop down to "Manual" and click "OK".
Before you use GobiLoader you will need to verify that the proper firmware files will be loaded. To find the proper firmware files you can take a look at the Qualcomm Download Service log file on your Vista installation. The log file is called "QDLService.txt" and can be found under the "C:\Users\All Users\QUALCOMM\QDLService" directory. Open the log file and verify the path to the firmware files that it is loading, you will see something like this:
05/06/2009 03:50:47.938 20 70 72 6F 74 6F 63 6F 6C 20 74 67 74 04 00 F0 05/06/2009 03:50:47.938 CB 04 04 00 00 00 00 00 00 00 00 00 00 00 00 00 05/06/2009 03:50:47.938 30 05/06/2009 03:50:47.938 QDL sending image file: C:\QUALCOMM\QDLService\Packages\1\amss.mbn 05/06/2009 03:50:47.938 QDL protocol server request sent 05/06/2009 03:50:47.938 0002 [9 05/06/2009 03:50:47.938] 05/06/2009 03:50:47.938 25 05 68 48 4E 00 01 00 00 00 04 00 00
The number '1' in the firmware path (C:\QUALCOMM\QDLService\Packages\1\amss.mbn) in this case is the ID for the firmware that my Vista installation was successfully using. Your number may be different depending on who your wireless provider is (AT&T, Verizon, Sprint).
Remembering the firmware number go back to Windows 7 and under the same "C:\Users\All Users\QUALCOMM\QDLService" directory open the "Options.txt" and verify that it is pointing at the correct firmware. After I installed the Qualcomm drivers on Windows 7 it was pointing at the wrong firmware so I had to manually correct the path. GobiLoader reads this file to load the correct firmware, so be sure it is correct or your card will not work. GobiLoader also assumes that the "Options.txt" file is located at "C:\Users\All Users\QUALCOMM\QDLService"; and it relies on the registry to detect which COM port that the QDLoader device is listening on.
Once you have everything in order you can simply run GobiLoader.exe and watch for a successful upload. Once the upload has happened you should see your WWAN modem become available.
You will need to run GobiLoader after any time that you shutdown, sleep, or hibernate your laptop.
More About The FirmwareGlancing at the firmware files I noticed that they had an ELF header, and running 'file' on them evoked this:
amss.mbn: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped
It seems that the Qualcomm Gobi chipset runs embedded Linux on an ARM processor, and the firmware files are simply executable programs. When the firmware files are uploaded they are being copied into RAM and then run just like any other Linux program. Since these programs are in RAM they are lost every time the card gets power-cycled (including during sleep or hibernate) and the card reverts to a blank slate.
In its blank state the card's built-in firmware exports a single USB serial port device -- called HS-USB QDLoader -- to the operating system, this port is used solely for the upload of the firmware files to the card. You can think of this built-in functionality as something like a bootloader.
I find this design rather ingenious, since the running firmware programs are simply Linux executables they've opened up the pool of capable developers considerably. Qualcomm should be able to be quite agile in fixing bugs and adding features since the developers can write user-mode programs, where most firmware is either bare metal or kernel-mode code. As the power of embedded processors grows I expect to see solutions like this become more common.
Once the firmware has been loaded, the QDLoader device goes away and the modem's other ports attach to the system; these devices appear in the Windows device manager.
[caption id="attachment_92" align="alignnone" width="549" caption="Gobi Devices After Firmware Load"][/caption]
The laptop manufacturer's driver package installs a Windows service called "Qualcomm Gobi Download Service", its job it is to upload these firmware files to the card after every power-cycle. Thanks to Alexander, Sergey and Mathew I was able to work out how the Download Service actually interacts with the card.
The FutureI don't know how responsive Qualcomm is, so I don't know how quickly these issues will be resolved; I would hope that as the Windows 7 release looms near that they will be prioritizing support. If these problems are not fixed soon then I will probably package GobiLoader up into a service that watches for the QDLoader port to load the firmware on-demand.
I'm also working on a post describing the handshake protocol in detail based on what I was able to gather from other code, protocol traces, and trial-and-error. Hopefully this detailed information can be useful in making the Linux support more robust, which -- for me -- is useful when firing up my Ubuntu partition.
I've cleaned up the source code and you can grab it here if you'd like to take a look or modify it. GobiLoader Source