Re: Completely disable graphics support in grub2 x86_64-efi

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

I am getting these errors when grub.efi is started but before the menu
comes up :-


error: no such device found
(3 times)
error: no suitable mode found
error: no video mode activated


using this config :-


insmod efi_gop
insmod efi_uga
insmod font

if loadfont ${prefix}/unifont.pf2
then
   insmod gfxterm
   set gfxmode="1280x800x32,1024x768x32,800x600x32,640x480x32,1280x800,1024x768,800x600,640x480"
   set gfxpayload=keep
   terminal_output gfxterm

   set color_normal=light-blue/black
   set color_highlight=light-cyan/blue

   insmod png
   background_image ${prefix}/archlinux.png
fi

insmod part_gpt
insmod fat
insmod ext2

set timeout=5
set default=0

search --file --set=arch64 --no-floppy /vmlinuz26

set _kernel_flags="nomodeset add_efi_memmap"
set _rootfstype="ext4"

menuentry "Arch Linux 2.6.35.3-ARCH" {
linux (${arch64})/vmlinuz26
root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
rootfstype=${_rootfstype} ro ${_kernel_flags}
initrd (${arch64})/kernel26.img
}

menuentry  "Arch Linux 2.6.35.3-ARCH Fallback" {
linux (${arch64})/vmlinuz26
root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
rootfstype=${_rootfstype} ro ${_kernel_flags}
initrd (${arch64})/kernel26-fallback.img
}


The menu colors come up properly but no background image is shown.
While booting no kernel boot messages are displayed.

Without the gfx related lines (config file starting from "insmod part_gpt" ),

(before menu)
error: no such device found
(3 times)

(while booting)
error: no suitable mode found
Booting however

No menu color change and no kernel boot messages. I am using 64-bit
UEFI 2.1 firmware (Tianocore EDK1 DUET UEFI64). How do I resolve this?
I want to see the kernel boot messages and be able to boot into
terminal (runlevel or init 3), not particular about grub2 menu colors
or background image. Thanks in advance.

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]

On 08/24/2010 04:11 PM, KESHAV P.R. wrote:
> I am getting these errors when grub.efi is started but before the menu
> comes up :-
>
>
> error: no such device found
> (3 times)
> error: no suitable mode found
> error: no video mode activated
>
>
> using this config :-
>
>
> insmod efi_gop
> insmod efi_uga
> insmod font
>
>   
Did you try keeping just efi_uga? This is what was previously hardcoded
> if loadfont ${prefix}/unifont.pf2
> then
>    insmod gfxterm
>    set gfxmode="1280x800x32,1024x768x32,800x600x32,640x480x32,1280x800,1024x768,800x600,640x480"
>   
Have you tried gfxmode="auto" ?

>    set gfxpayload=keep
>    terminal_output gfxterm
>
>    set color_normal=light-blue/black
>    set color_highlight=light-cyan/blue
>
>    insmod png
>    background_image ${prefix}/archlinux.png
> fi
>
> insmod part_gpt
> insmod fat
> insmod ext2
>
> set timeout=5
> set default=0
>
> search --file --set=arch64 --no-floppy /vmlinuz26
>
> set _kernel_flags="nomodeset add_efi_memmap"
> set _rootfstype="ext4"
>
> menuentry "Arch Linux 2.6.35.3-ARCH" {
> linux (${arch64})/vmlinuz26
> root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
> rootfstype=${_rootfstype} ro ${_kernel_flags}
> initrd (${arch64})/kernel26.img
> }
>
> menuentry  "Arch Linux 2.6.35.3-ARCH Fallback" {
> linux (${arch64})/vmlinuz26
> root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
> rootfstype=${_rootfstype} ro ${_kernel_flags}
> initrd (${arch64})/kernel26-fallback.img
> }
>
>
> The menu colors come up properly but no background image is shown.
> While booting no kernel boot messages are displayed.
>
> Without the gfx related lines (config file starting from "insmod part_gpt" ),
>
> (before menu)
> error: no such device found
> (3 times)
>
> (while booting)
> error: no suitable mode found
> Booting however
>
> No menu color change and no kernel boot messages. I am using 64-bit
> UEFI 2.1 firmware (Tianocore EDK1 DUET UEFI64). How do I resolve this?
> I want to see the kernel boot messages and be able to boot into
> terminal (runlevel or init 3), not particular about grub2 menu colors
> or background image. Thanks in advance.
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

2010/8/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> On 08/24/2010 04:11 PM, KESHAV P.R. wrote:
>> I am getting these errors when grub.efi is started but before the menu
>> comes up :-
>>
>>
>> error: no such device found
>> (3 times)
>> error: no suitable mode found
>> error: no video mode activated
>>
>>
>> using this config :-
>>
>>
>> insmod efi_gop
>> insmod efi_uga
>> insmod font
>>
>>
> Did you try keeping just efi_uga? This is what was previously hardcoded

efi_uga has no effect. efi_gop shows proper menu colors but no
background image and no kernel boot messages while booting.

>> if loadfont ${prefix}/unifont.pf2
>> then
>>    insmod gfxterm
>>    set gfxmode="1280x800x32,1024x768x32,800x600x32,640x480x32,1280x800,1024x768,800x600,640x480"
>>
> Have you tried gfxmode="auto" ?

no video mode activated error still comes. No change.

I talked to Tianocore guys about this and they told me that EDK1 DUET
(based on UEFI 2.1) does not include BiosVideo support. EDK2 DuetPkg
supports it and I tested DuetPkg X64 (UEFI 2.3) and the background
image came up properly and the kernel boot messages were displayed.
For people who are using old UEIF firmware (based on EDK1) are out of
luck. How come the bzr main trunk's grub.efi shows boot messages even
with the old firmware?

>
>>    set gfxpayload=keep
>>    terminal_output gfxterm
>>
>>    set color_normal=light-blue/black
>>    set color_highlight=light-cyan/blue
>>
>>    insmod png
>>    background_image ${prefix}/archlinux.png
>> fi
>>
>> insmod part_gpt
>> insmod fat
>> insmod ext2
>>
>> set timeout=5
>> set default=0
>>
>> search --file --set=arch64 --no-floppy /vmlinuz26
>>
>> set _kernel_flags="nomodeset add_efi_memmap"
>> set _rootfstype="ext4"
>>
>> menuentry "Arch Linux 2.6.35.3-ARCH" {
>> linux (${arch64})/vmlinuz26
>> root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
>> rootfstype=${_rootfstype} ro ${_kernel_flags}
>> initrd (${arch64})/kernel26.img
>> }
>>
>> menuentry  "Arch Linux 2.6.35.3-ARCH Fallback" {
>> linux (${arch64})/vmlinuz26
>> root=/dev/disk/by-uuid/0cc6e472-7f98-42ff-b7f3-309b641377ad
>> rootfstype=${_rootfstype} ro ${_kernel_flags}
>> initrd (${arch64})/kernel26-fallback.img
>> }
>>
>>
>> The menu colors come up properly but no background image is shown.
>> While booting no kernel boot messages are displayed.
>>
>> Without the gfx related lines (config file starting from "insmod part_gpt" ),
>>
>> (before menu)
>> error: no such device found
>> (3 times)
>>
>> (while booting)
>> error: no suitable mode found
>> Booting however
>>
>> No menu color change and no kernel boot messages. I am using 64-bit
>> UEFI 2.1 firmware (Tianocore EDK1 DUET UEFI64). How do I resolve this?
>> I want to see the kernel boot messages and be able to boot into
>> terminal (runlevel or init 3), not particular about grub2 menu colors
>> or background image. Thanks in advance.
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On 08/25/2010 08:44 AM, KESHAV P.R. wrote:
> no video mode activated error still comes. No change.
> I talked to Tianocore guys about this and they told me that EDK1 DUET
> (based on UEFI 2.1) does not include BiosVideo support. EDK2 DuetPkg
> supports it and I tested DuetPkg X64 (UEFI 2.3) and the background
> image came up properly and the kernel boot messages were displayed.
> For people who are using old UEIF firmware (based on EDK1) are out of
> luck. How come the bzr main trunk's grub.efi shows boot messages even
> with the old firmware?
>
>   
Were you testing inside qemu? If so then mainline version has used
video_cirrus module which wasn't propagated into newreloc until I
resynced it recently
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

2010/8/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Were you testing inside qemu? If so then mainline version has used
> video_cirrus module which wasn't propagated into newreloc until I
> resynced it recently

No, I was not testing in qemu or VirtualBox (or any virtual machine).
I tried it in real hardware. My GPU is ATI Mobility Radeon HD 3450
with 256 MB Graphics RAM, 1280x800 native resolution of my Dell Studio
1537 laptop. Should I use newreloc or experimental branch?

Maybe I will try newreloc separately and come back to you.

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

On Wed, Aug 25, 2010 at 17:43, KESHAV P.R. <skodabenz@gmail.com> wrote:
> 2010/8/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> Were you testing inside qemu? If so then mainline version has used
>> video_cirrus module which wasn't propagated into newreloc until I
>> resynced it recently
>
> No, I was not testing in qemu or VirtualBox (or any virtual machine).
> I tried it in real hardware. My GPU is ATI Mobility Radeon HD 3450
> with 256 MB Graphics RAM, 1280x800 native resolution of my Dell Studio
> 1537 laptop. Should I use newreloc or experimental branch?
>
> Maybe I will try newreloc separately and come back to you.
>

I tried the newreloc branch
https://code.launchpad.net/~skodabenz/grub/grub2-branch-newreloc but I
found no difference in fuctionality between experimental and newreloc
in case of x86_64-efi (I do not know about i386-efi). "newreloc"
solves the problem of initramfs not being loaded properly and leading
to kernel panic that currently occurs with mainline, but the graphics
problem in experimental also occurs with newreloc, I think this
problem is due to efigfx branch. Is there any command which makes
grub2 stop trying to load a graphics/video mode and instead fallback
to efi simple text protocol? Please include the way mainline handles
the issue, as a fallback option in efigfx, in case no graphics/video
mode is found.

Regards.

Keshav

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3252 bytes --]

On 08/26/2010 10:02 AM, KESHAV P.R. wrote:
> On Wed, Aug 25, 2010 at 17:43, KESHAV P.R. <skodabenz@gmail.com> wrote:
>   
>> 2010/8/25 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>     
>>> Were you testing inside qemu? If so then mainline version has used
>>> video_cirrus module which wasn't propagated into newreloc until I
>>> resynced it recently
>>>       
>> No, I was not testing in qemu or VirtualBox (or any virtual machine).
>> I tried it in real hardware. My GPU is ATI Mobility Radeon HD 3450
>> with 256 MB Graphics RAM, 1280x800 native resolution of my Dell Studio
>> 1537 laptop. Should I use newreloc or experimental branch?
>>
>> Maybe I will try newreloc separately and come back to you.
>>
>>     
> I tried the newreloc branch
> https://code.launchpad.net/~skodabenz/grub/grub2-branch-newreloc but I
> found no difference in fuctionality between experimental and newreloc
> in case of x86_64-efi (I do not know about i386-efi). "newreloc"
> solves the problem of initramfs not being loaded properly and leading
> to kernel panic that currently occurs with mainline, but the graphics
> problem in experimental also occurs with newreloc, I think this
> problem is due to efigfx branch.
efigfx was merged into mainline quite some time ago
>  Is there any command which makes
> grub2 stop trying to load a graphics/video mode and instead fallback
> to efi simple text protocol?
efi simple text protocol was never used for this. Moreover it's not
usable by OS (you can read spec for details, part boot and runtime
protocols)
>  Please include the way mainline handles
> the issue, as a fallback option in efigfx, in case no graphics/video
> mode is found.
>   
I don't understand what happens in your case. According to you
"videotest" doesn't work (can you confirm?) and according to code GRUB
in neither branch tries to detect any other way of configure graphics on
EFI. I have a theory that for some reason Linux uses vga_text normally.
It's possible to have this behaviour with patch at the end of this
e-mail. But that patch can't be incorporated because there is no way to
actualy check the availability of vga_text on EFI and on EFI as a
firmware it's usualy not. EFI is pretty loosy firmware and is definitely
not what I recommend. I recognize that in some cases you have to use EFI
(if your hardware is shipped with it) but in case of DUET, it's
specifically searching for trouble.
Additionaly DUET is labeled as being for test purposes only and not for
regular use.
=== modified file 'grub-core/loader/i386/linux.c'
--- grub-core/loader/i386/linux.c       2010-04-21 17:13:45 +0000
+++ grub-core/loader/i386/linux.c       2010-08-26 08:20:20 +0000
@@ -638,7 +638,7 @@
     }
   else
     {
-#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) ||
defined (GRUB_MACHINE_QEMU)
+#if 1
       params->have_vga = GRUB_VIDEO_LINUX_TYPE_TEXT;
       params->video_mode = 0x3;
 #else


> Regards.
>
> Keshav
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

2010/8/26 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>
>>  Please include the way mainline handles
>> the issue, as a fallback option in efigfx, in case no graphics/video
>> mode is found.
>>
> I don't understand what happens in your case. According to you
> "videotest" doesn't work (can you confirm?) and according to code GRUB
> in neither branch tries to detect any other way of configure graphics on
> EFI. I have a theory that for some reason Linux uses vga_text normally.
> It's possible to have this behaviour with patch at the end of this
> e-mail. But that patch can't be incorporated because there is no way to
> actualy check the availability of vga_text on EFI and on EFI as a
> firmware it's usualy not. EFI is pretty loosy firmware and is definitely
> not what I recommend. I recognize that in some cases you have to use EFI
> (if your hardware is shipped with it) but in case of DUET, it's
> specifically searching for trouble.

Grub hangs when after trying videotest in the commandline. Recent
firmwares enable bios video while older firmwares use vga_text.

I have attached the tarball of actual video driver VgaMiniPort enabled
in EDK1 DUET. The other video driver option BiosVideo is not compiling
in EDK1 DUET. I think grub2 tries for the 2nd video driver to be
present in the firmware.

> Additionaly DUET is labeled as being for test purposes only and not for
> regular use.

I know it is for test purposes only. I compile DUET (both EDK and
EDK2) in windows using visual studio. I use DUET to boot windows 7 x64
in UEFI-GPT mode because I have a GPT partitioned disk in a way hybrid
mbr cannot be used because I need access to all the partitions in
windows. Windows does not allow mixing BIOS+GPT 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).

Regards.

Keshav.

> === modified file 'grub-core/loader/i386/linux.c'
> --- grub-core/loader/i386/linux.c       2010-04-21 17:13:45 +0000
> +++ grub-core/loader/i386/linux.c       2010-08-26 08:20:20 +0000
> @@ -638,7 +638,7 @@
>     }
>   else
>     {
> -#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) ||
> defined (GRUB_MACHINE_QEMU)
> +#if 1
>       params->have_vga = GRUB_VIDEO_LINUX_TYPE_TEXT;
>       params->video_mode = 0x3;
>  #else
>
>
>> Regards.
>>
>> Keshav
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>

[-- Attachment #2: VgaMiniPort.tar.xz --]
[-- Type: application/x-xz, Size: 4084 bytes --]

[-- Attachment #3: BiosVideo.tar.xz --]
[-- Type: application/x-xz, Size: 22436 bytes --]

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

On 08/26/2010 12:04 PM, KESHAV P.R. wrote:
> 2010/8/26 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>>>  Please include the way mainline handles
>>> the issue, as a fallback option in efigfx, in case no graphics/video
>>> mode is found.
>>>
>>>       
>> I don't understand what happens in your case. According to you
>> "videotest" doesn't work (can you confirm?) and according to code GRUB
>> in neither branch tries to detect any other way of configure graphics on
>> EFI. I have a theory that for some reason Linux uses vga_text normally.
>> It's possible to have this behaviour with patch at the end of this
>> e-mail. But that patch can't be incorporated because there is no way to
>> actualy check the availability of vga_text on EFI and on EFI as a
>> firmware it's usualy not. EFI is pretty loosy firmware and is definitely
>> not what I recommend. I recognize that in some cases you have to use EFI
>> (if your hardware is shipped with it) but in case of DUET, it's
>> specifically searching for trouble.
>>     
> Grub hangs when after trying videotest in the commandline. Recent
> firmwares enable bios video while older firmwares use vga_text.
>
>   
DUET isn't a firmware
> I have attached the tarball of actual video driver VgaMiniPort enabled
> in EDK1 DUET. The other video driver option BiosVideo is not compiling
> in EDK1 DUET. I think grub2 tries for the 2nd video driver to be
> present in the firmware.
>
>   
GRUB doesn't handle the choice of driver by EFI. I would recommend
loading only efi_gop since efi_uga is hacky.
If you supply the qemu image to test I might be interested in finding
out the reason of this.
>> Additionaly DUET is labeled as being for test purposes only and not for
>> regular use.
>>     
> I know it is for test purposes only. I compile DUET (both EDK and
> EDK2) in windows using visual studio. I use DUET to boot windows 7 x64
> in UEFI-GPT mode because I have a GPT partitioned disk in a way hybrid
> mbr cannot be used because I need access to all the partitions in
> windows. Windows does not allow mixing BIOS+GPT
Call Microsoft, and tell them to stop telling the crap about the
impossibility of GPT+BIOS.
>  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.
> Regards.
>
> Keshav.
>
>   
>> === modified file 'grub-core/loader/i386/linux.c'
>> --- grub-core/loader/i386/linux.c       2010-04-21 17:13:45 +0000
>> +++ grub-core/loader/i386/linux.c       2010-08-26 08:20:20 +0000
>> @@ -638,7 +638,7 @@
>>     }
>>   else
>>     {
>> -#if defined (GRUB_MACHINE_PCBIOS) || defined (GRUB_MACHINE_COREBOOT) ||
>> defined (GRUB_MACHINE_QEMU)
>> +#if 1
>>       params->have_vga = GRUB_VIDEO_LINUX_TYPE_TEXT;
>>       params->video_mode = 0x3;
>>  #else
>>
>>
>>     
>>> Regards.
>>>
>>> Keshav
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>>
>>>       
>>
>> --
>> Regards
>> Vladimir 'φ-coder/phcoder' Serbinenko
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>>     
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>     


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

2010/8/26 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> On 08/26/2010 12:04 PM, KESHAV P.R. wrote:
>> 2010/8/26 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>
> GRUB doesn't handle the choice of driver by EFI. I would recommend
> loading only efi_gop since efi_uga is hacky.
> If you supply the qemu image to test I might be interested in finding
> out the reason of this.
>>
>>> Additionaly DUET is labeled as being for test purposes only and not for
>>> regular use.
>>>
>> I know it is for test purposes only. I compile DUET (both EDK and
>> EDK2) in windows using visual studio. I use DUET to boot windows 7 x64
>> in UEFI-GPT mode because I have a GPT partitioned disk in a way hybrid
>> mbr cannot be used because I need access to all the partitions in
>> windows. Windows does not allow mixing BIOS+GPT
> Call Microsoft, and tell them to stop telling the crap about the
> impossibility of GPT+BIOS.

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.

>>  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) . I gave up trying to chainload DUET and instead
started using grub2 uefi through DUET. I like the way UEFI works and I
have no plans to revert back to MBR partitioning for the sake of
windows compatibility.

See

http://sourceforge.net/mailarchive/forum.php?thread_name=h2r2a50f7881004011438m89746f5ct7f0d54bdd176ae15%40mail.gmail.com&forum_name=edk2-devel

http://sourceforge.net/mailarchive/forum.php?thread_name=FC2FB65B4D919844ADE4BE3C2BB739AD1E038288%40shsmsx501.ccr.corp.intel.com&forum_name=edk2-devel

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).

The bootsector files used by duet are

http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=DuetPkg/BootSector/Mbr.S;hb=HEAD
http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=DuetPkg/BootSector/bs32.S;hb=HEAD

In case of  GPT (instead of Mbr.S)
http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=DuetPkg/BootSector/Gpt.S;hb=HEAD

This is the flow chart
http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=DuetPkg/BootSector/FILE.LST;hb=HEAD

Regards.

Keshav

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'phcoder' Serbinenko]

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

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

On Thu, Aug 26, 2010 at 17:17, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:

> 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.

If you plan to implement this I can test it for you in real hardware.

> 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.

I have known about coreboot but I do not want to mess up my bios. DUET
acts like a uefi wrapper for bios. I used it because no "flashing the
motherboard" was involved. I do not want to try flashing coreboot to
my motherboard.

>> 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
>>

grub2 efi works fine in my VirtualBox 3.2.8 PUEL. IN edk1 duet it has
these graphics problems. It works fine in edk2 duet.

>> The bootsector files used by duet are
> I specifically asked for the DUET qemu image. I'm in no mood to
> assemble boot puzzle.

Sorry, but i do not have a qemu image because I am using actual
hardware. I guess you are asking for qemu image of my DUET USB
pendrive. Can you provide link to instructions on how to create one?
Can virtualbox be used to create the image.

Regards.

Keshav

Re: Completely disable graphics support in grub2 x86_64-efi

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 26, 2010 at 2:02 PM, KESHAV P.R. <skodabenz@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 17:17, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>
>> Nicest way would be to implement multiboot for efildr. If I had more time I'd do it myself
>> (and I still might).
> If you plan to implement this I can test it for you in real hardware.
Setting the environment to compile DUET is painful
>
> I have known about coreboot but I do not want to mess up my bios. DUET
> acts like a uefi wrapper for bios. I used it because no "flashing the
> motherboard" was involved. I do not want to try flashing coreboot to
> my motherboard.
>
I wouldn't recommend flashing if you don't have a way to recover the
original firmware.
> grub2 efi works fine in my VirtualBox 3.2.8 PUEL. IN edk1 duet it has
> these graphics problems. It works fine in edk2 duet.
I'm a bit lost. Are there any issues with edk2 duet on real hardware?
> Sorry, but i do not have a qemu image because I am using actual
> hardware. I guess you are asking for qemu image of my DUET USB
> pendrive. Can you provide link to instructions on how to create one?
dd if=/dev/sdX of=- bs=1M | bzip2 > usb.img.bz2



-- 
Regards
Vladimir 'phcoder' Serbinenko

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

Re: Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

I compiled EDK1 DUET UEFI64 with BiosVideo support (removing
VgaMiniPort driver) (compiled in Win 7 x64 with VS2008) and now I
proper graphics behavior with grub2 in the same way as with edk2 duet
(no more videomode not set error). Thanks for you help anyways.

On Thu, Aug 26, 2010 at 18:21, KESHAV P.R. <skodabenz@gmail.com> wrote:
> On Thu, Aug 26, 2010 at 17:56, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
>
>> I'm a bit lost. Are there any issues with edk2 duet on real hardware?
>
> No issues concerning grub2. But there is a efi variable service bug in
> edk2 duet -
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTi%3DBMmD%2B9cFdTCeUhoVStYy95ro8-EWvk%2BjgHEeJ%40mail.gmail.com&forum_name=edk2-devel
>
>>> Sorry, but i do not have a qemu image because I am using actual
>>> hardware. I guess you are asking for qemu image of my DUET USB
>>> pendrive. Can you provide link to instructions on how to create one?
>> dd if=/dev/sdX of=- bs=1M | bzip2 > usb.img.bz2
>
> I did "dd if=/dev/sdb of=sdb.bin" and then "xz -9 sdb.bin" (used xz
> for best compression) . Its a dd copy of 2GB Transcend JetFlash with
> EDK1 DUET UEFI64 (UEFI 2.1 x86_64) - FAT32 filesystem.
>
> If you want to try EDK2 DUET x64 (UEFI 2.3 x86_64) replace Efildr20
> file with the one attached in this post and copy DUETEFIMAINFV.Fv to
> the pendrive.
>
> Regards.
>
> Keshav
>

Completely disable graphics support in grub2 x86_64-efi

[KESHAV P.R.]

I am currently using grub2 experimental branch compiled for x86_64-efi
. I am getting the following error message (and no kernel boot
messages are displayed) -

error: no suitable mode found.
Booting however

What modules cause these errors? Will excluding them from grub.efi
display proper kernel boot messages. I already asked this before at
http://lists.gnu.org/archive/html/bug-grub/2010-06/msg00029.html and
it was suggested to use efi_gop or efi_uga module. I am currently
unable to boot my Archlinux x86_64 using bzr main trunk due to
corrupted initramfs. Thats why I use the experimental branch (due to
newreloc branch).

The bzr trunk does not display this error message but causes kernel
panic, while the exp branch shows no boot messages but boots into gdm
(login screen) in runlevel 5 successfully. But no text is displayed if
I try runlevel 3 or single user mode or simply console login. I don't
even know whether the boot is successful.

I want newreloc (or exp branch) functionality with main trunk's boot
messages for x86_64-efi ? How do I get this? Is there any way to force
grub2 to use simple text mode of UEFI instead of GOP or UGA, or
completely disable graphical terminal in efi in my system?

Thanks in advance.