I'm basically a computer science grad student and have developed an interest in device drivers and software-hardware interaction. I am assuming that clicking the mouse or pressing a key on the keyboard would be a hardware interrupt managed by a software event-handler for the programmer to interact with it, but I'm unable to figure out whether scrolling of mouse would be a hardware or a software interrupt. Also which type of interrupt is more costly to handle for the processor?
Related
My question is, if I manage to develop some kind of bootloader and flash it (is it called that when you put a bootloader on an MCU?), and it works horribly, can it brick the MCU entirely, making it completely unusable, permanently?
The reason I'm asking is that I've been tasked to develop a bootloader for the STM32F407. Problem is, I don't know anything about bootloaders or anything of the sort, which means that I have a lot to learn.
I appreciate any answers, thank you!
In short no you cannot brick a microcontroller with a bootloader.
In the end bootloader is just a firmware and can be erased away using the programmer via SWD
Erase the flash and your controller is as good as new
In general, absolutely, I have a collection of bricked microcontrollers, every so often I get lazy and there goes another.
It is very specific to your microcontroller and family. For example, pin count is very important, as much bang for your buck as you can get, if your microcontroller relies on certain pins for in circuit (or even in a programming fixture) and those pins can be repurposed by software. For example jtag pins that can also be gpio pins. And your code for some reason uses them as gpio pins, AND the design of the chip is such that they cannot use the jtag interface when the chip is in reset, then you can get bricked.
Another very easy one is the pll or clocks in general. If/as you develop code to initialize the clock system (assuming you choose to do that, even if you use chip vendor supplied code) and you have a bug that switches the chip over to a clock that you have not properly initialized or isnt there, it might brick.
Now some chip designs, many, help you out in various ways. The AVR family in general there is a programming mode that happens while the chip is in reset or is related to reset such that whatever code is in flash cannot affect its functionality, you can have a bad board design, sure, but your code cannot prevent it from working. Another method is a "strap" a pin (or pins) that is dedicated to a boot function, set one way normal boot, tie it the other and it goes into an alternate bootloader. This is what you have on the stm32 boot0 and sometimes boot1 depending. that is your get out of jail free card for that chip family, if you brick your chip (pll/clock or mess up the SWD pins by using them as gpio), you "simply" change boot0 and it boots into an internal bootloader (which AFAIK you cant mess up) which is known to work. From that bootloader you can use SWD (chips not bricked now) or the bootloader itself (always serial, sometimes usb or other is supported). NXP similar deal. Atmel ARMs used to have (do have) SAM-BA now they really only support SWD, you can get some samba code and try to lock it into the flash, but way too easy to unlock and or trash that flash, so that is a fail on their part.
As part of your system design if you dont have one of these built into save you from bricking features (like boot0 on an STM32), then I recommend you add one. Very early code initializes a dedicated gpio pin as a strap into your software, if that gpio pin is pulled one way do a normal boot, if pulled the other then spin in an infinite loop or jump to some other guaranteed to not be buggy code. Not a complete guarantee that you wont build the project wrong and trash this code, but it at least allows you to develop your bootloader/project and not brick a tray full of parts/boards as you work through the peripherals that can brick it.
Note letting smoke out of the part is another way to brick it as well, and that can/does happen from time to time as well.
Lots of examples on how to boot an STM32, plus various code from ST that you can use as a starting point as well. (all of which is of various quality, you get what you pay for). Their docs are good, better than some of the competition, not difficult at all to boot and configure their peripherals, sometimes easier than trying to use a canned library. YMMV, you should try various solutions. But if you are new to this, bricking is highly likely, fortunately you have a chip that you cant brick so long as your board design breaks out the boot0 pin. For a prototype board for an STM32 I prefer to have a boot0 button and a reset button, just reset resets the chip and runs, hold boot0 and press reset and it goes into the bootloader. both have to be wired in properly with the right pull up or down as needed for this task. or a jumper works tie boot0 directly high or low then pop reset, costs you more time, but works.
Yes You can brick the Micro controller to never recovered state. I did this and i did it in STM32F427.
Bootloader is all about carefully selecting Clocks, Peripharals and Interrupts priority. if you do this, there are less chances to brick the controller. Also test everything before release your code as some companies wants to save proprietary information to be saved so they blow up the JTAG lines, the only way to program is via Bootloader and if it is not perfect, voila, you just bricked the controller.
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...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How does OS communicate with CPU?
There are drivers in the OS, ok I understand that part. OS uses drivers--> communicate--> device controller.
How does the communication happen? Does the OS touch the CPU directly with its commands, or is it using BIOS as the interface?
Let's assume that I will make my own OS. Its only task is to send arithmetic operations to the CPU and print results to the screen.
I will tell the CPU to put memory words to registers, count them, and then put them back to memory. How can I do that?
The CPU just runs instructions from memory starting at some offset and then keeps fetching the next instruction and repeating. The bootloader sets up the CPU to start running the OS entry point when your computer starts. Actions like keyboard or mouse input cause interrupts which the interrupt controller use to lookup special code setup by the OS to handle these interrupts. These interrupts are also used to allow the OS to switch which thread is currently running on the CPU using special privileged instructions that can only be run in kernel mode. The interrupt causes the CPU to switch to kernel mode before calling into the OS interrupt handler code so that the OS can use the necessary privileged instructions for controlling various behavior user mode code is not allowed to.
There are a lot of details concerning what registers are used for what purposes and much much more but it would take a whole book to cover everything.
Here is a free book that covers many details at a relatively introductory level.
CPU calls OS for specific tasks using interrupts, and OS uses special privileged CPU registers to program CPU.
For example, when you press key on keyboard, interrupt is generated by hardware. CPU calls interrupt handler function (it is part of OS), which will handle keypress and, for example, pass it into user program.
Other example of frequent OS-CPU interaction is task switching. Most OS uses hardware timer to generate around 100 timer interrupts every second. On this interrupt OS scheduler is called, and sometimes it can switch tasks by changing some CPU registers. In simplest OS & CPUs, scheduler will change SP (stack pointer) and PC (program counter) register. With more complex CPUs it will also reprogram MMU hardware unit of CPU and change many internal control registers.
External hardware usually programmed by drivers by doing PIO writes or writes to mapped PCI space (writes to special addresses of hardware memory).
I am not sure if there is a certain hardware requirement on the CPU for multitasking? would it possible to do multitasking on 8086 chip?
Yes and no. There are several kinds of multitasking methods and each one requires a different degree of hardware support.
The 8086 chip is capable of multitasking but only a type of multitasking called cooperative multitasking (Early version of windows, ie, 3.0 used this). How it works is every program on the system must yield control back to the operating system every so often. The operating system in turn passes control onto the next program, which then must yield control back to the operating system after some time.
There are some obvious drawbacks, what if a program never yields control back to the operating system? Then the entire system hangs and there is no way to terminate that bad program.
The type of multitasking used today is called pre-emptive multitasking. It works by interrupting each program and passing control onto another one. Programs do not need to be aware of the multitasking at all, they can be written to assume that they are the only program running on the computer, so the actual multitasking element is transparent to them. This kind of multitasking needs hardware support in the form of what is called virtual memory. The operating system needs to be able to separate the addresses spaces of each program so that each program is not directly aware of each other. Then hardware interrupt timers are used to interrupt each program so that the operating system can move from one task to the next.
Different architectures have different methods of actually doing the task switching. It's possible to do it all entirely in software with just the support of virtual memory and hardware timers, however some architectures support constructs to simplify this process, such as x86 which has the Load Task Register. This isn't strictly necessary however to implement multitasking and most operating systems that I am aware of do their own task switching.
For more information on pre-emptive multitasking and how it works in the x86 architecture, I recommend this article: http://wiki.osdev.org/Multitasking_Systems
EDIT:
The MP/M-86 operating system used what can be considered a preemptive multitasking model on the 8086 by using a hardware timer to interrupt processes and move onto the next one, so the 8086 is capable of a form or preemption; however many of the same issues raised above are still a concern. For example, each process has access to other processes memory spaces. There is also nothing keeping a process from hijacking the system by disabling the hardware timer interrupt. In order to have a robust multitasking environment a large degree of hardware support is necessary.
I was just wondering how the mouse, keyboard works during the boot process. Let us say that I have a USB mouse and a USB keyboard. When I switch on my computer, POST is done just to check whether all the hardware connected to my system are working. But to get a USB hardware working, we need to have a USB driver which ultimately is a process. But if OS is not loaded yet(I mean init and swapper processes), how this process comes into existence? One thing striking my mind is BIOS. But I think, BIOS can't identify the different drivers needed to detect different mouse, keyboards. Please help.
The BIOS is able to enumerate and control a certain subset of USB devices. In particular, mice and keyboards belong to a common class of devices (Human Interface Devices, HID) that are have a common, defined interface and which is fairly to drive. So, the BIOS just has drivers for that class of devices baked in.
Modern BIOSes emulate the PS/2 ports 0x60 and 0x64 using SMM/SMI with a feature often called "USB Legacy Support" (see the EHCI specification for more info.)
When the OS itself loads and initializes the USB controller there is a controller ownership transition from BIOS-owned to OS-owned.