Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Anatomy of the Linux Boot Process

Zonk posted more than 9 years ago | from the step-one-turn-on-computer dept.

Hardware 170

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."

cancel ×

170 comments

Sorry! There are no comments related to the filter you selected.

Did I... (0, Offtopic)

daskalou (815182) | more than 9 years ago | (#11648641)

Make first post?!?

Re:Did I... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11648716)

values of ß will give rise to dom!

Re:Did I... (-1, Offtopic)

vistic (556838) | more than 9 years ago | (#11648724)

Yes!

Re:Did I... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11648966)

fag.

The good thing about Linux (5, Insightful)

X43B (577258) | more than 9 years ago | (#11648647)

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 (4, Insightful)

Claire-plus-plus (786407) | more than 9 years ago | (#11648660)

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 (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11648718)

Someone in my networking class in High School hotplugged a NIC once. Neither the nics, or the mainboard supported it. It also had windows 98.

It did't die. It actually detected it, installed the drivers, and the link went up. The old drivers simply threw up an "im not working" error in the device manager.

Re:The good thing about Linux (0)

Anonymous Coward | more than 9 years ago | (#11648892)

You are such a liar. Most if not all network setting changes require a reboot in windows 98. I'm not just talking about drivers, i'm talking ip addresses and network masks.

Re:The good thing about Linux (0)

Anonymous Coward | more than 9 years ago | (#11649014)

He is not. If you use DHCP, then this works. If you don't, it doesn't.

Re:The good thing about Linux (2, Funny)

Taladar (717494) | more than 9 years ago | (#11649095)

...and then he had to reboot to change the description of his PC in the Network Neighbourhood...

Re:The good thing about Linux (1)

ArbitraryConstant (763964) | more than 9 years ago | (#11649116)

I had a dying NIC that did pretty much the same thing with XP...

I don't use that NIC or Windows anymore, but credit where credit is due.

Re:The good thing about Linux (1)

vasqzr (619165) | more than 9 years ago | (#11649236)

I've done the same thing with modems, but never a NIC card. Interesting.

Re:The good thing about Linux (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11648935)

Or lowmem fragmentation/exhaustion. :)

Or a process stuck in I/O wait. :)

Or NFS gets confused. :)

Humility and knowledge of one's own weaknesses please!

Re:The good thing about Linux (1)

bloo9298 (258454) | more than 9 years ago | (#11649624)

Or a process stuck in I/O wait. :)

Real men just use a hex editor on /proc/kcore to remove the process. :-)

Re:The good thing about Linux (5, Funny)

Quasar1999 (520073) | more than 9 years ago | (#11649003)

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 (0, Redundant)

Aadain2001 (684036) | more than 9 years ago | (#11649103)

Well, you should have checked BEFORE the experiment that your equipment actually supported it. The software may have no issues, but if the mobo and/or card didn't support it, there is nothing the OS can do to keep the magic smoke it :)

Re:The good thing about Linux (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11649232)

unsuccessfully tried hotswapping an AGP video card once... I spent the rest of the day looking up motherboard, ram, and video card prices online

Ah, it's not for softies, but hot-swapping a peripheral card has been done [folklore.org] .

-1, Offtopic (0, Troll)

Anonymous Coward | more than 9 years ago | (#11648678)

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.

s/Linux/BSD/;


Re:The good thing about Linux (4, Insightful)

MikeCapone (693319) | more than 9 years ago | (#11649043)

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.

Re:The good thing about Linux (0)

Anonymous Coward | more than 9 years ago | (#11649066)

apart from when it reboots itself arbitrarily and for no reason

What a Debian system looks like when booting (5, Interesting)

El Cubano (631386) | more than 9 years ago | (#11648651)

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

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

Re:What a Debian system looks like when booting (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11648876)

No, this is more like what a debian system looks like booting:

Starting debian...............

garbage garbage garbagee garbagee garbagee garbage
l;kajsdf;lkjasl;f;lksajf;lskajf;lsjf;lksj a
asdfljkas;fdljasde garbagee garbagee garbage
fe garbagee garbagee garbagee garbage
asfasfd;lksajf;lskajf;lsjf;lksja
asfdase garbagee garbagee garbage
fasfasdfs;lksajf;lskajf;lsjf;lksja
asfda sfe garbagee garbageasfd
asfasdfe garbagee garbageasdfasdf
asdfase garbagee garbageasfdasdf
dfasdfasdfj;lksajf;lskfjsdl;fkjs; ldkjf;
garbage garbage garbageasdfasdfasdfasdf
garbage garbage garbagegarbage garbage garbage
asdfkjasd;lfe garbageasdfasdfsadf
askflj;asdjfke garbageasasdfasdfasdfasdfasdf
asdflkjaslfde garbageasdfasdfasdasdffasdf
garbage garbage garbageasfdasdfasdfasdf
l;kajsdf;lkjasl;f;lksajf; lskajf;lsjf;lksja
asdfljkas;fdljasde garbageasdfasdfasdfsadfsadf
garbage garbage garbagee garbagee garbagee garbage
l;kajsdf;lkjasl;f;lksajf;lskajf;lsjf;lksj a
asdfljkas;fdljasde garbagee garbagee garbage
fe garbagee garbagee garbagee garbage
asfasfd;lksajf;lskajf;lsjf;lksja
asfdase garbagee garbagee garbage
fasfasdfs;lksajf;lskajf;lsjf;lksja
asfda sfe garbagee garbageasfd
asfasdfe garbagee garbageasdfasdf
asdfase garbagee garbageasfdasdf
dfasdfasdfj;lksajf;lskfjsdl;fkjs; ldkjf;
garbage garbage garbageasdfasdfasdfasdf
garbage garbage garbagegarbage garbage garbage
asdfkjasd;lfe garbageasdfasdfsadf
askflj;asdjfke garbageasasdfasdfasdfasdfasdf
asdflkjaslfde garbageasdfasdfasdasdffasdf
garbage garbage garbageasfdasdfasdfasdf
l;kajsdf;lkjasl;f;lksajf; lskajf;lsjf;lksja
asdfljkas;fdljasde garbageasdfasdfasdfsadfsadf
fe garbagee garbagee garbageasfdasdf
asfasfd;lksajf;lskajf;lsjf;lksja
asfdase garbagee garbageasdfasdfsadfadsf
fasfasdfs;lksajf;lskajf;l sjf;lksja
asfdasfe garbagee garbageasdfsadsdafasdfsfgarbage garbage garbagee garbagee garbagee garbage
l;kajsdf;lkjasl;f;lksajf;lskajf;lsjf;lksj a
asdfljkas;fdljasde garbagee garbagee garbage
fe garbagee garbagee garbagee garbage
asfasfd;lksajf;lskajf;lsjf;lksja
asfdase garbagee garbagee garbage
fasfasdfs;lksajf;lskajf;lsjf;lksja
asfda sfe garbagee garbageasfd
asfasdfe garbagee garbageasdfasdf
asdfase garbagee garbageasfdasdf
dfasdfasdfj;lksajf;lskfjsdl;fkjs; ldkjf;
garbage garbage garbageasdfasdfasdfasdf
garbage garbage garbagegarbage garbage garbage
asdfkjasd;lfe garbageasdfasdfsadf
askflj;asdjfke garbageasasdfasdfasdfasdfasdf
asdflkjaslfde garbageasdfasdfasdasdffasdf
garbage garbage garbageasfdasdfasdfasdf
l;kajsdf;lkjasl;f;lksajf; lskajf;lsjf;lksja
asdfljkas;fdljasde garbageasdfasdfasdfsadfsadf
fe garbagee garbagee garbageasfdasdf
asfasfd;lksajf;lskajf;lsjf;lksja
asfdase garbagee garbageasdfasdfsadfadsf
fasfasdfs;lksajf;lskajf;l sjf;lksja
asfdasfe garbagee garbageasdfsadsdafasdfsf

and so on.. 1 million miles an hour.

Re:What a Debian system looks like when booting (3, Informative)

burns210 (572621) | more than 9 years ago | (#11648893)

Or, you could post to the article that inspired yours(and was cited in it), regarding the Fedora boot process. here [redhat.com] .

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.

Re:What a Debian system looks like when booting (3, Interesting)

El Cubano (631386) | more than 9 years ago | (#11649216)

Or, you could post to the article that inspired yours(and was cited in it), regarding the Fedora boot process.

That was not my post. I just remember seeing it on debian-devel. 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. The guy who did the Debian version explains how he did it and also provides links to the necessary tools.

Proof reading? (4, Insightful)

FyRE666 (263011) | more than 9 years ago | (#11648653)

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

Re:Proof reading? (1)

BLAG-blast (302533) | more than 9 years ago | (#11649204)

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

Glad somebody else noticed that, atleast it was only in the x86 section. I figure the author was trying to research how many readers who click on the link look at the FA and are not part of some Cultural Denial Of Service attack.

How many of you have clicked on a link just to hurt the server? How many have clicked refresh just to see how long the server stays up?

Feel free to post anonymously if you're ashamed.

Re:Proof reading? (0)

Anonymous Coward | more than 9 years ago | (#11649229)

The FA is hosted on an IBM webserver, it's probably one of the few places that can happily take a Slashdotting.

Re:Proof reading? (0)

Anonymous Coward | more than 9 years ago | (#11649214)

I assumed that I couldn't understand those diagrams because I didn't understand what I was looking at. If its just acase of the arrows actually being around the wrong way then that explains it, and I agree, they really should have proof "Read" those diagrams.

Re:Proof reading? (0)

Anonymous Coward | more than 9 years ago | (#11649333)

Yeah, and I can't for the life of me figure out that loop on the bottom, even ignoring the arrows.

PowerPC isn't standards based like x86 is. (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#11648679)

It could never match the performance of say, nicely tuned opteron/hammer.

I have a computer science degree (4, Funny)

Claire-plus-plus (786407) | more than 9 years ago | (#11648684)

But I still found that article as boring as hell!

Re:I have a computer science degree (3, Funny)

j1bb3rj4bb3r (808677) | more than 9 years ago | (#11648776)

But I still found that article as boring as hell!

If you had an EE degree, you might find it more interesting... but then likely everyone else would find *you* boring as hell.

Re:Lacking CS Degree. (0)

Anonymous Coward | more than 9 years ago | (#11649705)

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.

Arrows (5, Interesting)

Bios_Hakr (68586) | more than 9 years ago | (#11648701)

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 (2, Informative)

X0563511 (793323) | more than 9 years ago | (#11648754)

Compatibility/fallback?

Re:Arrows (5, Insightful)

teknomage1 (854522) | more than 9 years ago | (#11648761)

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

Re:Arrows (2, Insightful)

Apreche (239272) | more than 9 years ago | (#11648844)

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?

Because if you buy a motherboard and the BIOS on it makes it so that the computer will only work with Windows XP, server 2k3 and linux kernel 2.4+ people will be pissed. Some people might still want to run DOS, OS/2, Windows 95/98, kernel 2.2, or some other old busted operating system. It's there for that reason. With a linux bios your computer can pretty much only run Linux. Which is fine if that's all you want to run.

Oh, and BIOS makers don't have more workload. They've pretty much mastered making that part of the BIOS. They just have to slightly modify their BIOSes for each motherboard that comes out and update them to deal with the newest chips.

Re:Arrows (3, Informative)

0racle (667029) | more than 9 years ago | (#11648864)

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.

Re:Arrows (3, Interesting)

Anonymous Coward | more than 9 years ago | (#11648875)

On a PCI system, the OS doesn't really "detect" hardware -- at least not in the old Win95 sense of poking registers to figure out what's there.

The OS just asks the BIOS for a list of PCI ID values, and loads the appropriate drivers for those IDs.

Re:Arrows (1)

tristanj (797805) | more than 9 years ago | (#11649125)

One of the reasons for the OS redetecting hardware is that relying on the BIOS is less portable, and sometimes BIOS has limitations which the OS doesn't.

Re:Arrows (2, Informative)

iabervon (1971) | more than 9 years ago | (#11649173)

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.

Re:Arrows (1)

prockcore (543967) | more than 9 years ago | (#11649498)

Anyway, I've often wondered why the OS insists on redetecting hardware when BIOS does it for me already.

I'm actually glad that it does. We did the TiVo hack, and our bios didn't see the tivo harddrive at all. Luckily, linux saw it just fine and was able to mount it without a problem.

acronymfinder.com didn't help (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11648704)

what's SBC? Single Box Computer? Server? System? what?

Re:acronymfinder.com didn't help (2, Informative)

Anonymous Coward | more than 9 years ago | (#11648898)

Single Board Computer - aka cheap-and-nasty thing with no cards. Add power and boot.

-D

Re:acronymfinder.com didn't help (2, Informative)

Repugnant_Shit (263651) | more than 9 years ago | (#11649193)

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.

Re:acronymfinder.com didn't help (3, Informative)

Repugnant_Shit (263651) | more than 9 years ago | (#11648918)

Single Board Computer. A computer with almost everything (sometimes even storage by way of flash/nvram) on a single board.

Re:acronymfinder.com didn't help (0)

Anonymous Coward | more than 9 years ago | (#11648934)

Small Block Chevy

Imposter!!! (1, Funny)

Anonymous Coward | more than 9 years ago | (#11649633)

Small Block Chevy

You're not a nerd! I bet you even have a girlfriend and/or tattoo!

Re:acronymfinder.com didn't help (1)

virtualone (768392) | more than 9 years ago | (#11648944)

Spam BroadCast

describes important design pitfalls (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11648707)



Like, you know, a monolithic kernel?

Re:describes important design pitfalls (0)

Anonymous Coward | more than 9 years ago | (#11648774)

All hail HURD! ... don't hurt me?

Re:describes important design pitfalls (3, Funny)

psetzer (714543) | more than 9 years ago | (#11649044)

How the mighty have fallen! I'd never expect to see Andrew Tanenbaum trolling Slashdot as AC.

Re:describes important design pitfalls (0)

Anonymous Coward | more than 9 years ago | (#11649515)

The superiority of modular design hasn't been validated scientifically and never will be. It's purely a matter of personal preference.

Linux Boot (3, Interesting)

jon855 (803537) | more than 9 years ago | (#11648710)

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.

Re:Linux Boot (2, Insightful)

Taladar (717494) | more than 9 years ago | (#11649105)

You got it wrong. Not the Linux Support for ATI is bad but the ATI Support for Linux is.

Re:Linux Boot (0)

Anonymous Coward | more than 9 years ago | (#11649548)

And it'll never improve due to the fact that linux users will never standardize on a single desktop distribution.

Re:Linux Boot (1)

grolschie (610666) | more than 9 years ago | (#11649648)

ATI drivers are not so bad. Performance is pretty good really (I dual boot with 98SE and play ET on both). So they're not as easy to install as NVidia's, but hey this is Linux and we don't mind getting our hands dirty. err... well I use Debian so I don't mind. :-)

Re:Linux Boot (0)

Anonymous Coward | more than 9 years ago | (#11649566)

I still don't understand why Linux takes 10 minutes to boot up. It is way too slow.

Re:Linux Boot (0)

Anonymous Coward | more than 9 years ago | (#11649617)

Because of all the scripts that l1nux c0d3rz like to execute before init tosses control to the login processes.

More discussion? (3, Interesting)

mistersooreams (811324) | more than 9 years ago | (#11648721)

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.

Re:More discussion? (2, Funny)

Anonymous Coward | more than 9 years ago | (#11648933)

"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."

Once Linux has booted, it should not matter much.

It is more the overall architecture that is better in the sense that it is "cleaner".

For example, you don't need an extended/logical partition hack, you can have 32-64 equivalent partitions on a PowerPC with OpenFirmware (~BIOS~).

If you take a Mac for example. To boot, the OpenFirmware can read directly the HFS (MacOS) and load the kernel. Actually, you could put your Linux kernel on OS X partition to boot it... But most people install a boot loader on a bootstrap partition (minimum is 800KB, compare that with a max of less than 512 bytes on x86 for first stage...). The boostrap is actually a HFS filesystem.

So the boot for Linux on Mac hardware is:
OpenFirmware ---> boot loader (in one stage) ---> load Linux kernel on ext2, reiserfs or other. With 800KB you have enough space to put code to read on several file system type.

In the IBM article, they are talking about embedded system, the firmware loads directly the kernel in mem no need to load "intermediate software" called the boot loader.

What is really stupid is the lengthy/complex process for x86-embedded. Windows for embedded stuff (Win CE?) is flexible and does not need the BIOS... neither does Linux...

Re:More discussion? (0)

Anonymous Coward | more than 9 years ago | (#11649568)

Linux isn't carrying anything from DOS other than optional FAT filesystem support.

BIOS loads boot loader, boot loader loads kernel, kernel loads init, init runs a bunch of scripts which in turn load the TTY/login processes. It's really not that complicated.

Speaking of linux booting... (3, Insightful)

saskboy (600063) | more than 9 years ago | (#11648723)

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.

Re:Speaking of linux booting... (2, Interesting)

Claire-plus-plus (786407) | more than 9 years ago | (#11648775)

Mandrake 10.1 doesn't have verbose as default. It has a boring little progress bar. However, I prefer verbose mode gives me something to read while my computer is booting.

Re:Speaking of linux booting... (3, Insightful)

supercowpowers (834391) | more than 9 years ago | (#11649543)

After struggling with making my grandparents computer work with the Windows ME "recovery cd" that came with the computer (they didn't tell me I was going to be working on it, and didn't have the best of resources at hand...), I finally decided to just bite the bullet and install Debian and Gnome on it.

I know, I know, Debian isn't exactly your "grandmother's distribution", but the distro in question is pretty irrelevant once I get to the point.

Anyway, I set it up so they basically couldn't screw it up. They don't know the root password, GDM is set to automatically log in their user (yes, their, hilarity would ensue trying to get them to understand the concept of users) on boot, and the desktop has I think 5 icons, "user's home", "Computer", "Pogo Games" (they love this for some reason), "E-Mail" (evolution), "Internet" (loads google in firefox), and "Trash".

They had to learn very few things to use this system, mainly what the icons do (which is easy because I made them visually huge and self explanatory), and how to shut down (Actions menu, not the Start menu)

Some other measures I put into place, like making a backup of /home so I could log in remotely and fix it (I had to do this once, because one day the icon for pogo games magically disappeared, even though they "Didn't do anything, I swear!"), but this is really turning rambly really quick...just to give you an idea of how idiot-proof the thing is.

They haven't had problems with it in about 2 months (since I installed it). Their usage is very basic, and this configuration serves them very well, since I can control the interface to be much less full of surprises than Windows.

So the world is all well and rosy...well...not quite...

I took no measures to clean up the default boot process, so it still outputs 'garbage' like
APM Bios version 1.2 Flags 0x02 (Driver version 1.2)
Entry f000:c64e cseg16f000 dseg f000 cseg len ffff, dseg len ffff
Connection version 1.1
AC off line, batter status high, battery life 82
[and so on...]
It fills the entire screen, and scrolls by so fast they couldn't comprehend it even if they knew what it all meant.

So I've counted about 5 times so far where my grandmother asks something like, "Now, is all that writing going to come up for good now?" It really, deeply bothers them to see all that as opposed to a pretty Windows logo. Not that I blame them.

So, that progress bar might be 'boring' to you, but it's blissful simplicity to somebody like my grandparents.

(FWIW, I prefer to see it all on a 1024x768 framebuffer, because I want to know when something is configured wrongly but can still pass that stage failing silently)

Re:Speaking of linux booting... (3, Informative)

dmhoward (779000) | more than 9 years ago | (#11648790)

Most mainstream distributions already do this. For example: Fedora Core, Suse, and many others.

Danial Howard

Re:Speaking of linux booting... (4, Informative)

yamcha666 (519244) | more than 9 years ago | (#11648801)

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... (1)

mattyrobinson69 (751521) | more than 9 years ago | (#11648806)

suse does this by default, not sure about other home distro's as i use gentoo myself.

Speaking of Windows booting... (1)

xtermin8 (719661) | more than 9 years ago | (#11648820)

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!

Re:Speaking of Windows booting... (2, Informative)

saskboy (600063) | more than 9 years ago | (#11649023)

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.

Re:Speaking of Windows booting... (1)

Luigi30 (656867) | more than 9 years ago | (#11649154)

If you press ESC at the wrong time, however, it causes a protection fault and hangs the computer.

Re:Speaking of Windows booting... (1)

daveb (4522) | more than 9 years ago | (#11649194)

If you press ESC at the wrong time, however, it causes a protection fault and hangs the computer.

you've got a problem with your install then. I routinly do that and have never ever had that happen

Login screen way to late. (1, Informative)

Anonymous Coward | more than 9 years ago | (#11649603)

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.

Re:Speaking of Windows booting... (1)

niteice (793961) | more than 9 years ago | (#11649537)

2000/XP don't really have a verbose boot, just a list of drivers and such being loaded and then an NT4-style info screen (Microsoft Windows Version 5.1 (Build 2600)) if you boot with the /sos switch.

Tried a modern distro? (0)

Anonymous Coward | more than 9 years ago | (#11648849)

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.

Re:Speaking of linux booting... (4, Informative)

arkhan_jg (618674) | more than 9 years ago | (#11648870)

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...

Or something based off rhgb... (2, Informative)

Ayanami Rei (621112) | more than 9 years ago | (#11649076)

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)

Re:Speaking of linux booting... (4, Interesting)

SEE (7681) | more than 9 years ago | (#11649285)

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.

Re:Speaking of linux booting... babble (1)

saskboy (600063) | more than 9 years ago | (#11649518)

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 ...

funny.... (2, Funny)

zogger (617870) | more than 9 years ago | (#11649536)

...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.

Fire safety and misdirected arrows? (3, Funny)

Anonymous Coward | more than 9 years ago | (#11648770)

Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer.

Time to stop trusting that the arrows if emergency exit signs are right now too?

don't like the splash screens (3, Interesting)

LiquidMind (150126) | more than 9 years ago | (#11648772)

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.

Wow (0)

Anonymous Coward | more than 9 years ago | (#11648839)

Aren't you cool

Damn right (2, Funny)

SweetAndSourJesus (555410) | more than 9 years ago | (#11648879)

The last thing we want to see is more people using Linux.

Frickin' noobs, eh?

Re:don't like the splash screens (1)

rpozz (249652) | more than 9 years ago | (#11648889)

In that case, you probably want to use something like Gentoo. SuSE is designed to be a workstation for an average user.

Splash screens when things go wrong (1)

AnotherScratchMonkey (592037) | more than 9 years ago | (#11649097)

I like to tell people that Windows is nice when everything is working the way you expect, but terrible to debug when the unexpected happens, because it's so hard to dig useful information out of the system.

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.

Re:don't like the splash screens (0)

Anonymous Coward | more than 9 years ago | (#11649583)

i just wrote a brainfuck REPL OS that fits in a 512-byte boot sector. want it? $699.

The BSD boot process (5, Funny)

Anonymous Coward | more than 9 years ago | (#11648800)

And here i Present you the BSD boot process

1) birth
2) death (confirmed by netcraft)

The article: (0, Redundant)

killa62 (828317) | more than 9 years ago | (#11648922)

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. The main BIOS itself needs basic console services to announce messages and allow the user to override default start-up behavior and configure system-specific parameters.
2. Historical issues limit the size of a user-supplied bootloader program to slightly less than 512 bytes. Since this isn't enough space to implement all the possible device drivers that might be required to access different displays and storage devices, it's necessary for the BIOS to install standardized software interfaces for all installed, recognized hardware that might be required by the bootloader.

Once all the BIOS-supported system peripherals are initialized, the main BIOS code will run through candidate boot devices (in accordance with a user-configurable preference list) looking for a magic signature word. Storage devices for IBM®-compatible PCs have historically used a sector size of 512 bytes, and therefore the BIOS only loads the first 512 bytes from the selected boot device. The operating system's installation program is responsible for storing sufficient code in that zone to bootstrap the remainder of the IPL process.

Although it would be possible to write a minimalist Linux bootloader that would fit into such a space, practical Linux bootloaders for the PC consist of two stages: a small stub that lives in the boot sector, and a larger segment that lives somewhere else on the boot medium, usually inside the partition that contains the root filesystem. LILO and grub are the best-known bootloaders for mainstream Linux installations, and SYSLINUX is a popular choice for embedded distributions.

Using a RAMdisk
The primary purpose of the bootloader is to load the operating system kernel from secondary storage into RAM. In a Linux system (x86 or otherwise), the bootloader can also optionally load an initial RAMdisk image. This is a small filesystem that resides entirely in RAM. It contains a minimal set of modules to get the operating system off the ground before mounting the primary root filesystem. The original design purpose for initial RAMdisk support in the kernel was to provide a means whereby numerous optional device drivers could be made available at boot time (potentially drivers that needed to be loaded before the root filesystem could be mounted).

You can get an idea of the original usage scenario for the RAMdisk by considering a bootable Linux installation CD-ROM. The disk needs to contain drivers for many different hardware types, so that it can boot properly on a wide variety of different systems. However, it's desirable to avoid building an enormous kernel with every single option statically linked (partly for memory space reasons, but also to a lesser degree because some drivers "fight" and shouldn't be loaded simultaneously). The solution to this problem is to link the bare minimum of drivers statically in the kernel, and to build all the remaining drivers as separately loadable modules, which are then placed in the RAMdisk. When the unknown target system is booted, the kernel (or start-up script) mounts the RAMdisk, probes the hardware, and loads only those modules appropriate for the system's current configuration.

Having said all that, many embedded Linux applications run entirely out of the initial RAMdisk. As long as you can spare the memory -- 8MB is usually more than enough -- it's a very attractive way of organizing your system. Generally speaking, this is the boot architecture I favor, for a few reasons:

1. The root filesystem is always writeable. It's much less work to have a writeable root than it is to coerce all your other software to put its temporary files in special locations.
2. There is no danger of exhausting flash memory erase-modify-write lifetimes or of corrupting the boot copy of the root filesystem, because the system executes entirely out of a volatile RAM copy.
3. It is easy to perform integrity-checking on the root filesystem at boot time. If you calculate a CRC or other check value when you first install the root filesystem, that same value will be valid on all subsequent boots.
4. (Particularly interesting to applications where the root filesystem is stored in flash) You can compress the boot copy of the root filesystem, and there is no run time performance hit. Although it's possible to run directly out of a compressed filesystem, there's obviously an overhead every time your software needs to access that filesystem. Compressed filesystems also have other annoyances, such as the inability to report free space accurately (since the estimated free space is a function of the anticipated compression ratio of whatever data you plan to write into that space).

Other x86 boot considerations
Notice a few other points from Figure 1. The first is that the color coding is meaningful. In the blue boxes, the system is running BIOS code and accessing all system resources through BIOS calls. In the green boxes, the system is running user-provided code out of RAM, but all resources are still accessed through BIOS calls. In the yellow boxes, the system is running Linux kernel code out of RAM and operating out of a RAM disk. Hardware is accessed through the Linux device driver architecture. The purple boxes are like the yellow boxes, except that the system is running out of some kind of secondary storage rather than a RAMdisk. The rules being followed in the gray box are system-specific.

You'll observe from this that there are two possible boot routes (actually, more) once the kernel has been loaded. You can load an initial RAMdisk and run entirely out of that, you can use the initial RAMdisk and then switch over to a main root filesystem on some other storage medium, or you can skip the initial RAMdisk altogether and simply tell the kernel to mount a secondary storage device as root. Desktop Linux distributions tend to use the latter design model.

Also note that there is an awful lot of redundant code here. The BIOS performs system tests and sets up a fairly complex software environment to make things cozy for operating systems like MS-DOS. The Linux kernel has to duplicate much of the hardware discovery process. As a rule, once the kernel loads, none of the ROM-resident services are used again (although there are some exceptions to this statement), yet you still have to waste a bunch of RAM shadowing that useless BIOS code.

The non-x86 Linux boot process
In contrast to the x86's complex boot process, an embedded device like the Kuro Box jumps as directly as possible into the operating system. Although there are extant standards for implementing firmware interfaces (equivalent to the PC ROM-BIOS) in PowerPC® systems, these standards are rarely implemented in embedded appliances. The general firmware construction in such a system (assuming that it is based on Linux) is that the operating system kernel, a minimal filesystem, and a small bootloader all reside in linearly-accessible flash memory.

At power-up, the bootloader initializes the RAM controller and copies the kernel and (usually) the initial RAMdisk into RAM. Flash memory is typically slow and often has a narrower data bus than other memories in the system, so it's practically unheard of to execute the kernel directly out of flash memory, although it's theoretically possible with an uncompressed kernel image.

Most bootloaders also give the user some kind of recovery interface, whereby the kernel and initial RAMdisk can be reloaded from some external interface if the flash copies are bad or missing. Off-the-shelf bootloaders used in these applications include blob, U-Boot and RedBoot, although there are others -- and there are many applications that use utterly proprietary bootloaders. Figure 2 illustrates a typical start-up flow for a non-x86 embedded Linux device:

Figure 2. Typical start-up process for PPC or ARM Linux
Typical start-up process for PPC or ARM Linux

Observe that, as for the x86 startup process above, you have the same possible different routes once the kernel has been loaded. Also note that once control passes to the kernel, the boot process is identical to what it was on the x86. This is to be expected: the further you get in the boot process, the more the software environment is defined by the operating system's API specification rather than the vagaries of the underlying hardware.

The layout of flash memory
The exact layout of such a system in flash memory depends on two principal factors: the flash device sector size (usually in the neighborhood of 64KB), and the processor's power-on-reset behavior. A core like ARM, which starts execution at address 0, will put the bootloader at the bottom of flash. A core like x86 will need to put the bootloader at the top.

There are at least two, and generally four, entities that need to be installed in flash: the bootloader (mandatory), an optional parameter block providing nonvolatile storage for boot options, calibration data and other information, the Linux kernel itself (again, mandatory), and almost always an intial RAMdisk image. For example, a layout for a 4MB flash chip with a 64KB sector size might be as follows:
Listing 1. Typical layout of a 4MB flash chip

000000-01FFFF Bootloader (128KB)
020000-02FFFF Parameter block (64KB, probably mostly unused)
030000-1FFFFF Kernel (1.8MB)
200000-3FFFFF Initial RAMdisk image (2MB)

While it is possible to write these various segments across sector boundaries (and it is especially tempting in the case of the parameter block, which will likely be more than 99% empty), this is an extremely unwise practice and should be avoided unless you are under terribly severe flash space constraints. It is particularly vital that the bootloader should reside in a private segment that can be left write-protected. Otherwise, a failed firmware upgrade operation may leave the system entirely inoperable. Good system engineering should provide a safe fallback position from any possible user-initiated upgrade process.

The only part of this software bundle that absolutely must be preloaded at the factory is the bootloader. Once the system is startable from that boot code, you can use other (end-user-accessible) interfaces to load the kernel and RAMdisk image.

Why not do this on x86?
By the way, at this point the attentive reader may be wondering why embedded PC applications can't use a special boot ROM that simply loads the operating system kernel directly off disk (or some other medium).

The answer to this is that while it's possible to write a custom cut-down bootstrap program for a PC motherboard (see, for example, the LinuxBIOS project), the types of applications that use PC hardware tend to be using the board as a black box. Typically, the system integrator will not even have access to datasheets or schematics for the board; they can't write a bootstrap program even if they want to. Furthermore, PC operating systems are built on the assumption that lowest-common-denominator BIOS services are available, at least at boot time. In other words, it's a simple fact that the path of least resistance is so much easier than a fully custom alternative that practically nobody tries to do it the "smart" way. The inefficiencies of the multi-layer BIOS approach are lost in the noise (as it were) compared with the overall system specifications.

Having digested all the above, assuming you understand approximately how large your various software modules will be, you are well prepared to select flash and RAM sizes and layouts for a custom embedded system. Kuro Box happens to use a very uncomplicated memory architecture. It has a single 4MB linear flash chip and 64MB SDRAM. While this is the simplest design, it is not necessarily the cheapest, and you may wish to consider other alternatives if you are designing your own system.

A few alternatives
One hardware architecture that I have used with some success, and which I have also seen in a few other commercial products, is to use a very small, cheap (generally narrow-bus) OTP EPROM as the primary boot device. This chip is factory-programmed with just enough bootstrap code to load the main firmware image off a secondary storage device and check its integrity. It is very useful if you can also include a little additional intelligence so that the secondary storage device can be reloaded from some external source -- removable media, a serial port, Ethernet, USB or something else -- if the main firmware image becomes corrupted.

An attractive choice of storage device for the main image is NAND flash, which is cheaper than the linear NOR flash used by Kuro Box. NAND flash is produced in vast quantities for removable storage devices: CompactFlash cards, USB "pen disks," Secure Digital (SD) cards, MP3 players, and so on. Although it is possible, with a minimal amount of external logic, to graft NAND flash onto a normal flash/ROM/SRAM controller (such as that in the MPC8241), there are a couple of reasons why you can't simply boot directly out of the NAND flash. The first is that NAND is not guaranteed error-free; it's the host's responsibility to maintain ECC and bad sector mapping information. The second reason is that NAND flash is addressed serially; you send the chip a block number, then read the block out into RAM. Hence, you need a little boot firmware on a normal random-access PROM to do the physical-level management of the NAND. (See Resources for more on NAND and NOR.)

Note that some microcontrollers provide hardware NAND controllers that obviate the need for the little boot PROM I discussed above. The disadvantage of relying entirely on that sort of hardware is that you lose the failsafe system-recovery features that can easily be implemented in the boot PROM. However, if you're working against space or cost constraints, and your micro has the NAND control hardware, you may want to avail yourself of it. SoCs sold for cell phone applications use this sort of technology.

Summary
By now you should understand many of the design choices to be made when building your embedded Linux distribution and selecting the memories in which it will reside and run. You should also understand the way parts of your software distribution can be spread between a RAMdisk and secondary storage devices. The next article gets into the gory details of the software preloaded on the Kuro Box and sets the stage for some real development work.

Resources

* This article is the second in a series; the series started with an overview of migrating from x86 to PPC (developerWorks, January 2005).

* Tired of waiting for the BIOS to probe hardware? You may be able to load the kernel directly (developerWorks, May 2004).

* The LinuxBIOS project is a BIOS replacement for x86 PCs. It directly boots the Linux kernel and requires no secondary storage.

* Das U-Boot is a flexible and popular bootloader for numerous different hardware architectures.

* The blob bootloader (Boot Loader OBject) is a small, easy-to-use bootloader designed for ARM systems.

* Red Hat's RedBoot bootloader is actually a miniature operating system, based on the eCos product, also from Red Hat. It is very flexible and has been ported to many platforms.

* This Toshiba presentation describes some of the structure and advantages of NAND flash memories (versus NOR).

* Red Hat offers a fairly detailed x86-centric description of the Linux start-up and shutdown process.

* This useful article discusses how to write code that lives in the Master Boot Record (MBR).

* A recent developerWorks article, Standards and specs: Open Firmware -- the bridge between power-up and OS, covers the Open Firmware boot loader environment (developerWorks, October 2004).

* IBM has some related material in Linux Handbook: A Guide to IBM Linux Solutions and Resources (IBM Redbook, 2003).

* Find more Linux-related resources at the IBM developerWorks Linux zone and the developerWorks Linux on Power Architecture Developer's corner.

* Have experience you'd be willing to share with Power Architecture zone readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside IBM are welcomed. Check out the Power Architecture author FAQ to learn more.

* Have a question or comment on this story, or on Power Architecture technology in general? Post it in the Power Architecture technical forum or send in a letter to the editors.

* The Power Architecture Community Newsletter includes full-length articles as well as recent news about members of the Power Architecture community and upcoming events of interest. Subscribe to the newsletter today!

* All things Power are chronicled in the developerWorks Power Architecture editors' blog, which is just one of many developerWorks blogs.

* Find more articles and resources on Power Architecture technology and all things related in the developerWorks Power Architecture technology content area.

* Download a Power Architecture Pack to demo a SoC in a simulated environment, or just to explore the fully licensed version of Power Architecture technology. This and other fine Power Architecture-related downloads are listed in the developerWorks Power Architecture technology content area's downloads section.

About the author
Lewin A.R.W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years developing x86, ARM and PA-RISC-based networked multimedia appliances at Digi-Frame Inc. He has extensive experience in encryption and security software and is the author of two books on embedded systems development. He can be reached at sysadm@zws.com.

Re:The article: (1, Funny)

Anonymous Coward | more than 9 years ago | (#11649036)

Because IBM is so easily slashdotted.

Re:The article: (3, Funny)

grozzie2 (698656) | more than 9 years ago | (#11649211)

I _think_ the ibm site can handle a /. swarm. No need to karma whore this one.

Shit... (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11648940)

is the ULtimate roots and gets on declined in market

Should be "BIOS" vs. "known hardware" (4, Informative)

pchan- (118053) | more than 9 years ago | (#11648941)

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! (4, Insightful)

Osty (16825) | more than 9 years ago | (#11648953)

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.

Stop posting these sucky IBM DevWorks articles (0)

Anonymous Coward | more than 9 years ago | (#11648964)

Please!!

Re:Stop posting these sucky IBM DevWorks articles (0)

Anonymous Coward | more than 9 years ago | (#11649083)

That's right descriptions of computer boot processes could help terrorists to construct a time machine. They are un-American. If you support detailed IBM Dev articles about Linux boot processes you support acts of internationaal terrorism.

My boot process (5, Funny)

i.r.id10t (595143) | more than 9 years ago | (#11649006)

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.

minigirls (-1, Troll)

Anonymous Coward | more than 9 years ago | (#11649089)

What happened to all the people posting kiddie porn? That was hilarious!

Re:minigirls (0)

Anonymous Coward | more than 9 years ago | (#11649634)

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.

bootchart site moved. (2, Interesting)

Iamnoone (661656) | more than 9 years ago | (#11649557)

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 [bootchart.org]
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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>