I have been working on developing IOT solution for docker, and I found an help usage that docker does supports (pass-through for gpu, disks, usb and serial ports):
Exposing Nvidia GPU device for computation
Exposing particular serial device etc. using flag device
So before just working around from scratch to implement the passthrough mechanism for system memory I wanted to know if there exist any way already exist to achieve the same or not to aid:
Read/Write physical system memory
Expose all IO devices in one shot!
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.
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
I'm using Delphi to develop real-time control software and over the last couple of years I have done some work running older Windows installations under Microsoft's VirtualPC and it works fine for 'pure software' development (i.e no or limited access to the outside world). Such tools seem able to work with network connections but I have to maintain software which performs I/O via the parallel port (via a device driver). We also use USB I/O. In the past I've liked Microsoft's virtual tools because it takes time to install a new operating system and then (in my case) install Delphi and a load of libraries and components to provide development support. In these circumstances I've not been too bothered by my lack of access to the low-level I/O ports.
I want to up my game and I'm happy to pay for a good virtualisation tool IF I can have access from it to the outside world, i.e I want to be able to configure it to allow access to my machine's parallel port and com ports in the same way as if it was running natively. This access has to be able to expose the parallel port in register terms, i.e to 'see' the port at address $03f8 for example and to support I/O operations of those registers (via the appropriate kernel access) as my Windows 7 64-bit installation is able to do.
I see that there are a number of virtualisation solution out there now but it's quite hard to acertain the capability of each at such a low level. Does anyone have any experience or knowledge in this area?
The VMware products would be suited best for this. You can add virtual serial and parallel ports and forward them to a physical port on the host, or even to a file or a named pipe.
You can also connect any USB device that is connected to the host machine.
This works with VMware Workstation, but might even work with the free VMware player too.
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.