A device driver is a component that Windows uses to interact with a hardware device, such as a modem or network adapter. Rather than access the device directly, Windows loads device drivers and calls functions in the drivers to carry out actions on the device but how windows know which functions are available and how to call them?
As far as the first part of your question, on a modern system that supports ACPI (also see OSDev Wiki's page) Windows (or any other OS worth its salt) uses that to detect devices via the tables that are loaded by the BIOS (e.g. the DSDT).
Related
The memory map of the peripherals are defined by the chipset. However, modern operating systems like linux and Windows can boot from pretty much every chip (if compiled for the right architecture). As far as I know, the memory mapped devices like the USB Host are not included in the architecture standard. How can the OS still boot, load the drivers, and function? I suppose there must be some specification where the chipset is described.
Formulated a little different: How does the identification of the chipset work, what standards define the communication between the chipset and the processor so that it works on different hardwares and how does the kernel know the right physical addresses for the different peripherals?
Open systems typically use a device tree, which is a specification of the attached hardware, and how it is attached. There is another system, ACPI which supports legacy PCs. Either system permits an OS to locate and configure the buses and associated peripherals it needs.
It is never 100% as easy as that. For example, it is fine for the OS to know there is a scsi controller on bus 1 at address 1000; but if the code for the scsi driver isn't in the loaded os image, then this knowledge is of little use, as it has no way to load the driver.
The intel specification for ACPI attempts to fix this by having tiny driver implementations baked into the firmware of either the platform, the device itself, or both. Since the device doesn't necessarily know what sort of cpu it will run on, these mini drivers are written in a virtual instruction set which the host OS requires an interpreter for.
UEFI provides an alternate way have addressing the boot dependency via a more generic mechanism to use mini-boot drivers for the same purpose.
I'm curious about how the drivers work out of the box in x86 motherboards, like display, USB controllers etc.
For example :
Booting a toy custom kernel in x86 can display to screen without doing any extra work on the drivers space, however for an Android phone which is an embedded system, it seems almost impossible to display to screen with my own toy custom kernel (as there is information out there available about the memory map of the device and how the display is interfaced with the device).
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
x86 PC firmware has standard software interfaces (a lot like system calls), either modern UEFI or legacy BIOS int 0x10 and other interrupts.
The key point is that it's not just bare-metal x86, it's IBM PC-compatible which means software and even emulated legacy hardware like a PS/2 port, VGA, and even legacy interrupt controller.
If you didn't have all this help from firmware (for the benefit of bootloaders and toy OSes), you'd have a much harder job, e.g. needing at least a basic USB-hid and USB host-controller driver to get keyboard input. The lowest level function to handle a user input
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
That's not your real question. Embedded machines have working I/O hardware, they just don't come with portable software APIs/ABIs wrapped around drivers as part of the firmware.
I think most vendor's SDK comes with functions to access the I/O hardware (after maybe doing some fiddling to get it into a usable state). i.e. to write your own driver for it.
Embedded doesn't need this in firmware because it's expected that the kernel will be customized for the hardware.
Wouldn't it be better to have a BIOS or UEFI for maximum portability? Does it have any drawbacks to include one?
Yes: code size in the boot ROM, and someone has to write + debug that code. This costs time and developer salary.
No point in booting up what's nearly an OS (a UEFI environment) just to load a kernel which is going to take over the HW anyway.
Also a downside in boot time: any code that runs other than loading the kernel where it wants to be is wasted CPU time that slows down the boot. Having a very lightweight interface that just lets you get your kernel loaded, and leaving all the I/O to it, makes sense for this.
Unlike x86 PCs, there's no expectation that you can use this hardware with an OS install disc / image you downloaded that isn't specifically customized for this hardware.
It's not intended to be easy for hobbyists to play with using training-wheels APIs. Real OSes on this hardware won't use such APIs so why provide them in the first place?
Ex-My Webcam has face detection feature. I don't think this functionality can be achieved by standard device driver model .like Linux assumes everything as file and uses operations like read ,write etc for communicating to driver. So how user space programs uses these functionalities of device drivers?
If I know the device's model or vendor. Is there any direct way by which I can know the operating system of this device (e.g through the device driver or something like that? ). For example, I will quote an answer for a previous question I asked in: What is the difference between the firmware and the operating system?
Someone have said:
Hardware vendors commonly use a derivative of linux (e.g. Cisco IOS)
How can I know this. I know a name for one cisco device but I do not have the device and I need to check what is its operating system (even if it is widely known that it is Linux, I need to check this myself). How can I get this piece of information ? I checked the companies site and google, and I can not find any answer.
If the terms of the GNU Public License are complied with, it should be reasonably clear if a device is using any GPL code, including Linux, moreover the source code should be available too.
If the device uses an OS that is not open source, then even if the information were available to you, it is unlikely to be particularly useful except perhaps in respect to applying manufacturer's firmware updates.
Linux is by no means that common in embedded systems in general. It is commonly used in certain types of device, such as routers, STB's and NAS's. Often these devices have a web-server interface through which version information is usually available, but there is no common method of accessing this information, you'd have to access the particular URL for the device and parse the HTML.
You need a serial cable to hack into the device or read the binary from the flash and examine the hexdump. I have a STB in my home. The provider doesn't reveal the OS. There are competitors out there who need such information to take you down.
Recently, I'm trying to write a simple OS. This is a big project.
when I'm writing my code, I'm wondering how modern OS contact hardware under protected mode
In real mode, we can just call the bios interrupt to accomplish this job.
But I'm wondering how to accomplish this goal in protected mode.(Is it using in and out instruction??)
I traced some of the linux source code, but still can't find the appropriate code.
I know it is a basic question to many people, plz help me, tks.
and sorry about my poor English.
In protected mode, the CPU can run in either kernel mode or user mode. In kernel mode, you can always access the hardware. Calling BIOS interrupt is one old method, but a modern OS normally has its own device drivers for the hardware and does not call BIOS too often. If you know the hardware datasheet, you can use in, and out to access the hardware directly. Also, for modern PCI and PCI Express devices, they supported memory mapped IO (X86 CPU also supports this), and it means you can use mov to access the hardware.
For x86, the CPU also allows the user level program to access the hardware using in and out instructions. You can find it on Intel CPU manual. Just set DPL, CPL? (I forgot the correct name).
I guess you'd better read some book about device drivers, such as Linux Device Drivers, 3rd edition. http://lwn.net/Kernel/LDD3/