From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OoavN-00045G-OF for mharc-grub-devel@gnu.org; Thu, 26 Aug 2010 07:47:17 -0400 Received: from [140.186.70.92] (port=54842 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoavL-00044R-EJ for grub-devel@gnu.org; Thu, 26 Aug 2010 07:47:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoavJ-0002tL-QE for grub-devel@gnu.org; Thu, 26 Aug 2010 07:47:15 -0400 Received: from mail-qy0-f176.google.com ([209.85.216.176]:61270) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoavJ-0002tH-O1 for grub-devel@gnu.org; Thu, 26 Aug 2010 07:47:13 -0400 Received: by qyk2 with SMTP id 2so1761537qyk.0 for ; Thu, 26 Aug 2010 04:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=i9Oo1p52lHiGPu4H0nTZqVxM5/3gtUXZAMjy3ki+XVQ=; b=Ny1XlP4YJR7MjNNLzgHFsqqiyBIW66lls+MmQF3nFQo35gxLOl8QVym4SAmssG8TAG g9wA7Uz9cJ1gnm8dpPhL1TMBsifMRIQb04PG98BSmkpuaManYQFfeez0hQ682RwIk/AQ oQ8485ZU8GwUy7UbbCbR4jQd87oS28//8bd5U= 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=FRY4aNqAB0wLaOxbTzK5Y/MGgx8XFP+Urm9+Wb6WU6WgMNAV7AsQ9wuPKyJnqimqh9 d1Owjio3CyNcs7m31EVUcCvMh3MXslizK9sjdIHqwaKQjawhK7P7bMn8KjrswrcarywR E1GhgaoeF9rMNEs3SYKsOfJkVKrBq97PNMKOY= MIME-Version: 1.0 Received: by 10.229.232.14 with SMTP id js14mr443434qcb.103.1282823232393; Thu, 26 Aug 2010 04:47:12 -0700 (PDT) Received: by 10.229.1.158 with HTTP; Thu, 26 Aug 2010 04:47:12 -0700 (PDT) In-Reply-To: References: <4C747249.4080205@gmail.com> <4C74E602.1060308@gmail.com> <4C762609.303@gmail.com> <4C76415C.2060609@gmail.com> Date: Thu, 26 Aug 2010 13:47:12 +0200 Message-ID: From: "Vladimir 'phcoder' Serbinenko" To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Completely disable graphics support in grub2 x86_64-efi X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 11:47:17 -0000 On Thu, Aug 26, 2010 at 1:25 PM, KESHAV P.R. wrote: > No one in the windows world know much about gpt, leave alone uefi. One > of the advantages of open-source world is the direct user-developer > interaction which in Microsoft's case is not possible. You have what you choose > >>> =A0like linux or grub2 >>> allows. If you to try the DUET firmwares you can download it from >>> http://tiano-efi-duet-folder-sk.4shared.com/ where I have given >>> instructions on how to set it up (requires windows). >>> >>> >> EDK2 can be compiled with mingw under GNU/Linux. >> You don't approach the problem from right angle. Rather than trying to >> make grub work under DUET with all the incurring penalties you should >> look into loading DUET from GRUB. If DUET supported multiboot it would >> be trivial. I would recommend suggesting multibootor multiboot2 to DUET >> guys. With lack of those you need to stick to chainloader. >>> > > In the starting I tried to chainload DUET from grub2 bios, the duet > bootsector fails to find the Efildr20 and it did not work (I tried a > min of 10 times) . Nicest way would be to implement multiboot for efildr.-d do it myself (and I still might). If I had more time I efildr might be loadable by ntldr command. Also if you chainload be sure to use dumped sector and not the one from the compiled result. > I gave up trying to chainload DUET and instead > started using grub2 uefi through DUET. It's usually better to make sane way work than reverting to suboptimally designed one. > I like the way UEFI works The main part visible to user is loading files instead of sectors. This is a good decision. However the rest is a mess. Also coreboot+grub loads files too. > and I > have no plans to revert back to MBR partitioning for the sake of > windows compatibility. Robert investigated the issue following my idea of replacing MBR sector on BIOS read calls. It was enough to make bootmgr work on non-hybrid GPT. However ntoskrnl fails early. With some runtime patching I think it's possible to achieve the goal however nobody investig > The tianocore guys recommended using OVMF under qemu or VirtualBox for > UEFI booting, but the prblem is I want UEFI booting in real hardware > using my real HDD (not some virtual HDD file). With OVMF grub-efi works fine > > The bootsector files used by duet are I specifically asked for the DUET qemu image. I'm in no mood to assemble boot puzzle. > _______________________________________________ > 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