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"
Related
I have read that USB HDD are hot-pluggable but not removable whereas USB Flash drives are both removable and hot-pluggable.Internally, the windows DEVICE_OBJECT structure has Characteristics flag that can have a value FILE_REMOVABLE_MEDIA for removable media (not the removable device). Also, STORAGE_HOTPLUG_INFO structure has Devicehotplug boolean member that says device is hot pluggable or not. Can you please justify your answer with a little details?
David Zeuthen explains it best:
[...] "removable" means that the media of the device is removable. For
example, CD-ROM drives or Nin1 card readers for flash media. [...]
ATA disks connected via eSATA aren't removable, you can't remove the
platters.
Yet of course, you can intuitively understand that even non-removable devices can be hotpluggable (i.e. you can plug and unplug the entire device as a whole, as opposed to inserting/removing the media it contains).
Now, all (modern) buses in use in current systems are hotpluggable -
most new systems allow you to add/remove SATA disks while the system
is running.
Indeed you shouldn't have to care much about whether something is hotpluggable or not anymore: virtually all storage devices are. (In the past, you had to shutdown the machine to manipulate the storage devices).
So, it should follow that external USB drives (either HDDs or flash sticks) for example should be non-removable and hopefully always hotpluggable.
Unfortunately:
Of course, hardware sucks so virtually all USB keyfobs reports
"removable==1" probably because the maker of the device wanted to be
"helpful" and make things work better on windows.
I have no sources regarding the real reasons, but it turns out that many USB drives report themselves as removable too. David's suggestion that it might be because of certain operating systems which didn't use to support hotplugging but did support removable devices (CD-ROMs, etc) sounds reasonable: the manufacturers reused the same technique to trick the OS into letting the user "eject" USB drives.
Nowadays I would guess all modern operating systems make the distinction clear, and this has many advantages from a management standpoint (e.g. you might have a hotpluggable DVD drive with removable DVDs and you would thus need to be more clear about which you want to interact with). Still, older drives and old habits die hard, so you'll still find some "removable" USB drives even if they're really not.
Note: The bug report linked is about udisks which is more often found in the free software world. But again, I'm sure all systems make the distinction now even if the terminology is not exactly the same. Also note that the terminology is really rather arbitrary, though whichever terms you use for these two concepts best be well understood.
A simple Google search could have answered your question...
Hot plugging is the ability to replace or install a device without shutting down the attached computer. Hot plugging is implemented when
a peripheral device is added or removed; a device or working system
requires reconfiguration; a defective component requires replacement
or a device and computer require data synchronization. Also known as hot swapping. Hot swapping
allows easy accessibility to equipment and the convenience of
uninterrupted systems.
Removable media are data storage devices capable of computer system removal without powering off the system. Removable media devices are
used for backup, storage or transportation of data.
source: techopedia dot com
I'm building a custom linux kernel that should be able to access cdrom and usb mass storage devices, but not hard disks.
I tried disabling CONFIG_BLK_DEV_SD, but I lose usb mass storage support.
How can I achieve that? If not possible, is there a way to remove hard disk nodes in /dev at startup?
First, you need to define, what exactly "hard disk" means.
Second, you need to express the above definition as a set of udev rules. This way, device nodes for devices you don't want would not even get created in /dev/ in the first place.
One nice tutorial for udev rules is here:
http://www.reactivated.net/writing_udev_rules.html
Relevant Q/A:
https://unix.stackexchange.com/questions/66897/what-is-the-udev-rule-to-allow-specific-thumb-drive-vendors
Frankly, I'm amazed you even managed a bootable system with CONFIG_BLK_DEV_SD disabled: modern Linux kernels funnel virtually all storage I/O through the SCSI layer, then treat the specific types (SATA, PATA, USB mass storage, etc.) as flavors of SCSI.
I'd try disabling things at the next layer down in the system: enable SCSI disk and CD-ROM support, then disable all methods of actually talking to those disks: low-level SCSI drivers, ATA SFF support, ACHI support, etc.
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.
Part1:
To the linux/unix experts out there, Could you please help me understanding about device drivers. As i understood, a driver is a piece of code that directly interacts with hardware and exposes some apis to access the device. My question is where does this piece of code runs, User space or Kernel space?
I know that code that is executed in kernel space has some extra privileges like accessing any memory location(pls correct if i'm wrong). If we install a third party driver and if it runs in kernel space, wouldn't this be harmful for the whole system? How any OS handles this?
Part2:
Lets take an example of USB device(camera, keyboard..), How the system recognizes these devices? how does the system know which driver to install? How does the driver know the address of the device to read and write the data?
(if this is too big to answer here, pls provide links of some good documentation or tutorials.., I've tried and couldn't find answers for these. pls help)
Part 1
On linux, drivers run in kernel space. And yes, as you state there a significant security implications to this. Most exceptions in drivers will take down the kernel, potentially corrupt kernel memory (with all manner of consequences). Buggy drivers also have an impact on system security, and malicious drivers can do absolutely anything they want.
A trend seen on MacOSX and Window NT kernels is user-space drivers. Microsoft has for some time been pushing the Windows Userspace Driver Framework, and MacOSX has long provided user-space APIs for Firewire and USB drivers, and class-compliant drivers for many USB peripherals. it is quite unusual to install 3rd party kernel-mode device drivers on MacOSX.
Arguably, the bad reputation Windows used to have for kernel panics can be attributed to the (often poor quality) kernel mode drivers that came with just about every mobile phone, camera and printer.
Linux graphics drivers are pretty much all implemented in user-space with a minimal kernel-resident portion, and Fuse allows the implementation of filing systems in user-space.
Part 2
USB, Firewire, MCI (and also PCI-e) all have enumeration mechanisms through which a bus driver can match the device to a driver. In practice this means that all devices expose metadata describing what they are.
Contained within the metadata is a DeviceID, VendorID and a description of functions the device provides and associated ClassIDs. ClassIDs facilitate generic Class Drivers.
Conceptually, the operating system will attempt to find a driver that specifically supports the VendorID and DeviceID, and then fall back to one that supports the ClassID(s).
Matching devices to drivers is a core concept at the heart of the Linux Device Model, and exact matching criteria used for matching is match() function in the specific bus driver.
Once device drivers are bound to a device, it uses the bus-driver (or addressing information given by it) to perform read and writes. In the case of PCI and Firewire, this is a memory mapped IO address. For USB it bus addressing information.
The Linux Documentation tree provides some insight into the design of the Linux Device Model, but isn't really entry-level reading.
I'd also recommend reading Linux Device Driver (3rd Edition)
inHi, this question is fast, but from my point of view its pretty hard. I have been messing with implementing USB device built from MCU. So I found project called V-USB which is software-emulated USB interface for Atmel MCUs. But this is not so important.
The question is, on their site, they say that using custom USB class, you can simply write host software on Unix, but you need driver DLL for Windows. The problem is, they dont explain why.
So, please, why? I dont know Unix based systems, but I thought that the very basics of different OS are the same becouse thay rise from the same hardware, and even Unix cannot do HW IO operations from user mode.
I know about libraries for USB communication like LibUSB and so, but I want to know the very reason why thay say that its easy on Unix. Thanks.
EDIT:
Thanks for answer, but can I have further question? How this everything is a file works? I mean, my vision of driver on Windows is a program running in kernel mode, thus allowed to access CPU IO ports, which either provides functions to OS by some standarts, to allow Windows to use it (for example HDD driver must be accessible from filesystem driver by standardised set of functions, to allow any HDD work the same).
With this all you have to do is call drivers via WinAPI function or directly call its functions. But USB implements new feature which is different classes. So there is main USB root driver to handle USB and calling right secondary drivers for right devices. Than there is the same procedure, you just call your USB driver.
But if in Unix everything is a file, how are handled different classes? I just cannot imahine how this works in some analogy to Windows way. Does that file represents the way to communicate with USB root driver?
Everything in UNIX is a file, which supports simple operations. No matter if you are communicating via a terminal or a via a usb device, everything is a stream of bytes to a file.
* read
* write
* lseek
* close