Christopher Hallinan examines the bootloader’s role in a system, followed by an introduction to some common features of bootloaders. He also takes a detailed look at a popular bootloader used for embedded systems, and introduces a few of the more popular bootloaders.
Embedded Linux Primer: Bootloaders
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Informit.com article! 3 quarters of the page are advertisements and the length of the article, being so long, is clearly to increase the number of ads served to you!
Anyway, this article goes quite into the details, but I still have the feeling, after reading it, that I understand nothing of the topic. I think it has got to do with the selective extraction.
Well, the above is intended to be sarcastic. But the book is probably fine and worth to buy. I just think Informit.com articles are horrible.
…3 quarters of the page are advertisements…
You’re right, filling the article with tons of ads and breaking it to many pages makes it much less readable.
But you can always use the “Print” view. Informit, like many other sites, remove all the advertising and combine the pages into a long single one.
Thus “print optimized” view is actually “screen optimized” and “network optimized”.
Edited 2006-12-17 14:46
Anyway, this article goes quite into the details, but I still have the feeling, after reading it, that I understand nothing of the topic. I think it has got to do with the selective extraction.
Well, the above is intended to be sarcastic. But the book is probably fine and worth to buy. I just think Informit.com articles are horrible.
I am sure that the extraction has made the text less readable, but what is there isn’t particularly readable at all.
Here is Cloudy’s Condensed Intruction to Hardware bootstrapping, by way of comparison:
When you first turn any computer on, for various reasons, it doesn’t power up in a fully ready-to-run state. Pressing the power button causes a power sequencer to turn various parts of the system on in a particular order. The hardware power sequencer does the minimum necessary work to allow the processor to start executing code. This sequence is often called ‘cold start’, and the exact details vary from system to system. What follows is an outline of what happens during and after cold start in an embedded system.
The hardware sequencer turns certain parts of the system on. Typically, it turns on the random-access memory controller and random-access memory, meanwhile it turns on some non-volatile memory, usually in the form of flash memory. The last thing the hardware sequencer does is arrange for the processor to be turned on. (Non-volatile memory is any storage that retains its data when power is removed from the system.)
All modern processors have a very small program built in that is their bootup sequence. When they are first turned on, they automatically run this sequence. In the simplest form, the processor’s bootup sequence merely causes the processor to start fetching instructions from a well known address and executing them. More complex processors may have the program they execute first hard-coded into the processor. In that case, the program is very simple and all it does is copy a small amount of data from the nonvolatile memory to the ram and then start executing it.
Whatever the case, the last thing the hardware power up sequencer does is enable the processor. At that point, the system is in a barely usable state and it is entirely up to the processor’s bootup sequence to get it into a fully runable state.
Power sequencers are not sophisticated, so they tend to leave the parts of the system in a random state. In particular, the registers in the CPU have random values in them, other than the processs counter, and the various devices attached to the system have their control registers in a random state.
The process of initializing all of the hardware in the system to a known starting state and starting execution of the operating system is called ‘bootstrapping’. It is a complex process. Over time the work of bootstrapping a system has been partitioned among two or three programs, each bringing the machine a little closer to fully operational.
The first stage, called various things including ‘early boot’ and ‘stage 0’ boot, is the simplest, and is almost always done entirely in assembler language for the given processor.
Early boot has to set the processor registers to known values, turn memory mapping and caching off, turns off the caches and virtual memory, and sets up the controller for physical memory. Once this is done, it typically enables some very primitive device i/o so that the rest of the boot process can display messages. Often, in embedded systems, this is as simple as turning LEDs on or off.
Early boot may be a separate program, or it may be part of what is commonly called the ‘bootloader.’ If it is a separate program, it must also arrange for the bootloader to be copied into memory and started. If it is part of the bootloader then it simply branches to the bootloader and starts executing it.
The bootloader is a primitive operating system that serves several purposes, but, mainly, its purpose is to finish initializing the hardware necessary to start the operating system, and then load the operating system from some form of permanent storage into memory and start it executing.
Early boot and the bootloader are often separate programs because the CPU’s hardware startup sequence has the ability to copy a limited amount of data from permanent storage to memory, and that amount of storage is rarely enough for an entire bootstrap program. In this case, early boot basically exists as a separate bootloader that only has the job of copying the main bootloader into memory so that it can do its job.
One situation where early boot isn’t needed is devices that have permanent storage that can be directly executed from. NOR Flash is a common form of rewritable nonvolatile storage that can be treated as if it were ordinary memory. NOR is very slow to write, so it isn’t used as main memory, and it’s slow to read, so it is usually only directly executed from during booting. (Running directly from NOR is called “execute in place”, abbreviated to XIP.)
NAND Flash and other forms of nonvolatile storage, such as disk or USB flash drive can’t be directly executed from and so the early boot is usually a separate program that copies the bootloader from the storage to memory and starts it.
NEXT: Bootloaders
posting this crap.
This is not one of the worst Informit articles, but it’s incoherent, confused, and confusing.
The author completely misses the concept of two-stage booting, even though he uses the OSK5912, a board that has a two-stage loader, as an example.
The author has confused NOR-FLASH with FLASH and and described a booting process that doesn’t work on a NAND-FLASH based board.
The author gives an example of a dhcp.conf entry that, in fact, won’t work, as it is missing fields.
The author treats the DRAM controller as special because it requires clock initialization, but then completely misses that OMAP based systems like the OSK5912 require clock initialization for just above every component in the system.
The author has apparently never ported Das U-BOOT to a new ISA, if he thinks it’s an easy port. uboot is only an easy port when you’re porting it to a board that’s very similar to run it already runs on.
The author completely missed describing that the bootloader has to communicate information to the OS kernel and that this is a significant problem as there is no standard for such communication and so different bootloaders much different OSes with varying degress of success.
The author wastes space on Lilo, which is obsolete, and grub, even though neither are much used in embedded linux development.
The author completely forgets to mention the most commonly used bootloader in embedded systems: roll your own.
And, of course, the author never discussed the age old debate over how much initialization to do in the bootloader and how much to do in the kernel.
The early boot has arranged for a very minimal system to be running. It has turned off the MMU, disabled the cache, and possibly turned off all of the devices attached to the system except for the CPU, ram, and the nonvolatile storage that contains the bootloader.
The early boot then arranges for the bootloader to become resident in memory. This may require no work, as when the bootloader is XIPed from NOR flash, or it may require copying the bootloader from non-volatile storage to ram. In either event, the bootloader starts with a pretty minimal system.
The bootloader sets up the page tables that it will use, allowing itself a stack, invalidates the caches, and turns memory management on. This code is usually written in assembler for the specific processor. Next the bootloader branches to code that configures more of the system.
As a minimum, the bootloader will configure the device it is going to load the OS kernel. It may also discover and configure other devices on the system. If the loader is simply going to load the kernel, it does that next, copying it from nonvolatile storage into memory and eventually branching to it.
Unfortunately, “copying it from nonvolatile storage” can be a fairly complex process. In its simplest form, the bootloader simply copies a previously prepared binary image directly from storage to well known locations and then branches to the start of that image. In its most complex form, the bootloader has to understand the filesystem format used by the OS, find the kernel on the filesystem, translate the kernel on the fly from ‘executable’ format to the raw format needed for the system, and copy it into memory. Embedded bootloaders tend towards the primitive, since memory and startup time are premium.
Once the bootloader is done copying the kernel, it branches to the start of the kernel. There, the initialization process is done all over again. The bootloader may have left some data in memory that kernel knows how to read, or it may not have. It probably didn’t set up the virtual memory the way the kernel wants, and it most likely didn’t have the software necessary to properly initialize every device on the machine, so this reinitialization done early in the kernel is the third stage of loading.
But bootloaders also serve another purpose, typically. A ‘bootloader’ is often a control program that initializes a keyboard and display and interacts with the user of the system. It does a range of tasks from downloading new kernels (often called ‘flashing’) to running diagnostics, to setting parameters for booting the kernel.
Most of the work done by a bootloader is common to all systems, so, like operating system kernels, bootloaders have been made portable. There are many available bootloaders, and discussing them is beyond the scope of this posting, but the most common ones used in Linux embedded development are Redboot and Das U-Boot (usually just called uboot) and you can read more about them on the web.
You can write your own bootloader, and developers of embedded systems often do. When you have a particular application in mind, you can streamline the process, saving both space and boot time. The cost of doing this is that you have to port your bootloader to every new device you develop.
You might want to have a llok at
% man boot
% man loader
or read chapter 1 of the FreeBSD handbook: “Bootstrapping and kernel initialization” at http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/boot…
The introduction is very generic (might fit to topic of embedded systems) while the boot stages and the loader are FreeBSD specific… for educational use…
Cloudy, thank you very much for your postings. I wish to read that on Informit.com!
I’ve always held the deep religious belief that any man with a deep understanding of how an OS bootstraps will never go hungry.
Tim Holwerdi
Hi, My name is Tim Holwerdi.
I am gonna tell you my last dream…
I am an Aszzhole in search of Notoriety…
I work in a Website that offers news of IT and Open Source.
I pretend that I do it for the sake of love for IT, but the fact is that, I am expecting good revenues for the
future…
If not, why should I loose my time looking for IT news in other IT Web Sites that offer what I am not able to
offer… for the sake of these IT weirdos geeks and Open source-free computing fanboys…? c’mon…
I think I know more than the rest, of course… and I am always right!
Yes, I know more than anyone of you about Computers, and about anything else you can imagine! even If many people prove me the contrary, I am still right…
Me and my Mac go together everywhere, I even sleep with it, which is somehow problematic, cause as you can imagine, is not easy to have sexual relations tru an USB port, or a FireWire one… but I am in love anyway!…
Anything that is not Mac or commercial, is just wacko rubbish!
And, of course, is not going to offer me anything, because all these Open Source weirdos have no future, and are not gonna advertise in my site, or pay me money… I dont even talk about the FSF retarded hippies!
At best the big companies that now move to Linux, and pretend to be Open Source, worth a little bit, and may be a source of revenues in the future if the have some sucess…
Cheers…
P.S. Apple Rocks… Linux sucks… (MS is very good also, cause they have plenty of money, and are the pattern of our great western Businnes Economic and social system…)