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."
What I like about Linux is never having to reboot except when it is time for a kernal upgrade. :)
Originally posted on the debian-devel list: http://lists.debian.org/debian-devel/2004/11/msg00 547.html
They could have at least made sure the arrows on the diagrams were round the right way!
Code, Hardware, stuff like that.
What I like about Linux is never having to reboot except when it is time for a kernal upgrade. :)
And when it crashes. Seriously tho, Linux requires too much rebooting compared to BSD. I'm talking years of uptime here.
But I still found that article as boring as hell!
99 bottles of beer in 175 characte
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?
I'd rather you do it wrong, than for me to have to do it at all.
what's SBC? Single Box Computer? Server? System? what?
Like, you know, a monolithic kernel?
Now I understand the boot process much better, I always have started at the boot up process and wonder what the hell is Linux doing to my computer, eh, I guess I understand now better in how it boots, I want to see a comparsion between Linux and Windows... newb linux user here loves it but hates ATI support.
May
The article makes an interesting read (although the server is getting slow already), but it seems a bit short on commentary. I'm no expert on the low-level systems of Linux, so the bare facts are quite interesting, but I would have been more interested to read a comparison of the merits of the different systems.
My impression, from the article, is that x86 versions of Linux are carrying quite a lot of legacy (from DOS et al). Does this mean that Linux on other architectures is "better" in any sense? I don't know, but I'd be interested if someone can inform.
apterous.org
I've always found it disconcerting that a verbose boot is given by default. Before Linux goes main stream on the home desktop, the distros ought to slap a plain progress bar with a pretty picture [ie. Windows clouds or logos] and not show verbose details unless something is wrong with the boot, or unusual.
Saskboy's blog is good. 9 out of 10 dentists agree.
Time to stop trusting that the arrows if emergency exit signs are right now too?
i've noticed on SuSE that it now comes with a boot splash screen (a la Windows loading...). I know that's (somewhat) easily turned off, but really, I don't want my linux to be all fisher-price pretty. give me the rough and unadulterated command lines that are run when it boots up...make it look cool, make it intimidating, give it that matrix-esque feel...make it scare off all the n00bs that think they know everything.
This sig contains repetition and redundancy.
And here i Present you the BSD boot process
1) birth
2) death (confirmed by netcraft)
I've always wished Windows would do verbose boot by default! I find nothing more disconcerting than having a Win system hang at boot with nothing but a damn logo to look at!
Aren't you cool
Give something like Mandrake or Fedora Core a try. The only times I see that it doesn't give a graphical boot with the text hidden is when frame buffers don't work with that video card.
The last thing we want to see is more people using Linux.
Frickin' noobs, eh?
--
the strongest word is still the word "free"
Contents:
The x86 Linux boot process
The non-x86 Linux boot process
A few alternatives
Summary
Resources
About the author
Rate this article
Related content:
Migrating from x86 to PowerPC, Part 1
Standards and specs: Open Firmware -- the bridge between power-up and OS
Subscriptions:
dW newsletters
Design notes for hardware and firmware involved in booting embedded Linux
Level: Introductory
Lewin Edwards (sysadm@zws.com)
Design Engineer
08 Feb 2005
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.
This article describes the most common traits of embedded Linux(TM) distributions that people employ on x86 hardware and contrasts some of the different options frequently seen on non-x86 embedded systems.
By the time a system has booted itself to the point where it can run your application-level code, any one variant of Linux is, practically by definition, largely similar to another. However, there are several different methodologies that you can use to get the system from power-on reset to a running kernel, and beyond that point, you can construct the filesystem in which your application will run in different ways.
Each approach has its own distinct advantages and disadvantages, and a definite, two-way relationship exists between the hardware you choose to implement and the way you will structure the power-up and Initial Program Load (IPL) process. Understanding the software options available to you is a critical part of the research you must do before designing or selecting hardware.
The x86 Linux boot process
The most fundamental and obvious difference between x86 boards and embedded systems based on PPC, ARM, and others is that the x86 board will ship with one or more layers of manufacturer-supplied "black box" firmware that helps you with power-on initialization and the task of loading the operating system out of secondary storage. This firmware takes the system from a cold start to a known, friendly software environment ready to run your operating system. Figure 1 is a diagram of the typical PC boot process, with considerably more detail than you tend to find in PC-centric literature:
Figure 1. Typical start-up process for x86 Linux
Typical start-up process for x86 Linux
For cost reasons, modern PC mainboard BIOS code is always stored compressed in flash. The only directly executable code in that chip is a tiny boot stub. Therefore, the first task on power-up is to initialize the mainboard chipset enough to get the DRAM controller working so that the main BIOS code can be decompressed out of flash into a mirror area in RAM, referred to as shadow RAM. This area is then write-protected and control is passed to the RAM-resident code. Shadow RAM is permanently stolen by the mainboard chipset; it cannot later be reclaimed by the operating system. For legacy reasons, special hardware mappings are set up so that the shadow RAM areas appear in the CPU's real-mode memory map at the locations where old operating systems like MS-DOS would expect to find them.
Keep in mind that the PC is an open architecture. This openness even extends down to firmware modules within the BIOS itself. Once the power-on initialization (POI) code has run, the next step it takes is to enumerate peripherals, and optionally install hooks provided by expansion ROMs in those peripherals. (Some of those expansion ROMs -- for instance, the video BIOS in a system that has onboard integrated video hardware -- will physically reside in the main BIOS image, but conceptually they are separate entities). The reasons the BIOS has to do this redundant initialization are:
1. Th
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.
From the Slashdot submission:
And from the actual article: 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.Please!!
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.
Don't blame me, I voted for Kodos
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
The same applies to boot splash screens. The verbose screen lets you know exactly where a fault is occurring, so you have some hope of fixing it.
You also get a much better idea of how far you are from a useful desktop, by seeing the service names. A simple progress meter rarely updates consistently, so it doesn't really give a good estimate of how much time is left.
That's an interesting point about keeping the user informed, even if they don't realize it. I suppose it could be more useful for troubleshooting if the last thing to freeze onto the screen is the process that is failing to load completely, but from the computers of long ago, to the modern Windows computer, a boot screen is usually just one screen long, after the POST, and essentially just says [OS] loading ...
...
From the Apple ][e, to the Radio Shack Tandys, to MS-DOS 3.3, to Windows 98, these highly sucessful home user systems had a simple boot screen that didn't scroll drivers and vxds unless told to do so.
There's a difference between informing a user, and making them think they may be in over their head with technobabble about abbreviated system file names that only programmers have any idea as to their function. Perhaps if the driver's real world, translated name were used, such as keyboard driver loaded is displayed instead of loading kb.sys
Saskboy's blog is good. 9 out of 10 dentists agree.
...I alway find that is one of the funner things with linux from day one after my first install, even if I haven't a clue what the hell is going on. I just sit there hyp-mo-tized -> LOOKATHERGO! DANGTHASCOOL!
kinda fun in an admittedly strange way, it's also cool to see how your leet speed reading is, if you can keep up.
A couple of other posts refer to this indirectly.
Bootchart is actually some of the coolest use of graphical display of data I have seen in a while:
bootchart
Some of the Solaris 10 guys even used it to improve the boot process on new releases of Solaris 10.
The latest updates (as of a few days ago) continued to streamline the system.
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.
Small Block Chevy
You're not a nerd! I bet you even have a girlfriend and/or tattoo!
it wasn't real kiddie porn, but if you want to see some, type "russian teens" into your google toolbar. russia's age of consent is 14.
Remember the moment.
Explaining LILO. Friends. Relatives are not impressed.
" Is that all it is. A window with a few buttons. "
Of. Technological proficiency. Knowing.
Boot code articulated with " plain," intelligible language.
Embedded. Operating Systems. Kernel Versions. RAM.
ROM. Isn't this the boy reared by wolves?
Frank Lloyd Wright. For what it's worth. Logic boards.
Black-Box-Firmware-HelperCode. Good article.
And. That Linux perspective. Linear.
I wanted to learn about the private parts.
Parallelize Linux system services to improve boot speed
boooyaca.
Some people go mountain climbing, some people skydive, and some people even get into boxing and martial arts.
But to me, nothing says manly man like booting into Linux without the splash screen. That, and I can get the same BO that they can by just not bathing for a few days. People don't tease me for my Super Mario tattoo anymore.... well, they seem to avoid me as a general rule so they probably couldn't determine what it is anyway... maybe a big mole or something... but hey, that's the studly vibe I wanted to portray anyway!
Hoo-ah!
I know there are various logs, but I've some things I want to investigate in boot process and hell if i can find it, looking it dmesg, /var/log. I wish there was a way to store the ENTIRE boot process in one log. Is there?
lol.. a reboot might have got you up and running again sooner, huh? ;)
Seriously... for hot swapping PCI, you need a mobo that specifically supports it. It has something to do (or everything to do?) with extra grounding to handle shorting, I believe.
Hot swapping would definitely be useful for cutting down on reboots. Not sure if it's possible with AGP though.
Parallelize Linux system services to improve boot speed.
I haven't tried it yet (am about to), but for Gentoo there is Gensplash
Phillip.
Property for sale in Nice, France
- displaying the logo
- displaying loading linux.....
- displaying loading init_rd.....
- the screen is cleared and the words Uncompressing linux... Ok, booting the kernel.
I found the relevent bit of code in linux/arch/i386/boot/compressed/misc.cI also found a reset_terminal() in linux/drivers/char/console.c but tweaking it doesn't seem to help.
I could go for the bootsplash patch, but that adds nearly 200K to the (compressed) kernel.
I don't really want to as I'd be happy to just have the Uncompressing linux... line under my syslinux logo (640x480x16 colours only adds 10K to the distribution). After that, all the kernel messages are sent to /dev/ttyS1 so they don't appear on the screen.
So, anybody knows where in the kernel source (preferably 2.4) is the screen cleared? Any clues I could follow?
bundaegi is good for you
I'm not sure if the boot code uses the BIOS to clear the screen or does it by itself. If it uses the BIOS, look for references to int 0x10 in the code.
If it clears it itself, look for a memory address of 0xb8000, that is the address of the text-mode screen buffer.
That was rather poetic. Take a moment and absorb some culture.
Linux Kernel 2.4 Internals. Subsection 1.6 points to a initialise console step in init/main.c:start_kernel()
...and why does the PC have to boot in the outdated 16-bit console environment? The PC's strange boot environment forces operating systems to jump through hoops in order to load the kernel. Isn't it time for all PCs to boot in 32-bit flat mode (unprotected, without paging)?
Thou'rt quite the hakker!