For Vista / Win7 64bit editions, driver files (.sys) must be signed to even
load.
Signing the .inf tells the user that the driver has gone thru some testing to
insure some quality.
For WinUSB, Microsoft already signed the .sys portion for us. You only have to
customize the .inf.
If you do not sign the .inf, you will receive a "This driver has not been
signed/tested/blabla by manufacturer blabla".
But it will still work.
Signing of .inf is not necessary, only ideal.
________________________________
From: Dominic <dominic.r...@gmx.de>
To: openocd-development@lists.berlios.de
Sent: Friday, 26 June, 2009 17:35:41
Subject: Re: [Openocd-development] ftd2xx -> libftdi
On Friday 26 June 2009 18:10:56 Xiaofan Chen wrote:
> > o libftdi apparently works with libusb-win32's API (see for example
> > Freddie's post)
>
> Yes.
>
> > o libusb-win32 comes with 3 (maybe 4) backends
> > - a libusb driver and a libusb filter driver (not sure if this
> > differenciation is still correct)
> > - a HID backend (I've seen something like that with Keil's ULINK I guess,
> > which looks like a HID to Windows, and thus needs no driver)
> > - a WinUSB backend
>
> This is libusb-win32 1.0 branch. Unfortunately it is not working yet and I
> do not know when the author will get time to get it working. Several people
> suggested WinUSB backend to fix Vista 64 issues. I suggested the
> HID backend since there are issues to use libusb-win32 with HID device.
Is the libusb-win32 1.0 branch compatible with libftdi (i.e. is it compatible
with libusb 0.1)?
> > o libusb-win32's drivers are supposed to be a dead end because they wont
> > work with 64-bit windows (and probably not with Windows 7), but they do
> > work for older versions that don't have WinUSB support (particularly
> > 2000... leaving 98/ME behind doesn't sound overly disturbing to me)
> >
> > o the FTDI chips are not HID, so the HID backend is dead for our purposes
>
> The HID backend is for other device. There are many HID based device.
> Typically we use native HID API to access HID device. But many programs
> use libusb to access HID device under Linux.
Not sure if I understood you correctly here - the HID backend is for HID-class
devices, right? Specifically it is not for the FTDI chips?
> > o the WinUSB backend brings a WHQL signed driver, which is good, because
> > it runs on all windows versions that required signed drivers (Vista
> > 64-bit, Windows 7)
> >
> > o The WinUSB How-To says that you need to get the whole driver package
> > including the .inf file signed. Some postings to newsgroups suggest that
> > this is not necessary. It might be that you get a warning, which
> > shouldn't be that much of a problem.
>
> It is ok to load the driver even though there is a warning.
Is this true for all existig and upcoming Windows versions?
> You can do
> the same with libusb-win32 device driver if somebody can pay the
> digital signature (not so expensive). One company already got their
> libusb-win32 based device driver certified by WHQL but they
> renamed all the driver name to their own name.
You seem to know the signature and WHQL stuff. As I understand it there are at
least two issues:
- WHQL certification for the driver (.sys)
- Signature for the driver package (.cab), including the .inf file that will
need to be modified whenever we add a new VID/PID
I'm not sure if WHQL certification and the driver signature are the same thing?
Does digital signature mean for example a VeriSign issued signature? Would
Windows accept self-signed signatures? Can we create root certificates of our
own for this purpose?
I dislike the idea of paying for any of this because because some of these
costs might be recurring (digital signatures might expire?), and because it
would mean the project would have to cover costs for mostly commercial dongles.
> > o libusb-win32's development seems sporadic if not stalled
>
> You can say it is stalled right now since the SVN is 22 months old.
>
> > Conclusions
> >
> > + libusb-win32 would be good, because it works on all present windows
> > platforms, and because it's supposed to work on upcoming versions, too
> >
> > + libusb-win32 would be good, because it allows us to use libftdi, which
> > implements all the FTDI-chip specific USB communication. Using the
> > information available in libftdi wouldn't be much of a problem, but it's
> > certainly a lot of coding work that is mostly unrelated to OpenOCD
> >
> > - I have no idea about how stable and reliable libusb-win32 is
>
> Based on my experiences it is quite good. The filter driver can cause
> many problems (including serious BSOD and lost of all USB device)
> and is no longer recommended by the author. The device driver has
> never caused problem for me.
The advantage of the filter driver is that it runs in parallel with other
installed drivers, e.g. FTDI's D2XX, right?
> > o (Re-)writing libftdi with plain WinUSB should be possible and would
> > remove the uncertainties of libusb-win32, but would burden the OpenOCD
> > project with the task of keeping it stable and up to date. It would also
> > leave out Windows 2000 and before.
>
> You can always use libusb-win32+libftdi for Windows 2k.
Having to maintain multiple different Windows drivers puts a pretty heavy
burden on the Windows packagers.
> If possible, some people with Windows knowledge can look
> at the libusb-win32 1.0 branch to judge how mature (or im-mature)
> it is.
>
> WinUSB is a good solution with or without libusb-win32. If libusb-win32's
> WinUSB backend can be made to work, it is of course better since it
> will benefit other open source projects as well. But a WinUSB based
> solution specific to OpenOCD (for FTDI) device may be easier.
Regards,
Dominic
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
