Slashdot Mirror
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."
Most mainstream distributions already do this. For example: Fedora Core, Suse, and many others.
Danial Howard
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.
That the OS does it allows older systems to be much more useful. By ignoring whatever crap the BIOS says, my FreeBSD system can use a >8gb drive in a system with motherboard that does not support large drives. However, with a bios still there, the system can be used by a system that relies on it.
"I use a Mac because I'm just better than you are."
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...
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
Basically, they found that rhgb (which is often turned off by Redhat Engineers) is wasting a lot of time and doesn't accomplish anything. Removing it would increase bootspeed.
Single Board Computer. A computer with almost everything (sometimes even storage by way of flash/nvram) on a single board.
Vote for global prefs bug
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.
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.