From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MnHuU-0000UC-V5 for mharc-grub-devel@gnu.org; Mon, 14 Sep 2009 16:12:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnHuT-0000U4-UW for grub-devel@gnu.org; Mon, 14 Sep 2009 16:12:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnHuP-0000Tg-9p for grub-devel@gnu.org; Mon, 14 Sep 2009 16:12:25 -0400 Received: from [199.232.76.173] (port=38842 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnHuP-0000Td-49 for grub-devel@gnu.org; Mon, 14 Sep 2009 16:12:21 -0400 Received: from mail-yx0-f202.google.com ([209.85.210.202]:50929) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnHuO-0004Zw-Qu for grub-devel@gnu.org; Mon, 14 Sep 2009 16:12:21 -0400 Received: by yxe40 with SMTP id 40so4347742yxe.28 for ; Mon, 14 Sep 2009 13:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/+w1qU3H+BLDq70TraK55jdCICVRkM/Nlm2pk3aY0H8=; b=VeOXnPCdX+q6STfSLxs/saLPV62ETp2koeQDNMA43NPG4ljVobFXlDgTNBGQXIms5G gHacyMr+ncTvMO+vbQIfaofp0CAZMeCVIkH+WbkNkJORN+Q6M2SKD3ulrKG6iy10tj8G TSTVfTNCZzl1mNvXhO3AOVPvsIpTzxLsLrkIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ZecffNcsoYefP/Gn+eAKZKIzQxOLVy5JwLH69FG9LfvDjtxx1h1AM2HdWq7cf3X6I0 yGxQDrTFCWUMK1kasHX0/Woa+DYRbpXQYF5Xdf4jDt56UNElbshqxj1CD4xLzfMZ1AqN W1UOIaXJY7TRspe6O3Yh9vp0CzwicH6uAdWY8= MIME-Version: 1.0 Received: by 10.150.175.1 with SMTP id x1mr10855137ybe.45.1252959139586; Mon, 14 Sep 2009 13:12:19 -0700 (PDT) In-Reply-To: <1252955497.4336.5.camel@mj> References: <1252505468.2998.16.camel@fz.local> <1252587711.2908.38.camel@fz.local> <20090911131709.GC7959@thorin> <20090912125452.GB11249@thorin> <20090914153226.GA25403@thorin> <1252955497.4336.5.camel@mj> Date: Tue, 15 Sep 2009 05:42:19 +0930 Message-ID: From: Brendan Trotter To: The development of GRUB 2 Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: About firmware facilities X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 20:12:26 -0000 Hi, On Tue, Sep 15, 2009 at 4:41 AM, Pavel Roskin wrote: > On Tue, 2009-09-15 at 04:27 +0930, Brendan Trotter wrote: >> Hi, >> >> On Tue, Sep 15, 2009 at 1:02 AM, Robert Millan wrote: >> > Well, you have the freedom to disagree with anything we do and bring your >> > customized GRUB to a different direction :-) >> > >> > Anyhow, my priority for GRUB is strong driver-based support. We could recruit >> > someone to develop the framework in next year's GSoC (unless somebody steps >> > in, of course). >> >> Why stop there? >> >> If proprietory ethernet ROMs aren't good enough, then what about >> proprietory SCSI ROMs, and proprietory firmware/BIOS? > > We are already doing it. There is functional ATA support, USB support > is under development. But, are you doing it for valid technical reasons? > GRUB can serve as BIOS together with Coreboot. I know. It'll break my code. The multi-boot specification says "However, other machine state should be left by the boot loader in normal working order, i.e. as initialized by the bios (or DOS, if that's what the boot loader runs from)."; although I seem to remember it saying words to the effect of "the firmware should be left in a usable state". Due to limitations in the original multi-boot specification my code switches back to real mode and uses the BIOS to do memory detection, do video mode detection, switch video modes and gather other information. If GRUB is running on coreboot or UEFI I can't do this (and can't work around the limitations any other way). Unless the multi-boot specification is changed significantly (such that a multi-boot compliant code needs no work-arounds, or at least so that multi-boot compliant code can determine what sort of firmware there was and use the firmware) then GRUB as a whole becomes useless to me. The current draft (http://grub.enbug.org/MultibootDraft) is a small step in the right direction; but it has changed much in 3 years. >> Why are you worrying about such silly things when the multi-boot >> specification (which actually is relevant) is still severely borked? > > Patches are welcome. I'm not sure it's possible to write patches for a multi-boot compliant boot loader without a specification that defines "multi-boot compliant". Cheers, Brendan