Does the OS get this information from the BIOS or does it scan the buses on its own to detect what hardware is installed on the system. Having looked around online different sources say different things. Some saying the BIOS detects the hardware and then stores it in memory which the OS then reads, others saying the OS scans buses (e.g pci) to learn of the hardware.
I would have thought with modern OSs it would ignore the BIOS and do it itself.
Any help would be appreciated.
Thanks.
Generally speaking, most modern OSes (Windows and Linux) will re-scan the detected hardware as part of the boot sequence. Trusting the BIOS to detect everything and have it setup properly has proven to be unreliable.
In a typical x86 PC, there are a combination of techniques used to detect attached hardware.
PCI and PCI Express busses has a standard mechanism called Configuration Space that you can scan to get a list of attached devices. This includes devices installed in a PCI/PCIe slot, and also the controller(s) in the chipset (Video Controller, SATA, etc).
If an IDE or SATA controller is detected, the OS/BIOS must talk to the controller to get a list of attached drives.
If a USB controller is detected, the OS/BIOS loaded a USB protocol stack, and then enumerates the attached hubs and devices.
For "legacy" ISA devices, things are a little more complicated. Even if your motherboard does not have an ISA slot on it, you typically still have a number of "ISA" devices in the system (Serial Ports, Parallel Ports, etc). These devices typically lack a truly standardized auto-detection method. To detect these devices, there are 2 options:
Probe known addresses - Serial Ports are usually at 0x3F8, 0x2F8, 0x3E8, 0x2E8, so read from those addresses and see if there is something there that looks like a serial port UART. This is far from perfect. You may have a serial port at a non-standard address that are not scanned. You may also have a non-serial port device at one of those addresses that does not respond well to being probed. Remember how Windows 95 and 98 used to lock up a lot when detecting hardware during installation?
ISA Plug-n-Play - This standard was popular for a hot minute as ISA was phased out in favor of PCI. You probably will not encounter many devices that support this. I believe ISA PnP is disabled by default in Windows Vista and later, but I am struggling to find a source for that right now.
ACPI Enumeration - The OS can rely on the BIOS to describe these devices in ASL code. (See below.)
Additionally, there may be a number of non-PnP devices in the system at semi-fixed addresses, such as a TPM chip, HPET, or those "special" buttons on laptop keyboards. For these devices to be explained to the OS, the standard method is to use ACPI.
The BIOS ACPI tables should provide a list of on-motherboard devices to the OS. These tables are written in a language called ASL (or AML for the compiled form). At boot time, the OS reads in the ACPI tables and enumerates any described devices. Note that for this to work, the motherboard manufacturer must have written their ASL code correctly. This is not always the case.
And of course, if all of the auto-detection methods fail you, you may be forced to manually install a driver. You do this through the Add New Hardware Wizard in Windows. (The exact procedure varies depending on the Windows version you have installed.)
I see a lot of info about system hardware, except for memory ,one of the main important part besides the cpu, which funnily isn't really mentioned as well.
This is fair because perhaps there's so many things to enumerate, you kind of lose sight of the forest through the trees.
For memory on x86/64 platforms you will want to query either BIOS or EFI for a memory map. for BIOS this is int 0x15 handle 0xe820. EFI has it's own mechanism which provides similar information.
This will show you which memory ranges are reserved by hardware etc. in order for your OS to know to leave them alone. (ok you have to built that part too of course ;D)
For other platforms, often the OS will be configured for a fixed memory size, like in embedded platforms. There is no BIOS for you, and performing a sort of bruteforce on memory is unreliable at best. (as far as i know! - not much experience outside of x86/64!!!)
For the CPU you will definitely want to look into MSRs, control registers and CPUID functions to enumerate the CPU and see what it's capable of. you can query if for example 64 bit mode is supported, and some other features which might not be present on all cpus.
For other hardware like pci etc, i would recommend like myron-semack said to look into PCI specification, pci-express, and importantly ACPI as implementing that will make you handle hardware and powermanagement a . bit more generically / according to newer standards.
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?
I have these related questions:
Does anybody know how an OS gets to know all hardware connected on the motherboard? (I guess this is called "Hardware Enumeration").
How does it determine what kind of hardware is residing at an specific IO address (i.e.: serial or parallel or whatever controller)?
How to code a system module which will do this job? (Assuming no OS loaded yet, just BIOS).
I know BIOS is just a validation and an user friendly interface to configure hardware at boot time with no real use after that for most modern OS's (win, Linux, etc). Besides I know that for the BIOS it should not be difficult to find all hardware because it is specifically tuned by the board manufacturer (who knows everything about it!). But for an OS or an application above BIOS that is a complete different story. Right?
Pre-PCI this was much more difficult, you needed a trick for each product, and even with that it was difficult to figure everything out. With usb and pci you can scan the busses to find a vendor and product id, from that you go into a product specific discovery (like the old days this can be difficult). Sometimes the details for that board are protected by NDA or worse you just dont get to know unless you work there on the right team.
The general approach is either based on detection (usb, pcie, etc vendor/product ids) you load a driver or write a driver for that family of product based on the documentation for that family of product. Since you mentioned BIOS, win, linux that implies X86 or a PC, and that pretty much covers the autodetectable. Beyond that you rely on the user who knows what hardware was installed in the system and a driver that came with it. or in some way you ask them what is installed (the specific printer at the end of a cable or out on the network if not auto detectable is an easy to understand example).
In short you take decades of experience in trying to succeed at this and apply it, and still fail from time to time since you are not in 100% control of all the hardware in the system, there are hundreds of vendors out there each doing their own thing.
BIOS enumerates the pci(e) for an x86 pc, for other platforms the OS might do it. The enumeration includes allocating address space for the device based on pci compliant rules. but within that address space you have to know how to program that specific board from vendor documentation if available.
Sorry my English is not very good.
Responding questions 1 and 2:
During the boot process, only the hardware modules strictly necessary to find and start the OS are loaded.
These hardware modules are: motherboard, hard drive, RAM, graphics card, keyboard, mouse, screen (that is detected by the graphics card), network card, CD / DVD, and a few extra peripherals such as USB units.
Each hardware module you connect to a computer has a controller that is like a small BIOS with all the information of the stored device: manufacturer, device type, protocols, etc
The detection process is very simple: the BIOS has hardcoded all the information about the motherboard, with all communication ports. At startup, the BIOS sends a signal to all system ports asking the questions "Who are you? What are you? How do you function?" and all attached devices answers by sending their information. In this way the computer knows how much RAM you have, if there is present a keyboard or a mouse, which storage devices are available, screen resolution, etc ...
Obviously, this process only works with the basic modules needed to boot the system, and does not work with complex peripherals that require specific drivers: printers, scanners, webcams ... all these complex peripherals are loaded by software once the OS has been charged.
Responding question 3:
If you wants to load a specific module during the boot, you must:
- Create a controller for this module.
- If the peripheral is too complex to load everything from the controller, you must to write all the proccess to control that module directly in the BIOS module, or reprogram the IPL to manage that specific module.
I hope I've helped
Actually, when you turn on your system, the BIOS starts the IPL (Initial program load) from ROM. For check the all connected devices are working good and also check the mandatory devices such as keyboard, CMOS, Hard disk and so on. If it is not success, it gives an error flag to the BIOS. The BIOS shows us the error through video devices.
If it is success, the control of boot is transferred to BIOS for further process.
The above all process are called POST (Power On Self Test).
Now the BIOS have the control. It checks all secondary memory devices for boot loader of the OS. If it hit, the bootloader's memory address is transferred to RAM.
The Ram started to execute the bootloader. Here only the os starts to run.
If the bootloader not hit, the bios shows us the boot failure error.
I hope your doubt clarified...
I'm currently doing a course about Operating Systems.
I understand that a kernel is a core part of an operating system that acts as a bridge between user applications and the data processing elements of a computer such as the CPU.
Why do we need Drivers then (e.g Touchpad drivers), doesn't the kernel control all computer hardware?
Because there are literally thousands (if not hundreds of thousands) of companies that produce hardware devices. The Operating System company cannot write software to handle all of them, so they provide a generic programming model using which those hardware companies can write software that could talk to their hardware.
Important to note is that although drivers are not actually part of the kernel as such, they do have some low-level privileges (direct access to hardware) because their code runs in Executive mode, unlike normal applications which run in User mode and generally do not access hardware directly. The whole point is that once the OS provides a way to write hardware-controlling software (called drivers), any vendor or person is free to write a software that could take advantage of the specialized features of their/his hardware device.
Also note that some hardware devices follow well-known standard (such as keyboards, mice, many video drivers, monitors etc.) and most OS come with built-in support for those devices. On the other hand, some devices do not have or follow standards, while still other can have both kinds of features, i.e. a subset of features that could be accessed by the default driver, plus a subset of features that doesn't follow any standards and thus is not supported by default driver. In all such cases, hardware manufacturers supply their own driver that knows the ins and outs of their hardware and therefore can take advantage of all features efficiently.
Certainly kernel does control all the hardware. However, there are way too many different hardware devices out there.
To deal with this vast variety of different devices, developers write specialized modules - and these are called drivers.
As far as I understand it, any program gets compiled to a series of assembly instructions for the architecture it is running on. What I fail to understand is how the operating system interacts with peripherals such as a video card. Isn't the driver itself a series of assembly instructions for the CPU?
The only thing I can think think of is that it uses regions of memory that is then monitored by the peripheral or it uses the BUS to communicate operations and receive results. Is there a simple explanation to this process.
Sorry if this question is too general, it's something that's been bothering me.
You're basically right in your guess. Depending on the CPU architecture, peripherals might respond to "memory-mapped I/O" (where they watch for reads and writes to specific memory addresses), or to other specific I/O instructions (such as the x86 IN and OUT instructions).
Device drivers are OS-specific software, and provide an interface between the OS and the hardware.
A specific physical device either has hardware that knows how to respond to whatever signals from the CPU it monitors, or it has its own CPU and software that is often called firmware. The firmware of a device is not specific to any operating system and is usually stored in persistent memory on the device even after it is powered off. However, some peripherals might have firmware that is loaded by the device driver when the OS boots.
There are simple explanations and there are truthfull explanations - choose one!
I'll try a simple one: Along the assembly instructions, there are some, that are specialized to talk to peripherials. The hardware interprets them not by e.g. adding values in registers oder writing something to RAM, but by moving some data from a register or a region in RAM to a peripherial (or the other way round).
Inside the OS, the e.g. the sound driver is responsible for assembling some sound data along with some command data in RAM, and the OS then invokes the bus driver to issue these special instructions to move the command and data to the soundcard. The soundcard hardware will (hopefully) understand the command and interpret the data as sound it should play.