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."
Compatibility/fallback?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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 - aka cheap-and-nasty thing with no cards. Add power and boot.
-D
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.
You can press ESC when Windows it loading, at least for the Windows 98 series, and it gives your autoexec and config.sys anyway if you have them set to echo. Windows 2000 and XP booting into safemode have verbose boots.
Saskboy's blog is good. 9 out of 10 dentists agree.
Some people don't use the framebuffer drivers because they have a "better" xorg driver and they might be incompatible. So bootsplash doesn't work. What you can use is rhgb. When entering runlevel 5 it loads X ASAP during the boot process and has a special progress screen. When it's time to load XDM/GDM the greeter script kills rhgb but keeps the X session for itself. (This is important because if X went down and then up again, you'd have to sit through two screen blank-outs while the monitor gets re-probed)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Basically, the BIOS has to manage the hardware before the OS boots. You can't rely on the OS to find the boot hard drive to load the OS from, or to arrange RAM to run the BIOS, or to interact with the user to configure the BIOS settings to determine what to boot from. This means that the BIOS has to understand the video card somewhat, hard drives, keyboards, mice, USB for some of these, PCI for others, IDE, SCSI, and so forth.
But it doesn't have to be efficient at any of it, because you're not going to do very much with the system as handled by the BIOS. It doesn't matter if you don't use DMA to load the bootloader, because it's small and you do it once per boot.
They are not cheap-and-nasty. They are primarily for embedded development, and can be quite expensive. They usually have everything a modern computer needs: ethernet, multi-megabyte storage, RAM, graphics adapter, etc. Most of the time a low-power CPU (like ARM) or an older x86 (486 or early Pentium). Sometimes they even include a small LCD display.
Vote for global prefs bug
Just between where the login screen appears and the end of boot system dies. A little bug. Found it on 2 ghz or faster machines due to the short time of boot.
You can even do it after pressing ESC. It is simpler to do that way.
SuSE (at least 9.x) has this splash window you refer to.
No. Very few modern systems use the PCI BIOS to gather information on the bus. Accessing the PCI controller directly and probing for devices is not difficult amd reliably allows the OS to detect devices such as PCI bridges which the BIOS may not report properly or even may not recognise.
Besides, the if you follow the links from the fedora-devel post you refer to, all you get is a couple of png images of the boot processes.
That's because the project just started then. Here's the project page now with documentation and more samples:
www.bootchart.org
Ziga
It's Single Board Computer.
The most common computers out there. Probably outnumber desktops 10 to 1.
Maybe the kernel is freezing for a while, rather than the startup scripts.
/etc/lilo.conf in yours) cures this for me.
Just on the off-chance......got a motherboard that supports serial-ATA ? My kernel would hang for 30 seconds trying to detect a (non-existant) second ATA disk. Adding "hdg=noprobe" to the kernel boot line (/boot/grub/menu.lst in my case, maybe something like
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.