Anatomy of the Linux Boot Process

Donna writes "This article discusses detailed similarities and differences involved in booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices."

Comments

The good thing about Linux

[X43B]

What I like about Linux is never having to reboot except when it is time for a kernal upgrade. :)

Re:The good thing about Linux

[Claire-plus-plus]

What I like about Linux is never having to reboot except when it is time for a kernal upgrade. :)

Or hardware installation :)

Re:The good thing about Linux

[Quasar1999]

Or hardware installation :)

About that... I've unsuccessfully tried hotswapping an AGP video card once... I spent the rest of the day looking up motherboard, ram, and video card prices online... using another computer... I'll let you figure out why...

Re:The good thing about Linux

[MikeCapone]

That is a good point, but it doesn't mean that the boot process can't be sped up quite a bit.

It would especially be useful on laptops, or for people who like to save electricity by shutting down their computers when not in use.

What a Debian system looks like when booting

[El Cubano]

http://seehuhn.de/comp/bootlog.html

Originally posted on the debian-devel list: http://lists.debian.org/debian-devel/2004/11/msg00 547.html

Proof reading?

[FyRE666]

They could have at least made sure the arrows on the diagrams were round the right way!

Re:Proof reading?

[larwe]

Hi, I'm the author of this article series, and I was steered here by my publication contact at IBM (I don't get much time to read /. - right now I'm working at a day job, this article series, my third book and some contract embedded systems engineering). Anyway, I swear to you (and can email you the original PNG!) that *I* got the arrows the right way around. Unfortunately, someone in IBM's graphics department was apparently DUI operating Adobe Illustrator. I don't always get a chance to proof the graphics before an article gets published; and that was the case for this one. I got a bite at the text, but didn't see the massaged graphics until the article hit the web. I've already poked my end of the chain to get that fixed. To people who find the article boring, I've got two comments: a) It's part of a series. I can't assume much about my readership, so I had to spend essentially the entire first three articles doing groundwork to explain what's happening in the system and why, and how to get a functional development environment working on the box. Article #4 starts giving some actual code, and article #5 will start giving some actual circuits. Unfortunately, IBM sets the release schedule, and that means you have to wait a month between episodes. They also set the article length limits, which means I can only put so much in each instalment. b) Not everything in those three articles is obvious to the lay person. Although I didn't have enough space to go into great detail, I tried to communicate some useful information I've learned in practical 32-bit systems implementation (for commercial purposes). Remember that the target audience is primarily people who are accustomed to building x86-based embedded Linux apps, and many of these people will not know or care about much of the infrastructure under their app.

I have a computer science degree

[Claire-plus-plus]

But I still found that article as boring as hell!

Arrows

[Bios_Hakr]

I really hate to nit-pick, but any editor should have caught that the arrows in the flow chart point the wrong way.

Anyway, I've often wondered why the OS insists on redetecting hardware when BIOS does it for me already. I've heard that the LinuxBios actually does away with the hardware detect phase; leaving it solely to the kernel.

If the most popular OSes out there are taking care of HW at the high level, why haven't BIOS makers taken advantage of this to reduce their workload?

Re:Arrows

[teknomage1]

Tradition! Seriously though, BIOS code is very old and designed to provide for the least common denominator.

The BSD boot process

[Anonymous Coward]

And here i Present you the BSD boot process

1) birth
2) death (confirmed by netcraft)

Re:Speaking of linux booting...

[yamcha666]

The distributions of Linux that are aimed for the main stream home desktop do use some type of a bootsplash.

The most notable example I can give is Xandros. The booting process shows an animated Xandros logo with very general boot details such as detecting hardware... done, and Loading Kernel ... done.

The distros that usually don't offer a type of bootsplash by default are aimed for us power users because we want to know what's going on.

Re:Speaking of linux booting...

[arkhan_jg]

most modern distros do now, especially the livecd's and home-user orientated distros, the software that does it is called bootsplash. It relies on you having a graphic card/monitor supported by the frame buffer drivers though, so don't expect it to work on a 486. It comes in two flavours; a high res virtual terminal with a background image, or silent mode which just has a pretty screen and a progress bar until it launches gdm/kdm etc.

If it's a server/professional workstation, the services boot loader is probably more useful. I'd sure like to have one on windows when I'm trying to troubleshoot a boot problem, without having to use safe mode - especially if the problem doesn't show up in safe mode...

Should be "BIOS" vs. "known hardware"

[pchan-]

This article glosses over one point that is very critical. That is, in an embedded system, the hardware is known at compile time, as well as all the details of initializing it. On a desktop PC, the hardware configuration is a mystery everytime you boot. Who knows, maybe the user decided to move their network card to a different PCI slot and now it has a different memory address, add a hard drive, remove a sound card, take out half the RAM. This makes the boot process far more complicated. The BIOS method of dealing with this situation is archaeic and painful to use, but it works. That is, you can boot even the dumbest OS (say, DOS, or that memtest86 iso) without having that PS know anything about the hardware.

Having written a few embedded bootloaders (and modified some others), I will say that booting an embedded device is far far easier than booting a device who's hardware (that is critical to booting) can change between boots.

Stop plagiarizing!

[Osty]

From the Slashdot submission:

This article discusses detailed similarities and differences involved in booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices.

And from the actual article:

This installment of "Migrating from x86 to PowerPC" discusses detailed similarities and differences between booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices.

Replacing the string "This installment of "Migrating from x86 to PowerPC"" with "This article" and replacing the word "between" with the phrase "involved in" is not sufficient to serve as summarization in the submitter's own words. Somehow I have a hard time believing that the submitter "Donna" and the article author Lewin Edwards are one and the same person. If I'm wrong, then fine. You can't plagiarize yourself. If I'm correct, then Slashdot's done it again. The article summary isn't an original work by Donna, but a minor modification of the article author's own summary, and should be properly attributed as such.

My boot process

[i.r.id10t]

Open the office, turn on the computer, walk out of the office, walk across campus to the cafeteria while ogling the young college chicks, get a cup of coffee, walk back, log in, do work.

Re:Speaking of linux booting...

[SEE]

Bruce Tognazzini, founder the Apple Human Interface Group and fomer Apple Human Interface Evangelist, disagrees.

Some might be surprised to learn, however, that not only do I accept the idea of having flashing updates, such as "loading the kernel," I actually embrace it. First, it keeps the user engaged, and an engaged user is a happy user. Second, it informs. Yes, I'm aware that the only kernel most people are aware off is armed with eleven herbs and spices, but that's because no one has ever introduced them to the UNIX/LINUX kernel.

In ancient times, before there was disk, we all used tape cassettes to store our applications. We could literally hear them as they loaded into the computer over a period of one to three minutes. (Thank heavens today's hard disks are a million times faster so that, for example, Excel can load in only a few microseconds.) One might assume the sound of a loading program would be indistinguishable from random noise, but that proved not the case. Every application and every image had a unique signature. After a while, we could tell if we'd started the wrong program just by the sound of its code.

Today, few modem users understand handshaking protocols, but they do become used to a familiar pattern of clicks and screeches indicating normal vs. abnormal connections.

If regular folk can come to "understand" on some level the sound of high-speed binary code, do you think they cannot absorb some lessons from being subjected to new terminology like "kernel," etc.? Such terms so often come to be useful, as when some system software programmer spits out some horrifying message like, "fatal execution of kernel." At least they won't fear their supply of fried chicken is about to be cut off.

Entertain them. Teach them a little something, even if it seems "way over their heads." At the very least, it will keep them awake and alert.