Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted: > 3. How does getting a x86 system to boot differ from getting a MIPS > system or ARM system to boot? Does it only work because the vendors made > it work or is x86 fundamentally harder?
I can answer this one. x86 is harder at the bootloader stage, but in turn easier, or perhaps simply different, at the kernel and kernel device interface level. Consider, most MIPS and ARM systems ship with a specific set of basic devices, configured to use specific IO addresses, IRQs, etc, and that's it, at least to get up and running (USB devices, etc, may be able to be plugged in, but they're not normally needed for boot). If you've been keeping up with the kernel (say via LWN, etc), this has been one of the big deals with the ARM tree recently, as until now each "board" had its own hard-coded kernel config directly in the tree, and it was getting unmanageable. They're switching to "device tree", etc, allowing the boot loader to feed the kernel a file with this information at boot time, thus allowing a whole bunch of different boards to boot off the same shipped kernel, while at the same time getting the explosion of individual board files out of the kernel tree. This is a BIG deal on ARM and similar embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all. Meanwhile, on x86, the system must be prepared for end-user switch-out of pretty much everything. memory, storage (consider floppy, hard drive, optical disk either direct or el-torito, USB stick, etc, all bootable and all end-user changable!), even quantity and speed of CPUs, and the firmware BIOS (or replacement) must cope with that and be able to boot off it. Even back in the 386 era when everything was jumper-configured, users could still change pretty much everything out, other than the mobo itself. Now days, it's even MORE complex, as most of these devices can be configured in dozens or hundreds of mode combinations via "plug-n- pray", and they often don't /have/ a default -- they **MUST** be so configured in ordered to be operable for the intended use. Sure, the BIOS CAN leave some of it for the kernel to do, but other bits, not so much, as otherwise, how does the kernel even get loaded -- the BIOS must pick one of the many boot options, configure it (as well as the CPU and the system between storage and the CPU, storage chipset, memory, etc) at least well enough to read in the boot loader and/or kernel. None of that's necessary on ARM, etc, because (pretty much) everything there's a totally arbitrary-as-shipped config, nothing to dynamically negotiate and get working before the kernel or secondary bootloader (after the BIOS) can even work! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
