-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/06/12 05:33 AM, Richard Yao wrote: > On 06/21/2012 04:08 AM, Duncan wrote: >> 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! >> > > A firmware replacement for the BIOS does not need to worry about > floppy drives, hard drives, optical drives, usb devices, isa > devices, pci devices and pci express drives, etcetera, because > those live on buses, which the kernel can detect. It would need a > device tree to inform the kernel of what buses are available, but > that would be specific to a given board, rather than what is > attached to it. If the end user makes hardware changes, the kernel > should be able to handle that, with the exception of changes > involving RAM, which I believe go into the device tree.
I take it the above statement is based on the kernel being directly placed within the BIOS/firmware/nvram on the board, such that you couldn't boot anything else but that kernel? Otherwise I don't see how you could get away with the BIOS not worrying about all those devices.. IE, I don't forsee many general x86 users giving up their ability to boot off usb stick or cdrom or pxe based on a boot-time bios choice, or to boot windows or alternative linux kernels (which could be located who knows where) at whim. And I don't see how an alternative BIOS would be able to provide this ability without dealing with all the things Duncan mentioned... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU 7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI =CwME -----END PGP SIGNATURE-----
