Please anyone explain the exact differences?
While implemntin the driver code, I have facing an issue in both places.
We will need more information for getting to the root of your issue. What exact problem you are facing. Well as per your query different types of driver details are given below.
Physical Device Driver: A physical device driver is a driver for a specific piece of hardware. This drivers are written by device vendor. Some of the examples are ethernet drivers, graphics drivers(intel, nvidia) etc
Logical Device Driver: A logical device driver is a high level abstraction of how a device behaves. The logical device driver talks to the physical device driver for you to keep you abstracted from the underlying hardware. So Logical device drivers are written by operating system vendor. some of the examples are generic drivers provided by microsoft like USB etc
Virtual Device Driver: Virtual device drivers are drivers which emulates a hardware device. It emulates a piece of harware, so that softwares can have illusion of accessing real hardware. Some of the virtual device driver examples are virtual network adapter, virtual DVD/CD drive, virtual disk device etc
Related
I am working in Linux 2.6.20.14 running processor having USB chip FT313. I got a Linux driver from a vendor and I ported that to my Linux. When I do the memory read at the Uboot side on the memory to be mapped to my FT313 chip, I saw each 16-bit value was repeated twice in the memory. For e.g, if the default value is 03130001, the output will be like 03130313 00010001.
I needed to have dummy entries for each register to ignore these repeated values. After that, USB insertion and ejection give prints and IRQ count also increases. But when I tried to mount the Pen Drive as mass storage, SCSI probes won't happen and a USB device is not getting detected as Mass storage. I have already installed USB storage and scsi_mod modules.
Can anyone who has worked on FT313 in Linux tell me whether it is the expected behavior or not? And if it is possible to have FT313 chip as USB mass storage.
I am being confused on all terminology referring to it, so here is my request:
Name at least one USB Wireless Adapter whose Wi-Fi chipset is supported by a wireless driver enabling AP mode, Monitor Mode and PSM (Power Saving Mode) in a SoftMAC implementation (PSM functions accessible and modifiable via software).
The goal is to work on a new Power Saving Mode implementation, by modifying existing implementations of either PSM or APSM.
Check out MediaTek USB dongles:
http://www.mediatek.com/en/products/connectivity/wifi/pc/usb/
Most of these can work straight away using Linux mainline rt2x00 driver. rt2x00 is open-source, supports Monitor mode (can sniff packets), AP mode (can work with wpa_supplicant/hostapd), and is a SoftMAC driver (as it works with mac80211 driver). As for PSM, I'm not sure although there seems to be a good chance that rt2x00 supports it as well..
I need to create a driver, which will behave similar to software RAID. E.g. driver will need to communicate to multiple physical disks (or maybe even network resources), and shall look like a disk to the OS.
So two main questions are:
1) Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
2) Is it possible in theory to write such a driver for EFI? My primary concern is possibility of accessing other EFI disk drivers from your own virtual disk driver.
I only have time for a quick-ish reply, forgive me for brevity!
Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
To my knowledge, only the bootloaders for these OSs use the UEFI driver stack for loading the native OS kernel and drivers. Once ExitBootServices() is called by the bootloader, most of the drivers are unloaded, and (according to the spec) no calls to handle-based drivers may happen after this, meaning no disk drivers. Like a traditional bootloader, a UEFI bootloader is only using the basic drivers long enough to load the OS's native drivers. You can also use these drivers in the preboot environment if you'd like (although it sounds like you don't!).
TL;DR No, these systems can't use UEFI drivers other than for loading the OS.
Is it possible in theory to write such a driver for EFI?
You should definitely be able to layer your UEFI driver on top of the existing stack. It might be a little tricky if you haven't worked with UEFI before, but conceptually the system is very modular. There appear to be a number of resources on the Internet to help you out, and there is always Beyond BIOS: Developing with the Unified Extensible Firmware Interface by Vincent Zimmer.
As far as testing goes, you can use one of the simulators provided in Intel's EDKII (if you're on Windows, you should probably use the Nt32 project, it works well with Visual Studio).
TL;DR Yes, you can write this driver, but it will only work for bootloaders and applications in the pre-boot environment.
1) Are EFI drivers recognized and supported by Windows, MacOS X and Linux? E.g. can these systems use EFI disk drivers, and ?
No. Once you run ExitBootServices() it goes bubye. You can have a RunTimeDXE Driver, but those are incredibly limited. They cannot allocate memory (the VM Map is controlled by the OS) and they don't have access to any EFI APIs any more. They can be used to transfer information from the Firmware to the OS, but a better choice would be a private EFI Table.
2) Is it possible in theory to write such a driver for EFI? My primary concern is possibility of accessing other EFI disk drivers from your own virtual disk driver.
The bootloader is the only one able to use the EFI drivers. If you want to go to the OS level, you need to write your own OS driver that gets the information from the EFI driver using EFI System Tables. Such examples are Full Disk Encryption implementations.
In theory you would need to write an EFI Block Driver based, a Windows IO Filter or BUS/Volume Driver, an OS X IOStorageFamily KEXT and a Linux Block Device Driver all of them transferring the information from firmware to OS using EFI Tables, Variables or RuntimeDXE.
RuntimeDXE implementations are incredibly difficult due to the conversion to Virtual Memory Maps from the flat addressing available in the EFI.
I heard about USB to LPT adapters that are capable of mapping PC legacy parallel port address. What is the level of such mapping? I mean - is it possible to access the adpater's pins by using 'in' or 'out' x86 assembler instructions (in Windows or Linux)? If not, what does it mean that the addresses are mapped? What kind of emulation is this?
Thanks.
Marcin
A mapping from legacy I/O port addresses to a USB device is most likely handled by trapping the port access in kernel mode operating system code. For several generations of systems now, the operating system has been able to impose itself between application code and the hardware in such a way that even things that look like raw hardware access to the application are not necessarily so.
Effectively, when the processor comes upon that raw port access, it isn't executed but an operating system service routine is called instead.
I am very enthusiastic in writing device drivers for a microcontroller(like PIC, Atmel etc).
Since I am a newbie in this controller-coding-area I just want to know whether writing device drivers for controller is same as we write for linux( or any other OS) ?
Also can anyone suggest some online device driver building tutorial for the same ..?
Thanks,
If you are thinking about developing the device drivers to interface your device with a host computer (probably using USB), then most of the microcontrollers nowadays implement default classes that rely on native drivers.
A concrete example:
If you use a PIC18F4555, you can use the regular HID (human interface device) windows driver to communicate with your microcontroller (given you implemented it correctly). No need to develop any driver.
Writing a device driver for an MCU is a pretty far cry from writing it for a OS. Most MCUs won't have an OS running on them at all. You'll generally end up writing some low level Interrupt Service Routines (ISRs) and filling up buffers, that your application software will end up emptying. You don't have to fit into any device driver paradigm that an O/S has defined. You basically have to read the datasheet for the device you are wanting to interface with and read and write to its memory over whatever interface it might use (e.g. SPI, I2C, UART, etc.). Ultimately the device driver ought to provide intuitive function calls to the application software.
If you are using AVR MCU like atmega then you can use vusb (https://www.obdev.at/products/vusb/index.html) for those MCU that don't have any HID and handles the interrupts by connecting D+ and D- pins of the USB to digital I/O ports of the MCU.
The atmegaU2 packages have their own USB communication ports and HID.