Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
As per my understanding, the firmware is what controls the hardware, and drivers interacts with the firmware to control the hardware. Is that correct?
In Linux, what are the APIs or functions which interact with the firmware? Is the firmware code independent of any OS (e.g. Linux or Windows)?
Firmware is the software that runs on the device. A driver is the software that tells your operating system how to communicate with the device. All the devices having firmware are generally programed in to the device (either with a ROM chip, or a programmable ROM chip), but there are some devices where the firmware is loaded into the device at initialization time.
Every device does not have the frimware.
More technically "Firmware is software that is uploaded to a microprocessor or programmable logic on the hardware device itself. Examples of hardware that use firmware are HP printers that receive their code from the USB port at power up, wireless network interfaces that upload firmware at start up, routers that can update themselves from the internet, etc... In general, the ability to upload firmware to a device is a plus. it allows for product improvements to be added after the initial sale. These include fixing bugs in the product, responding to security issues, or responding to changes in the regulatory environment; Examples: FCC opening or restricting allowable bandwidths, power consumption, safety."
In General: A driver is a kernel module that talks to hardware; firmware is software that runs on the hardware that talks to the driver.
This depends on the way of connection between device and PC. For PCI boards there is set of Linux kernel mode API. Another set of kernel mode API is used to communicate with device connected through USB port. For Ethernet and WiFi connection you can use sockets API, communication is done completely in user mode. Devices, connected through serial port are also handled with user-mode API - they are treated as files in the Linux OS.
Generally, device firmware does not depend on the host system OS. It depends, however, on the OS (if any) running on the device itself. Firmware code may be written in plain C without any OS, or running under real-time OS. Modern devices may contain full-featured OS like embedded Linux or Windows. In this case, the whole OS with the programs specific to this device, are considered device firmware. For example, Android OS for specific mobile device.
Related
I want to learn how Linux OS understands the underlying hardware.Can anyone suggest me where to start for getting this understanding,As of now i just know the '/dev' sub-directory plays a vital role in that.
It has the device special files which are like a portal to the device driver which then takes it to the physical device.
I read somewhere that Udev daemon listens to the netlink socket to collect this information and Udev device manager detects addition and removal of devices as they occur.
But with these i am just not satisfied with the thought of how Linux reads the hardware.
Please let me know where to start to understand this, i am so thankful to anyone trying to help.
I think at first you need to find out how the memory mapping works. What is the address space and how it relates to physical memory. Then you could read about how the hardware is mapped in address space and how to access it. It is a big amount of docs to read.
Some of those information are in Linux Documentation Project.
Additionally some knowledge about electronic would be helpful.
In general - Linux for communication with devices needs some "channel" of communication. This channel may be for example ISA, PCI, USB, etc bus. For example PCI devices are memory mapped devices and Linux kernel communicates with them via memory accesses. So first Linux needs to see given device in some memory area and then it is able to configure this device and do some communication with it.
In case of USB devices it is a little bit complicated because USB devices are not memory mapped. You need to configure USB host first to be able to communicate with USB devices. Every communication with USB device is achieved via USB host.
There are also devices which are not connected via ISA, PCI or USB. They are connected directly to the processor and visible under some memory address. This solution is usually implemented in embedded devices. For example ARM processors use this approach.
Regarding udev - it is user-space application which listens for events from Linux kernel and helps other applications with recognizing device addition and configuration.
I have a USB audio device (Scarlett Focusrite 18i6) which does not require a driver, so I assume it uses the USB HID Audio Class standard.
It works on everything from Windows and Mac to Linux and iOS.
But on Mac and Windows, it has a control application which can for instance enable and disable direct monitoring.
How would I go about reverse-engineering how this is done, so that I can reproduce it on platforms where the control application does not exist?
I'm thinking of booting up Windows in a VMWare session and then logging the USB communication (somehow?) while using the control application, but it does sound tedious considering the amount of data and my very limited understanding of USB.
Any other suggestions?
You could try running the control application using Wine instead of reverse engineering it. However, if it's accessing USB devices then there is a good chance it might be using an API not supported by Wine.
To reverse engineer it, you should find a way to look at the USB traffic between the computer and the device. Total Phase has some hardware USB protocol analyzers, but you might be able to find a good software solution for free.
In Linux, HAL provides hardware abstraction and device driver too provide hardware abstraction. Can you please clarify me the difference between two ?
The device driver communicates with a specific device at a specific buffer and control flag block location. A hardware abstraction layer abstracts away the details of how specific devices work. For example, the driver for a USB mouse is very different from the driver for a PS2 mouse but at the HAL layer they are both mice and can be treated interchangeably.
I would say that HAL provides hardware abstraction using device drivers. From a certain point of view, no device can work without a driver. HAL goes one step ahead, offering a uniform (or, "easier") API for the application.
You can bypass HAL and talk directly to the device driver, but you can not bypass the device driver and talk directly to the hardware (this last sentence is more or less valid in general, depending on OS and environment).
The main difference is what they provide abstraction for. HAL abstracts processors, device drivers abstract different devices. So in a sense HAL is the "device" driver of the processor or the motherboard in PCs.
Back in the day, every programmer who coded an app also codes drivers for the various hardware that they wanted to support. So, if you have an idea to develop an app which needs to use network capabilities, you also needed to know how to program hardware drivers for the network card. Then came in the HAL.
So instead of having your software and OS directly reaching out to the hardware, there is now a layer in between called the HAL. The HAL lies underneath the operating system layer or within.
Now nobody is allowed to access the hardware, except that they do it through and by the hardware abstraction layer(HAL). Just the HAL is allowed to access the hardware.
Now it's something which is standard. All Devs have to do is make the game/app work with the HAL.
Now we have the drivers. The drivers tell the HAL how to access the actual hardware.
So whoever makes the sound card, they just make a driver that tells the HAL how to access that sound card.
So overall, our software interacts with the HAL, The HAL uses drivers to interact with the hardware. We are telling the HAL how to access that sound card or network card etc. with the use of the drivers.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm currently programming an arm embedded device. Currently I have installed thttpd and I have a web server running on the device. We have checked, using an ethernet connection, and everything runs fine. This web page controls systems running some sh script that execs c++ programs that communicates over pmpp with the final systems.
This device has an usb port that we plan to use to connect android / ios / bb devices(mobile phone or tablet) and open the same web page, for example, through 192.168.0.222.
Suppose I'm a worker and I have my company smartphone, I want to modify some values of the product so I just plug the usb, I access using safari/chrome or whatever navigator I decided to use, change the values and go home to spend the rest of the afternoon with my family.
What we do not want to do it's to develop an application to retrieve the web page from the device to draw them if we have previously created it.
You have several fundamental architectural problems to solve here if you I understand the question correctly - which is that you want an ethernet connection over a direct USB connection with a mobile device, so that the mobile device can consume a web-service on your embedded system.
1) USB roles: One of the devices needs to have a USB Host Controller, and act as the host. As it happens mobile phones support USB-OTG on their USB ports - and you'll be wanting to get them into host mode (appropriate cable for phones with micro-USB connectors, USB Camera Connection Kit for an iOS device).
2) USB device role: Your embedded device will need to implement an appropriate end-point for the host to communicate. One option is the CDC Ethernet from the Linux Gadget Framework. Provided your device has a functional USB Device stack and supports the gadget framework, this ought to be a case to changing your kernel config and recompiling. Alternatively, you write a driver that spoofs an existing USB Ethernet dongle's API.
3) USB Host drivers: You will need a corresponding USB driver on host. This is where it all starts to fall apart. None of the phones are likely to ship with these. On Android, you could in theory root the phone and then side-load additional drivers. On iOS, the you need to join the Made For iPnone programme to even start to consider this. Even the cost of getting on the scheme is covered by NDA, and it's only intended for volume OEMs. I presume Blackberries are well locked down too.
Alternatively, an approach that is far more likely to work is to connect a USB Ethernet (cost: about $15) or Wifi dongle (Ethernet is far, far easier) to the USB Host port of your embedded device and bring that interface up on your office network.
In terms of implementing the embedded side of this, any webserver capable of CGI is a quick and dirty way of doing the job.
Is there any simulation environment that allows to run and test Linux based USB device application on host machine running Linux?
Also same thing for Linux based USB host side applications where one can run and test Linux based host applications with physical/virtual USB devices.
Regards,
Mooni
Are you asking if it's possible to use a general purpose PC to simulate a USB device? If so, no, the hardware on, say, your motherboard is not physically capable (in almost all cases) of emulating a USB client device.