From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ShcSv-0004B6-2g for garchives@archives.gentoo.org; Thu, 21 Jun 2012 08:10:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BA331E08A5; Thu, 21 Jun 2012 08:09:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 533DCE04ED for ; Thu, 21 Jun 2012 08:09:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B2C6B1B400F for ; Thu, 21 Jun 2012 08:09:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5.5 tests=[AWL=-0.573, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_z36Qiy0ZV9 for ; Thu, 21 Jun 2012 08:08:58 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 9A8751B401B for ; Thu, 21 Jun 2012 08:08:56 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ShcRc-0003DI-5J for gentoo-dev@gentoo.org; Thu, 21 Jun 2012 10:08:48 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jun 2012 10:08:48 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jun 2012 10:08:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Killing UEFI Secure Boot Date: Thu, 21 Jun 2012 08:08:39 +0000 (UTC) Message-ID: References: <4FE0F922.2090807@gentoo.org> <4FE1230D.8090502@gentoo.org> <1a28c6af40914cf5b6b5559bd0195a1b@HUBCAS1.cs.stonybrook.edu> <4FE24BB7.3000904@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.138 (Der Geraet; GIT f50ed2b /usr/src/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 09bc3783-c138-4aac-b1c4-286923b8080b X-Archives-Hash: 4e01a66bcfe4c89e5af2a1448d4831f7 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 mad= e > it work or is x86 fundamentally harder? I can answer this one. x86 is harder at the bootloader stage, but in=20 turn easier, or perhaps simply different, at the kernel and kernel device= =20 interface level. Consider, most MIPS and ARM systems ship with a specific set of basic=20 devices, configured to use specific IO addresses, IRQs, etc, and that's=20 it, at least to get up and running (USB devices, etc, may be able to be=20 plugged in, but they're not normally needed for boot). If you've been=20 keeping up with the kernel (say via LWN, etc), this has been one of the=20 big deals with the ARM tree recently, as until now each "board" had its=20 own hard-coded kernel config directly in the tree, and it was getting=20 unmanageable. They're switching to "device tree", etc, allowing the boot= =20 loader to feed the kernel a file with this information at boot time, thus= =20 allowing a whole bunch of different boards to boot off the same shipped=20 kernel, while at the same time getting the explosion of individual board=20 files out of the kernel tree. This is a BIG deal on ARM and similar=20 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= =20 pretty much everything. memory, storage (consider floppy, hard drive,=20 optical disk either direct or el-torito, USB stick, etc, all bootable and= =20 all end-user changable!), even quantity and speed of CPUs, and the=20 firmware BIOS (or replacement) must cope with that and be able to boot=20 off it. Even back in the 386 era when everything was jumper-configured,=20 users could still change pretty much everything out, other than the mobo=20 itself. Now days, it's even MORE complex, as most of these devices can=20 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=20 configured in ordered to be operable for the intended use. Sure, the=20 BIOS CAN leave some of it for the kernel to do, but other bits, not so=20 much, as otherwise, how does the kernel even get loaded -- the BIOS must=20 pick one of the many boot options, configure it (as well as the CPU and=20 the system between storage and the CPU, storage chipset, memory, etc) at=20 least well enough to read in the boot loader and/or kernel. None of=20 that's necessary on ARM, etc, because (pretty much) everything there's a=20 totally arbitrary-as-shipped config, nothing to dynamically negotiate and= =20 get working before the kernel or secondary bootloader (after the BIOS)=20 can even work! --=20 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