My USB device is set as CDC. If the USB is set as CDC, the windows 10 will auto use default INF file(Usbser.inf). How can I change the default INF file to myself INF file?
You would have to instruct your users to install your INF file before plugging in the device. Once your INF file is installed, it will be used by default. If your INF file is not installed, usbser.inf and usbser.sys are used by default for matching USB devices.
Related
I am using USB to TTL serial cable in my mac. I have followed the instructions in the links Adafruit-driver-mac and mac-os-driver-installations,and installed the driver successfully. However after restarting my computer the serial cable is still not detected. I checked ls /dev/tty.usb. But no such device is shown in the list (except my BBB).
So, is it that the drivers not updated for MacOS 10.14 (Mojave) or there is anything else I am missing.
The USB to TTL serial cable I am using is PL2303 HX.
For driver install follow this link. link
I have inserted my usb drive into my computer. I have created a mount point "mount /dev/sdb1 /media/usb. I have copied files from cp home/my_name/folder/file_name to /media/usb.
I can see the files in ubuntu /media/usb, but I cannot see the files in the stick when I plug it in windows. All I see is this folder is empty.
Apparently, I transferred my files from ubuntu to my usb drive but I cannot see then in the usb drive in windows.
What am I doing wrong?
Thanks
You need to umount /media/usb before removing the stick.
Otherwise the changes to the filesystem might only reside in RAM (cache). USB drives are rather slow - it is highly likely that only some changes made it to the actual device. Try running chkdsk on the stick.
We have a device that requires we install drivers before it's plugged in, otherwise we need to remove the drivers that Windows 8 and 10 automatically download.
How do we make a USB driver installer that can install correctly whether it's plugged in first or not?
On Windows 10, my simple driver for usbser.sys with just an INF file and a CAT file will automatically take precedence over Microsoft's usbser.inf that they supply in Windows 10. But if that doesn't happen for your particular driver/device, you might look into using DevCon, an open source utility from Microsoft that can be used to list devices and update their drivers. I have never used DevCon in an installer, but I think I have noticed other installers that use it. There is an MSYS2 package for DevCon.
We use DPinst which is a Driver Package installer program that Microsoft supply. It is quite flexible & straightforward to use & can give you a pretty standard wizard UI.
How can I run Windows RT (the restricted ARM version of Windows 8) in an emulator, for development purposes? This question contains two parts:
Obtaining the image: Does an installation image exist (for vendors, in MSDN, ...)? Can I take a snapshot of the Surface RT disk (how?), or can I extract it somehow from recovery data (I don't know how the recovery system works, but there's a function to wipe and reinstall the software on the Surface completely).
Running the image: What can I emulate it on? I've heard about QEMU, but it has the reputation of being slow. Also, the program must emulate the neccessary hardware (Tegra-3).
I'm aware this question was asked 9 years ago, but now it's possible to emulate Windows RT in patched QEMU 6.2.0, you can also read more about the work being done for it.
The repo with downloads is here: https://github.com/binarymaster/qemu/releases
Please note that there is no audio, no network, and no GPU acceleration supported. Although you can have network connection with Windows 10 ARM, just read my previous answer below.
Answer from May 13, 2020:
I'm aware this question was asked 7 years ago, but now it's possible to emulate Windows on ARM in the latest QEMU 4.2.0.
Steps to follow:
Patch QEMU to report EL3 TrustZone available: https://github.com/TeoIzAwezome/rtemu/commit/0f8b8ec18725cd0f66a39b5520fb6a435a757f95 - if you're using Windows and don't want to build QEMU from source, you can patch qemu-system-arm.exe : replace this hex sequence with NOPs 4531C931D24C8D05BE515C004889F1E87AD82E00 => 9090909090909090909090909090909090909090 - it replaces this part:
Download Linaro firmware for QEMU 32-bit ARM platform, specifically 15.12 version which is the last one that boots Windows on ARM without problems: https://releases.linaro.org/components/kernel/uefi-linaro/15.12/release/qemu/QEMU_EFI.fd
Download an ESD image of Windows RT 8.1, these are publicly available from Microsoft.
You can find download links here https://tech.myonlylonely.com/wimboot-for-surface-2-en/
or by using Google with this string: 9600.17053.winblue_refresh.141120-0031_woafre_client_CoreARM_O15_en-us-IR5_CCSA_WOAFRER_EN-US_ESD_2F1E1C773E39C4672F52B1F3A0AE7844FD837B23.esd
Either convert ESD to ISO or just extract it with esd-decrypter-wimlib-8.7z : https://www.tenforums.com/software-apps/27180-windows-10-recovery-tools-bootable-rescue-disk-2.html
You will need VirtIO drivers for QEMU compiled for 32-bit ARM platform, precompiled viostor.sys driver is available here https://www.betaarchive.com/forum/viewtopic.php?f=62&t=40522 - if you built drivers yourself in Visual Studio, make sure to create catalog files by using Inf2Cat /driver:C:\Drivers\ /os:8_ARM,6_3_ARM and test-sign them (all .cat and .sys files); once drivers are ready, you can slipstream them into boot.wim and install.wim by using dism /Mount-Wim + /Add-Driver + /Unmount-Wim
If you don't want to boot and install from ISO, you can create a VHD/VHDX disk image and format/partition it the same way as it's done for Windows installation on UEFI systems — GPT partitioning: EFI partition - FAT32, MSR partition, Primary partition - NTFS. Use dism /Apply-Image with install.wim to install Windows files to created disk, and bcdboot to install EFI files
Since you're using test-signed drivers, you need to tweak BCD file on EFI partition:
set BCD=E:\EFI\Microsoft\Boot\BCD
bcdedit /store %BCD% /set {globalsettings} testsigning on
bcdedit /store %BCD% /set {globalsettings} nointegritychecks on
Once everything is done, start QEMU with these parameters:
set HDD=windows-on-arm.vhd
set ISO=en_windows_8.1_ir4_ARM_dvd.iso
qemu-system-arm ^
-M virt ^
-cpu cortex-a15 ^
-smp 2 ^
--accel tcg,thread=multi ^
-m 2G ^
-bios QEMU_EFI_1512.fd ^
-device VGA ^
-device ich9-usb-ehci1 ^
-device usb-kbd ^
-device usb-tablet ^
-drive if=virtio,file=%HDD% ^
-device virtio-scsi-pci,id=scsi0 ^
-device scsi-cd,drive=install,bus=scsi0.0 ^
-drive if=none,format=raw,id=install,file=%ISO%,readonly=on ^
-rtc base="2013-07-15",clock=vm
Notes:
There is known problem with PCI MMIO area, and USB input wouldn't work because of it. You can workaround that by replacing -M virt with -M virt,highmem=false however with this option Windows 8.1 RT will throw BSOD with code SYSTEM_THREAD_EXCEPTION_NOT_HANDLED.
It's known Windows 10 for ARM does not throw this BSOD code and works in QEMU pretty well with -M virt,highmem=false. You can use Google to get it: 10.0.15035.0.rs2_release.170209-1535_armfre_client-enterprise_volume_en-us :
Also note that full emulation of 32-bit ARM is very slow even on Intel Core i7-8700 # 3.2 GHz, so it's better to use some modern ARM board like Raspberry Pi 4 that have hardware accelerated KVM hypervisor.
Windows for 32-bit ARM is already considered legacy, better switch to AArch64 aka Windows for ARM64, see https://withinrafael.com/2018/02/12/boot-arm64-builds-of-windows-10-in-qemu/
There's no way to truly emulate a Windows RT enivonrment on ARM. You have two options...
1) Go pick yourself up a Surface tablet.
2) Contact your local Microsoft Technical Evangelist to see if they have loaner hardware available.
Also, chances are your local Microsoft Evangelist team is holding Windows 8 developer events where they may have test hardware on hand for you to try. If you're in the US, you can find a list of these events at http://msdnevents.com.
This programming guide implies that this is possible, so I figure what the heck.
Right now, though, it doesn't work.
Host OS is Vista 64-bit, VMWare Workstation 6.5.3 is running Windows 7 Enterprise 32-bit.
Installed Software on the VM:
Visual C# 2010 Express
Microsoft Server Speech Platform Runtime
Microsoft Server Speech Recognition Language - Kinect
Microsoft Speech Platform SDK
Kinect for Windows SDK Beta
I plug in the Kinect, the device is recognized by the VM, then I run the Sample Shape Game and it doesn't recognize the device. It says "Plug in the Kinect and try again" which turns out to be error 0x80080014, which leads to
http://social.msdn.microsoft.com/Forums/en-US/kinectsdknuiapi/thread/4da8c75e-9aad-4dc3-bd83-d77ab4cd2f82/
which gives me two things to look at:
is it plugged in with the special cable? yes
are all 4 entries in the Device Manager? no
In the Device Manager, I see a "Microsoft Kinect" group containing Microsoft Kinect Audio Control, Microsoft Kinect Camera and Microsoft Kinect Device, but there is nothing under "Sound, video and game controllers" other than VMware VMaudio. "Kinect USB Audio" should be there.
I'm guessing that there is some further twiddling I have to do with the VMWare USB / hardware options (whatever that tray with the USB / CD / HD / floppy etc icons is called) or some deft combination of rebooting and (un)plugging, but I'm almost out of enthusiasm.
Any ideas? TIA
EDIT: I realized that I had some lingering drivers on my host (Vista) system from OpenKinect. After removing them, I can no longer see the Kinect at all in the VM. Hmm.
There is this on read.me
Virtual machines: You must run applications built with the Kinect for Windows SDK Beta in a native Windows environment. Kinect for Windows applications cannot run in a virtual machine, because the Microsoft Kinect drivers and this SDK Beta must be installed on the computer where the application is running.
just to share that (not really understood how) VM Workstation 8 running in a host win 7 x64 with guest OS Ubuntu 10.04 sucessfully detected and installed Kinect drivers.
I was able to test it with libfreenect (OpenKinect Project) http://openkinect.org/wiki/Getting_Started#Manual_Build_on_Linux
best regards,
I'm late to the party, but we've been running and developing for the Kinect with Windows 7 running under VMWare under Mac OS X Mountain Lion.
I'm not a Computer Scientist, but I thought Turing showed that a universal Touring Machine was basically the same as physical hardware. I've had Distributed COM+ running on 3 or 4 VM's on the same physical hardware, but somehow the Kinect device is different? I don't buy that at all.
The most recent version of Microsoft Kinect for Windows (v1.6, possibly slightly earlier versions) in combination with the "Kinect for Windows" hardware does work inside a virtual machine. I run this setup on a MacBook Pro, Parallels 7 and Windows 7.
Note that a Kinect for Xbox does not work inside a virtual machine.
This page from Microsoft says that the "Kinect for Windows" device should work in a VM, but that the "Kinect for XBOX" does NOT work.
First of all you just need two Things to be installed:
libfreenect
libusb
after that you should set three flags to 0x02 at the line
typedef enum {FREENECT_DEVICE_MOTOR = 0x02,FREENECT_DEVICE_CAMERA = 0x02,FREENECT_DEVICE_AUDIO = 0x02,} freenect_device_flags;
Inside the headerfile located at /usr/local/include/libfreenect libfreenect.h but you will lose the ability to control the movement and the the microphone usage will be disabled so don't even try to access them or your device might get damaged after that you should also set
#define PKTS_PER_XFER 32
#define NUM_XFERS 6
inside your libfreenect/src/usb_libusb10.h file at the linux Line
After that rebuild your libfreenect by
mkdir build
cd build cmake ..
make make install.
Than Restart your virtual System and plug and connect only the Kinect Camera Device and no other Kinect device during start of the VM. When System is up you could test your device is properly working by switching to your previously created libfreenect build directory and go to bin there you run ./freenect-camtest you should get no or only a small number of package losses if a lot of losses occur try restart your vm with the camera device pluged in and already connected to your vm. You might need to active disconnect and connect the Webcam from the VM during startup to receive images this should be done during first seconds of VM Boottime!
Works with Ubuntu 14.04 and Workstation 10 and 11 and 11.1
HOST OS Windows 7 and Kinect SDK installed and Kinectdevice for Windows
Also it seems to be quite unstable you often have to restart your virtual system if you can't receive images from your Kinect. But if you once received images don't unplug device or you won't get data until you reboot virtual system with Kinect Camera connected to it.
=> This actually solved the problem otherwise to much frames get lost and its not possible to display proper image!