From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MnIUI-00035F-SP for mharc-grub-devel@gnu.org; Mon, 14 Sep 2009 16:49:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnIUF-00033t-WC for grub-devel@gnu.org; Mon, 14 Sep 2009 16:49:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnIUB-00030s-0b for grub-devel@gnu.org; Mon, 14 Sep 2009 16:49:23 -0400 Received: from [199.232.76.173] (port=44143 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnIUA-00030i-LN for grub-devel@gnu.org; Mon, 14 Sep 2009 16:49:18 -0400 Received: from mail-bw0-f220.google.com ([209.85.218.220]:56591) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnIU9-0003q4-Ie for grub-devel@gnu.org; Mon, 14 Sep 2009 16:49:18 -0400 Received: by bwz20 with SMTP id 20so2489970bwz.42 for ; Mon, 14 Sep 2009 13:49:10 -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 :content-transfer-encoding; bh=3/x0myYP8PXDsuyffFH4VFOknfdWceJ9ROZXoFiJq50=; b=qfLRMZEHKq7nY89mHTn7k38P5o9RN4S2sYAOHH20tvPjRl7FlfaDDFtRoojYSbUX3t Zu/yDLBgPf3obv3iMzYV4aiMWThmUsey8gGCDnFfwFhfapEq5wNNoBZxTQpHT5CVWiMo c8NDcJ9Up4luK6PGhKrmQCE9PvGcjevCsdwG4= 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:content-transfer-encoding; b=ZtO6JPlgJrXptSgtfAAdL7Aqb8qE4E4wV3TswbPGlOG16eIwrYk1mhjsYZT3WjIASt RnrGISDkYBPstUE9dItrRJdk9oyUoL5+EHTSRQGbESXSckxu5HhE7tnh3lEaBSkpbBBy /hSxVjR04Gzi56tlwv+Nk9u6lbspEWL2B0YcQ= MIME-Version: 1.0 Received: by 10.204.152.214 with SMTP id h22mr5577681bkw.197.1252961348922; Mon, 14 Sep 2009 13:49:08 -0700 (PDT) In-Reply-To: References: <1252505468.2998.16.camel@fz.local> <20090911131709.GC7959@thorin> <20090912125452.GB11249@thorin> <20090914153226.GA25403@thorin> <1252955497.4336.5.camel@mj> Date: Mon, 14 Sep 2009 22:49:08 +0200 Message-ID: From: "Vladimir 'phcoder' Serbinenko" To: The development of GRUB 2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:49:24 -0000 On Mon, Sep 14, 2009 at 10:12 PM, Brendan Trotter wrot= e: > 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. =A0We co= uld 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. =A0There is functional ATA support, USB support >> is under development. > > But, are you doing it for valid technical reasons? > Yes. I have a borked firmware right on this laptop. >> 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". > Firmware if present is left in usable state. However it may simply not be present. > 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. Have you actually read the multiboot specification? Booter passes info about memory and video mode in mbi (video for multiboot isn't implemented yet). If you need firmware for basic bootup you're clearly doing something wrong and are firmware-dependent. Of course it's your freedom to make suboptimal software. > 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. Just say in clean text what changes you need so we can discuss it. Don't expect us to understand the statement "your standard is borked, change it". > > The current draft (http://grub.enbug.org/MultibootDraft) is a small > step in the right direction; but it has changed much in 3 years. > It mainly introduces multi-CPU and another MBI format compared to multiboot= 1 >>> 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". > Read it here: http://www.gnu.org/software/grub/manual/multiboot/multiboot.h= tml > > Cheers, > > Brendan > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > --=20 Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git