• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 869 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EK-TM4C1294XL: Do the USB Drivers from the TI-RTOS USB Serial DFU project run in Kernel or User Mode?

Tom van Rijn
Prodigy 60 points
Part Number: EK-TM4C1294XL

Hello,

I am using the unsigned USB drivers provided with the TI-RTOS USB Serial DFU project, see code below.

The files enumerate two devices, a runtime usb dfu device and a cdc serial device.

I have tried to find out if the drivers run in kernel or user mode.

If I am not mistaken, when a .sys file is used, as is the case (WinUSB.sys and usbser.sys), they run in kernel mode.

On the other hand, the driver description says

[...] All this file does, therefore, is ensure that the DFU drivers and WinUSB subsystem are installed to support switching from DFU runtime mode into "real" DFU mode in preparation for download and upload operations.

Since I need to purchase a certificate to be able to sign the drivers for Windows 10, I need to know if I need to purchase an extended validation certificate (kernel and user mode) or if just a regular certificate (only user mode) will do.

I tried finding answers on the Windows Hardware Dev Center but it left me quite confused.

Can anyone help me out for these drivers specifically or better yet, how to identify if a driver runs in kernel or user mode when only the .inf file is available? It is greatly appreciated.

Full unmodified driver files for reference:

; -----------------------------------------------------------------------------
;
; TivaWare USB DFU Runtime device driver installer
;
; The composite devices supported by this INF file contains a HID mouse with
; a Device Firmware Upgrade runtime interface (basically, just a stub that
; tells the host that the device supports DFU).  Since HID is supported
; natively by Windows, no HID-specific sections are required here.  All this
; file does, therefore, is ensure that the DFU drivers and WinUSB subsystem
; are installed to support switching from DFU runtime mode into "real" DFU
; mode in preparation for download and upload operations.
;
; This device offers DFU on interface number 1 and publishes PID 0x0A while in
; runtime mode.  When it is switched to DFU mode (implemented by the boot_usb
; boot loader), the device reenumerates and publishes PID 0xFF instead.  This
; is seen as a different device by Windows and requires a second INF file to
; support it.  This INF file is boot_usb.inf which installs exactly the same
; files as this one.
;
; -----------------------------------------------------------------------------

; NOTE: When you customize this INF for your own device, create a new class
; name (Class) and a new GUID (ClassGuid). GUIDs may be created using the
; guidgen tool from Windows Visual Studio or the Windows SDK.

[Version]
Signature = "$Windows NT$"
Class = USBLibDFURuntimeDeviceClass
ClassGuid={0D42186B-31A8-4800-B875-1A5525A407B9}
Provider = %MFGNAME%
DriverVer=12/15/2015,2.1.1.71

; ========== Manufacturer/Models sections ===========

[Manufacturer]
%MFGNAME%=USBLibDFUDevice_WinUSB,NTx86,NTamd64

; NOTE: Replace the VID and PID in the following two sections with the
; correct values for your device.

[USBLibDFUDevice_WinUSB.NTx86]
%DESCRIPTION%=DFU_Install,USB\VID_1CBE&PID_0102&MI_02

[USBLibDFUDevice_WinUSB.NTamd64]
%DESCRIPTION%=DFU_Install,USB\VID_1CBE&PID_0102&MI_02

; =================== Installation ===================

[ClassInstall32]
AddReg=AddReg_ClassInstall

[AddReg_ClassInstall]
HKR,,,,"%DeviceClassDisplayName%"
HKR,,Icon,,-1

[DFU_Install.NTx86]
Include=winusb.inf
Needs=WINUSB.NT
CopyFiles=System32_CopyFiles

[DFU_Install.NTamd64]
Include=winusb.inf
Needs=WINUSB.NT
CopyFiles=SysWOW64_CopyFiles
CopyFiles=System64_CopyFiles

[DFU_Install.NTx86.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall

[DFU_Install.NTamd64.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall

[WinUSB_ServiceInstall]
DisplayName     = %WinUSB_SvcDesc%
ServiceType     = 1
StartType       = 3
ErrorControl    = 1
ServiceBinary   = %12%\WinUSB.sys

[DFU_Install.NTx86.Wdf]
KmdfService=WINUSB, WinDFU_Install

[DFU_Install.NTamd64.Wdf]
KmdfService=WINUSB, WinDFU_Install

[WinDFU_Install]
KmdfLibraryVersion=1.9

[DFU_Install.NTx86.HW]
AddReg=Dev_AddReg

[DFU_Install.NTamd64.HW]
AddReg=Dev_AddReg

; NOTE: The following GUID is used by software that accesses USBLib DFU
; devices (dfuprog and LM Flash Programmer). If you want your device to be
; accessible by these tools, do not change it.

[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{D17C772B-AF45-4041-9979-AAFE96BF6398}"

[DFU_Install.NTx86.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[DFU_Install.NTamd64.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"WdfCoInstaller01009.dll,WdfCoInstaller","WinUSBCoInstaller2.dll"

[CoInstallers_CopyFiles]
WinUSBCoInstaller2.dll
WdfCoInstaller01009.dll

[System32_CopyFiles]
lmusbdll.dll
lmusbdll.lib
lmdfu.dll
lmdfu.lib

[System64_CopyFiles]
lmusbdll.dll, lmusbdll64.dll
lmusbdll.lib, lmusbdll64.lib
lmdfu.dll, lmdfu64.dll
lmdfu.lib, lmdfu64.lib

[SysWOW64_CopyFiles]
lmusbdll.dll
lmusbdll.lib
lmdfu.dll
lmdfu.lib

[DestinationDirs]
CoInstallers_CopyFiles=11
System32_CopyFiles=10,system32
SysWOW64_CopyFiles=10,syswow64
System64_CopyFiles=10,system32

; ================= Source Media Section =====================

[SourceDisksNames]
1 = %DISK_NAME%,,,\i386
2 = %DISK_NAME%,,,\amd64

[SourceDisksFiles.x86]
WinUSBCoInstaller2.dll=1
WdfCoInstaller01009.dll=1
lmusbdll.dll=1
lmusbdll.lib=1
lmdfu.dll=1
lmdfu.lib=1

[SourceDisksFiles.amd64]
WinUSBCoInstaller2.dll=2
WdfCoInstaller01009.dll=2
lmusbdll.dll=1
lmusbdll.lib=1
lmdfu.dll=1
lmdfu.lib=1
lmusbdll64.dll=2
lmusbdll64.lib=2
lmdfu64.dll=2
lmdfu64.lib=2

; =================== Strings ===================

; Note: Replace these as appropriate to describe your device.

[Strings]
MFGNAME="Texas Instruments Inc."
DESCRIPTION="TivaWare Device Firmware Upgrade (runtime mode)"
WinUSB_SvcDesc="WinUSB"
DISK_NAME="TivaWare Install Disk"
DeviceClassDisplayName="TivaWare Device Firmware Upgrade (runtime mode)"


;
;   TivaWare USB CDC (serial) driver installation file.
;
[Version]
Signature="$Windows NT$"
Class=Ports
ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318}
Provider=%MFGNAME%
LayoutFile=layout.inf
DriverVer=12/14/2015,2.1.1.71

[Manufacturer]
%MFGNAME%=VirComDevice,NT,NTamd64

[DestinationDirs]
DefaultDestDir = 12

[VirComDevice.NT]
%DESCRIPTION%=DriverInstall,USB\VID_1CBE&PID_0102&MI_00

[VirComDevice.NTamd64]
%DESCRIPTION%=DriverInstall,USB\VID_1CBE&PID_0102&MI_00

[DriverInstall.NT]
Include=mdmcpq.inf
CopyFiles=FakeModemCopyFileSection
AddReg=DriverInstall.NT.AddReg

[DriverInstall.NT.AddReg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,usbser.sys
HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"

[DriverInstall.NT.Services]
AddService=usbser, 0x00000002, DriverServiceInst

[DriverServiceInst]
DisplayName=%SERVICE%
ServiceType=1
StartType=3
ErrorControl=1
ServiceBinary=%12%\usbser.sys

[Strings]
MFGNAME     = "Texas Instruments, Inc."
DESCRIPTION = "TivaWare USB serial port with DFU"
SERVICE     = "TivaWare USB CDC serial port"

  • 0
    TI__Guru*** 135355 points
    Hello Tom,

    First off since you mentioned using unsigned USB drivers, have you tried installing the patch drivers from TivaWare? That may clear up the signing issue: software-dl.ti.com/.../SW-TM4C-2.1.4.178.PATCH-1.0.zip

    Regarding the kernel vs user mode certificate, I am not certain on this idea because that really isn't a topic we've looked into as device specialists. Our example uses the WinUSB generic USB driver for ease of evaluation for customers. You don't necessarily have to use that USB driver and depending on your requirements, it may not even do enough for you.

    I tried searching for details on kernel vs user mode but came up empty myself. I am not really sure how to look this up as I am not all that familiar with how the windows drivers function, that is not a piece I have had to put together before.

    Maybe installing the signed drivers will help give you some ideas on that front though when I looked through the drivers installed for a COM Port I didn't see anything to indicate if it was a kernel or user mode driver.
  • 0 in reply to Ralph Jacobi
    Prodigy 60 points

    Hello Ralph,

    Thanks for your reply.

    The driver seems to work fine for our purposes (I have done several tests with the driver signed with a test certificate).

    I have installed the patch drivers, but the first driver is, apart from a different PID, slightly different from the "boot_demo_usb.inf" file:

    In the description line

    %DESCRIPTION%=DFU_Install,USB\VID_1CBE&PID_0102&MI_02

    the last part has been changed. In "boot_demo_usb.inf" it ends with "&MI_01". I do not understand what this means and haven't found the answer online so I do not know what I have to change in the TI-RTOS DFU project to get it to work with that driver. I have modified the PID in the project to use the one from the "boot_demo_usb.inf" driver but the driver update (starting from an unknown device in the Device Manager) fails because it "cannot find the drivers".

    Since the "MI_01" vs "MI_02" is the only difference between the two files, my problem would be solved as well if I can change the project to reflect this.

    For completeness, this is the line from the patched driver "boot_demo_usb.inf":

    %USB\USBLibDFUDevice.DeviceDesc% =DFU_Install, USB\VID_1CBE&PID_000A&MI_01

    And this is the line from "usb_serial_dfu.inf"

    %DESCRIPTION%=DFU_Install,USB\VID_1CBE&PID_0102&MI_02

    What does the "&MI_0x"-part mean and where could I change it in the project?

    Thank you in advance,
    Best regards,
    Tom van Rijn

  • 0 in reply to Tom van Rijn
    TI__Guru*** 135355 points
    Hello Tom,

    That I can help with I think.

    The integer that follows the string "MI_" is a 2-digit hexadecimal representation of the interface number, which is extracted from the bInterfaceNumber field of the interface descriptor.

    As far as modifying it on the project, I don't recall a case where I tweaked that. It's set in driverlib and would start as 0 by default and would increase to higher counts for composite devices. I would expect that needs to be changed on the driver side rather than in the code unless this is the case of a driver with 3 interfaces, but even then if properly initialized TivaWare would recognize the Interface number needs to be incremented.
  • 0 in reply to Ralph Jacobi
    Prodigy 60 points
    Hello Ralph,

    OK thank you for the insight.

    Unfortunately if anything is changed to the driver the signature will not be valid anymore and I would be back at square one since that would require me to sign it and therefore know if it is a kernel or user mode driver.

    I will take another look at the driverlib documentation and the project and maybe I will find a solution.
    If I do I will report back in case anyone has had a similar problem.

    I would like to thank you for the TI-RTOS USB Serial DFU project. I am just starting out with Tiva C (and USB drivers) and learned a ton!

    Best regards,
    Tom van Rijn
  • 0 in reply to Tom van Rijn
    TI__Guru*** 135355 points
    Hi Tom,

    You should be able to edit the USB library to force the descriptor to be what you need via hard coding and verify if that solves the problem to start, and then delve more into a better solution when you know it works.

    Note that if you change usblib, you need to import the usblib project into CCS and rebuild it so it updates the .lib file with the change.

    I'll go ahead and close this thread for now, but if you have any further questions on this topic feel free to post in here again and I'll see it.
  • 0 in reply to Ralph Jacobi
    Prodigy 60 points
    Hi Ralph,

    OK I’ll do that.
    Thanks for the advice.

    Best regards,
    Tom van Rijn