Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: Killing UEFI Secure Boot
Date: Thu, 21 Jun 2012 08:08:39 +0000 (UTC)
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



Replies:
Re: Re: Killing UEFI Secure Boot
-- Richard Yao
References:
Re: Killing UEFI Secure Boot
-- Rich Freeman
Re: Killing UEFI Secure Boot
-- Richard Yao
Re: Killing UEFI Secure Boot
-- Richard Yao
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Killing UEFI Secure Boot
Next by thread:
Re: Re: Killing UEFI Secure Boot
Previous by date:
Re: [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags
Next by date:
Re: My wishlist for EAPI 5


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.