Re: Completely disable graphics support in grub2 x86_64-efi

["Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>]

On Thu, Aug 26, 2010 at 1:25 PM, KESHAV P.R. <skodabenz@gmail.com> 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
>
>>>  like 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
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git