ATA commands to USB drive - windows

Windows 7
C Programming
Visual C++ 2008 (in a VMWare)
I'd like to send some ATA commands (IDENTIFY DEVICE, READ NATIVE MAX ADDRESS, SET MAX ADDRESS) with DeviceIOControl to a USB hard drive. Therefore I have some questions.
As I understood, USBSTOR cannot handle ATA-commands directly (with IOCTL_ATA_PASS_THROUGH). I tried this and it worked with the native IDE hard drive but not with USB.
Is it correct that applications send SCSI-commands to the device and they are forwarded to the device? So I need to create a SCSI command with the respective ATA command encapsulated?
With what dwIoControlCode can I do that? I tried it with IOCTL_SCSI_MINIPORT but the error was ERROR_NOT_SUPPORTED. Could it work with minport? Is miniport still up to date?

Look at this link:
http://www.mombu.com/microsoft/windows-programmer-nt-kernel-mode/t-howto-send-ata-spec-command-to-usb-hdd-1646752.html
Q: howto send ATA spec. command to USB HDD?
A: You are limited to whatever the USB->ATA tailgate (bridge) chip supports.
If you control the bridge, you can implement whatever you want. If you
don't, you'll have to ask the bridge vendor to reveal what they do support.
See my replies in the thread on 1394->ATA on NTDEV for more information.
Q: Once more question: whether probably to get access to everyone disk
in SCSI RAID?
A: No.
You can only send SCSI commands to the bridge/enclosure at the end of the USB
cable. How they are translated to ATA commands - is not under your control.
I assume El Cheapo enclosures to only translate the essential SCSI commands. In
this case, you will only have 1) SCSI INQUIRY emulated by ATA IDENTIFY 2) SCSI
READ CAPACITY emulated by ATA IDENTIFY 2) READ and WRITE 3) VERIFY.
And that's all. In this case, you will have zero chances sending any
non-trivial ATA commands, since the USB-to-ATA bridge on other side provides no
ways of doing such.

Related

How to find scanner device in /dev folder in Mac OS X?

When I do lsusb, I get:
Bus 020 Device 013: ID 03f0:7d04 Hewlett Packard Deskjet F2100 series Serial: CN76R3R53Q04TK
How can I associate it to a file in /dev?
Adding a file-like handler to a USB device is job of a kernel driver.
In general, however, printers don't need a kernel driver. They usually just do bulk USB transfers, which you handle with libusb, and that works without an explicit /dev/ entry describing exactly your printer.
Depending on your OS, libusb's communication with the USB stack of your kernel will look different (and I'm not overly versed with OS X), but there's probably something like a /dev/bus/usb/20/0/13 or so; really depends.
Anyway, unless you want to write a CUPS printer filter, you probably don't want to interfere directly with the USB device, but let your printing system do that.
So, TL;DR: That's a printer. It usually does not have a /dev/ entry on its own. Use libusb to communicate with USB devices on a USB packet level.

usb hard drive/pen drive emulation via bios

I am trying to read/write usb hard drives and flash drives for a DOS application.
I read EDD spec. and it mentions that function Int13(Fn = 48h) can be used to get interface path and device path for a particular disk drive. This also includes usb interface and ata interface.
Now this function also returns a Device Parameter Table Extension (DPTE) table that gives I/O addresses via which a software bypassing Int13h can use to read/write the device. But this table is only for ATA afaik.
I wanna read/write to usb disk/pen drives w/o using Int 13h. Is it possible?
Actually it is a disk I/O sensitive application in protected mode. So using Int13h would involve heavy penalty in terms of performance, due to mode switching. So, I am trying to avoid using Int13h.
Does bios initalizes usb drives to appear as ATA drives too. If so, then I can use DPTE to get the I/O base addresses of the command block and control block and then access the usb drives just like ATA drives. Am I right?
Thanks
This particular issue has been discussed at length among the FreeDOS community. The best guide to the whole issue is the FreeDOS technote "USB with DOS"

USB linux gadget zero driver communicate with Windows host

I need to set up USB communication between a Windows 7 host and a Linux device for data transfer. I was able to compile the Linux kernel on the device to include the Gadget Zero driver in the kernel (not as a loadable module - Linux version 3.0.15). My project has some requirements, which also explains why I chose Gadget Zero:
1) On the Windows 7 host, a kernel mode driver must be used to communicate over the USB connection for sending and receiving bulk data. (speed is not important, not a lot of data at once).
2) On the linux device, no requirements on USB side except send and receive data easily over USB link. The data received will eventually be "unmarshalled" to call functions in another kernel module (and those responses packaged and sent back to the host).
3) Multiple linux devices will be connected to the host, so need easy way to enumerate connected devices and communicate with them.
So due to the requirements, I decided against the Gadget Serial. I'm having serious issues sending and receiving data over the virtual COM port in kernel mode (KMDF) in Win 7 host. WinUSB does not seem to want to open my attached device (I'm using KMDF windows USB driver from template in VS2012) Also, the gadget serial driver on the linux side, I cannot find the functions where the data is received and sent. Plus, any received data on the linux device seems to be echoed back to the host for some reason. (and to test this, I wrote a simple user-mode app in Windows, which is a no-no for my project).
Gadget Zero, it appears much simpler on the linux side. I can plug the USB cable to the Win7 host, and I can get the device to appear in the device manager. However, again I am having problems with getting communication going over the link. Gadget Zero has 2 bulk endpoints, so this shouldn't be an issue. Surely, someone has made data communication possible between a Windows host and a linux device using Gadget Zero? With Gadget Zero, it should be easy to enumerate the connected linux devices and communicate with them.
The trick is to keep the Windows side communication in kernel mode. Can someone point me in the right direction perhaps with Gadget Zero, Windows 7 KMDF, and some sample source code? I have a hard time believing no one has done this before because my internet searches don't turn up much. (and mostly user-mode solutions with Gadget Serial).
Thanks!
So you're writing a Win32 driver in which you want to communicate with your linuxed usb? I haven't written much win32 kernel code, but I believe I've seen a huge section in the doc, saying something like "This is how you make usb drivers"... That'd be it. In other words, when in kernel mode you have access to the full kernel usb layer. You don't need an existing driver or whatnot.
On the linux side you can use the serial gadget, in a different run mode. Only the default run mode, registers it self as VCP. There exist a more basic mode:
modprobe g_serial use_acm=0
Give it your own vendor id and you'll be able to attach your very own custom win32 driver. The 'multiple linux devices' will be handled by Windows. (Multiple instances of your driver, will be initiated.)
The echo you're seeing btw, is most likely a terminal feature. (The terminal mode on uarts will echo.) You have to disable it, when connecting. And now that you're at it, you also have to disable the xon/xoff, esc chars etc. (Standard legacy rubbish.)
And another thing. I'm not sure the gadget zero actually sends the data onto the line. It's meant for testing the gadget framework. (I could be mistaken though.)
Anyway, you've prolly solved this issue years ago. I'd be nice to know what you came up with.

Windows PC as a USB slave to emulate a thumbdrive

I need to create a application that will allow a Windows PC (XP/Vista) to emulate a thumbdrive. That is, when the PC is plugged into either another Windows system, or in this case, a piece of hardware that allows for USB thumbdrives to be plugged in, a folder on the computer looks like a giant thumbdrive. Any thoughts on where a guy would start to investigate this?
Update (more specific description):
I need to connect my PC to one of the newer multifuction devices that support scanning to a USB thumbdrive that is inserted into the front of the device. These units do not support WIA or TWAIN via the rear USB connector that you'd typically use for connectivity to a PC.
Most USB controllers in regular pc's dont have the possibility to function as an USB slave. So I'd start with investigating what kind of hardware you're going to use.
Another way to go: there are USB Link cables to link up 2 pc's over USB, maybe that's usable for you?
You cannot do this in an application. At the lowest level, the USB ports on your computer are controlled by an Host Controller Interface. This chip will manage up to 127 slave USB devices. You would need to seriously reprogram this chip before it implements the slave side of the USB protocol. Of course, at that point any USB hub in your PC will break down - those 8 USB ports you probably have are usually implemented by 2 smart USB hubs connecting to both USB1 and USB2 host controllers. Next, your USB keyboard and mouse will stop working.
Take an MCU with two Slave USBs. Write a simple frimware which makes one USB act as a Special Device Class and wait until PC on this USB provides mandatory data (including Device Class, of course) for the other USB. Write a PC program which connects to the Special Device (your MCU), uploads Mass Storage Device Class and redirects I/O to a dedicated partition. The other USB on the MCU will become an emulated Mass Storage Device.
Some of those code can be taken from Linux.

USB Debugging

I'm looking for a very specific USB device for debugging systems that may use USB but not with a regular computer (proprietary hardware). I want a device that has a USB host controller and two USB device connections. The device to be debugged is connected to the USB host controller and one of the device connections is connected to another device with it's own host controller on it. The the other device connection is connected to a pc. The point being that all USB data travelling through the device (from the device connected to the host controller to the device connected to the first device connection) is reported to the pc.
I'll happily write software to do the logging (in fact I want to) but I can't seem to find a board like this anywhere. Can anyone help?
I have an Ellisys USB analyser, which isn't exactly what you describe internally, but does sit between a peripheral and a host and use a separate PC to collect the data.
(i.e. it has two 'B' and one 'A' connectors on it.)
Excellent product, and very helpful company.
Sniffing the USB shouldn't be too hard if you have the right hardware. And that is the tricky question. I haven't seen anything that describes the USB breakout box that you want. However I can say that this is in the realm of the following two magazines:
Nuts and Volts
Circuit Cellar
If they don't have a USB breakout box project in their archives, then at least they will have advertisements for small cheap single board computers that would have multiple USB ports that you can use for buffering the signals and reporting it back to your PC.
Alternatively is it possible to just wire your PC up to the middle of your two devices and write a custom drive that echos data back and forth while sniffing off a stream for you?
Sorry for the long delay in my reply -- I checked out one of our USB developer's toolchain, and he uses a Beagle USB Sniffer. He seems happy with it.
You're looking for a USB device with two upstream outputs. I think according to the USB spec, this is not possible. You will have two USB hosts trying to send messages and control the USB devices at the same time.
What if you were to look for a device which allowed you to view the data going through a hub via something other than a usb output?
If you're building something custom, take a look at this USB chip site. The chips are programmable via a windows application. Once you define how you want it to operate, it's saved on an EPROM on the dev board ($30-$50).
Sorry if this isn't helpful!

Resources