| Author |
Topic |
|
|
3963
85 Posts |
 Posted - 11 Nov 2004 : 11:30:03
|
Hi, Over here you note that you can roll a version of the CE image that contains custom drivers. Are there other options?
-Can the driver search path be augmented such that the OS looks in another folder (say, on flash) in addition to \windows?
-Can the loading of a particular driver subsystem (i.e. USB) be deferred (via registry keys) until files are copied?
The "Double Boot" method (on cold boot, copy files; then warm boot) is slow and, uh, inelegant, and I can see our drivers changing, so putting them in your build isn't ideal either.
Thanks... |
|
|
ctacke
877 Posts |
Posted - 16 Nov 2004 : 17:39:18
|
You can add additional paths to the system path through the registry. The only trick is that the key is a multi-sz, which ADSLOAD.REG doesn't yet support. ADSReg.exe does support them, so it's a viable alternative. See the Swedish Keyboard Driver ADSCopy install package example for an idea of how to set this up.
As for deferring loading of a driver, it can be done though setting the "Order" key for your driver. Lower orders load first.
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\MyDriver]
Order=dword:3
|
 |
|
|
3963
85 Posts |
Posted - 17 Nov 2004 : 14:28:18
|
Thanks for the reply.
So, I modded the system path to include our directory on the FlashFX Disk, and made the entries persistent. Again, the goal is to load our USB driver from Flash so we don't have to double-boot. After a cold boot, the USB driver is not loaded. The registry settings are still there. So, either I hosed the registry settings (unlikely?) or the USB subsystem is starting prior to the FlashFx drivers (which might make sense if one needed access to a USB disk when spawning something in the /FlashFX Disk/Startup folder).
The USB slave subsystem doesn't seem to use the standard driver keys that allow for the "Order" to be defined. So, what is the relative ordering of the USB Slave subsystem vs. the FlashFX drivers? Can it be changed via registry if I don't like the ordering?
Thanks again. |
Edited by - 3963 on 17 Nov 2004 14:30:00 |
|
|
|
ctacke
877 Posts |
Posted - 17 Nov 2004 : 14:45:06
|
| If you soft-reset (call restart.exe) does the driver work? |
|
|
|
3963
85 Posts |
Posted - 17 Nov 2004 : 15:00:02
|
Great question. Answer: No.
I just tried removing "\Release\" as the first entry in the system path, but didn't help. Hmm. |
|
|
|
ctacke
877 Posts |
Posted - 17 Nov 2004 : 16:20:48
|
| AH, so this might be the problem. How are you setting/editing the key? The key *must* be a MULTI_SZ, not a simple string, so the regedit.exe from Microsoft won't work, nor will ADSLOAD.REG. You have to use something like ADSReg.exe or the Remote Registry Editor tool in eVC. |
|
|
|
3963
85 Posts |
Posted - 17 Nov 2004 : 17:43:22
|
| Chris, I sent you mail with a screenshot of how I entered the keys via the Remote Registry Editor tool. |
|
|
|
3963
85 Posts |
Posted - 22 Nov 2004 : 11:40:02
|
| So, ignore a problem long enough, and it will go away! We spent some time on hardware (putting the board in a unit to minimize static electricity issues) and now the system path change works! I'm thinking it has to do with powering the board down, though in the past the reset button has been equivalent. On to new challenges... |
|
|
|
3963
85 Posts |
Posted - 23 Nov 2004 : 10:10:13
|
Update: It turns out that it only works intermittently. We have two usb devices; 0, 1, or 2 are registered on boot. I put in a debug version of our USB driver, and sure enough we only get 0, 1, or 2 "DeviceAttach" calls into our dll. Of course, this is only when running the dll from the FlashFx disk...
We're so close to avoiding the double-boot. Ideas? |
|
|
|
3963
85 Posts |
Posted - 10 Dec 2004 : 13:22:56
|
Per CTacke's suggestion, I tried setting the "Order" of [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SMIVGXUSB] from 1 to 9. (I also tried various other numbers). I had hoped that this would delay the USB host subsystem from starting up until after the FlashFX subsystem (Order = 2), and, hence, allow my custom dll to get reliably loaded on startup. Unfortunately, this did not help. I also tried making the FlashFX order = 1, but this caused the FlashFX disk to fail to enumerate -- evidently "1" is too early.
If I wait until the system boots, then connect our USB devices, they are reliably detected -- this would seem to support the conjecture that we are indeed working with some sort of race condition. So, either:
1) Changing the order of the OHCI driver (SMIVGXUSB) has no effect because of other keys (drivers/hid or drivers/USB?) or other OS dependencies
or
2)The race condition depends on something other than the OHCI driver.
Thoughts? Suggestions? |
|
|
|
3963
85 Posts |
Posted - 13 Dec 2004 : 13:21:13
|
More info: Looking at HKLM/Drivers/Active
01 ?
02 Drivers\BuiltIn\FLASH
03 Drivers\BuiltIn\SMIVGXUSB
04 Drivers\BuiltIn\InitReg
05 Drivers\USB\ClientDrivers\Hid_Class
06 Drivers\BuiltIn\WaveDev
07 Drivers\BuiltIn\FlashFx
.
.
.
12
Does the index in 'Active' indicate the order 'activated'? What is InitReg.dll? Is this where ADS applies the ADSLOAD.Reg registry deltas? If so, this would explain why I can't make the SMIVGXUSB have a higher 'Order'... |
|
|
|
ctacke
877 Posts |
Posted - 14 Dec 2004 : 17:50:27
|
| I believe the order in Active is the order in which the drivers actually loaded. InitReg is the driver that loads ADSLOAD.REG, so that may well be the problem. |
|
|
|
3963
85 Posts |
Posted - 13 Jan 2005 : 11:57:41
|
Success! I found a way to avoid the double-boot! Unfortunately, it's a bit, uh, inelegant. Basically, I 'bounced' the USB host driver after setting up my files, etc. The only USB clients we have are our custom devices, so this approach might be bad for folks who have other USB clients (mice, keyboards, mass-storage, etc).
Ideally, there would be some API to grab the device handle of the (Active) USB Driver (SMIVGXUSB) programmatically. It looks like CE 5.0 will have such an API. CreateFile could do it if I knew the "$bus" name, but I don't. I also went down the "RequestDeviceNotifications" path, but this only gets you the name of the device; but I already know that. So, until I can find an API (and to see if this was worth pursuing), I reached into the registry and took what I needed. Basically, I walk through the HKLM\Drivers\Active entries and look for "HCD1", then grab the "Hnd" (device handle), and call "DeactivateDevice" on the DeviceHandle, then "ActivateDevice". It looks like I need to give the driver time to enumerate the USB bus before kicking off my program, so this is where "RequestDeviceNotifications" might come in handy.
So, if someone knows a more elegant way to get to the device handle for the USB Host driver, I'm all ears! |
|
|
|
3963
85 Posts |
Posted - 17 Jan 2005 : 11:20:03
|
| Well, qualified success. This approach appears to cause system instability, probably due to yanking resources out from under DeviceManager? I played with several more refinements, but the system would hang during boot 20% of the time. There may be potential in this approach, but since it isn't using 'correct' APIs, and I don't have visibility / control into what's going on in the DeviceManager, I'm heading back to the Platform Builder / BSP approach. |
Edited by - 3963 on 17 Jan 2005 18:19:47 |
|
|
|
3963
85 Posts |
Posted - 17 Jan 2005 : 18:19:13
|
OK, I have something that works. I assume that the boot order of the drivers got tweaked sometime prior to the latest (4.20.22) release -- the USB host driver (aka SMIVGXUSB & HCD) is now _after_ the InitReg. This allows the following:
1) Use an ADSLOAD.reg to set a "Flags" value on the SMIVGXUSB key to 4. The documentation for ActivateDeviceEx indicates this is the value for "Don't load this driver".
2) In your ADSLOAD.exe, copy your usb drivers from flash to RAM, and call ActivateDevice on the SMIVGXUSB key.
3) Either wait a bit for the driver to enumerate the bus, or use RequestDeviceNotifications.
4) Run your application. |
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Loading a custom USB driver at boot
Forum Locked
Send Topic to a Friend
Printer Friendly