UEFI Boot with Grub-Experimental

UEFI Boot with Grub-Experimental

[stephen]

After having no luck using the grub-efi-amd64 package in ubuntu, or 
the grub trunk, I've started trying to compile my own grub and getting 
it to boot on a new Intel motherboard which supports EFI.  I've not 
been able to get any output yet from the acutal linux kernel; usually 
the system will simply hang after the boot menu option is selected, or 
the 'boot' command is issued from the grub command line.

Currently the farthest I've gotten is using the grub command line and 
typing in the following commands:

insmod efi_gop # no impact on result
insmod ext2
insmod part_gpt

set root=(hd0,gpt3)
fakeroot # optional, no impact on result
linux /vmlinuz ro video=efifb noefi single # 'noefi' and 'video=efifb' 
have no impact on overall result
initrd /initrd.img
boot

The output is:

error: no suitable mode found
booting however
_

And then nothing else happens.  I've appended "no impact on result" on 
various things in the command(s) that I've tried that were suggestions, 
but had no visible result in the hang or the message.

I've also tried newreloc, but I don't think this has anything to do 
with relocations.

Any suggestions?

Thanks,
stephen

Re: UEFI Boot with Grub-Experimental

[Colin Watson]

On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
> After having no luck using the grub-efi-amd64 package in ubuntu, or the 
> grub trunk, I've started trying to compile my own grub and getting it to 
> boot on a new Intel motherboard which supports EFI.  I've not been able 
> to get any output yet from the acutal linux kernel; usually the system 
> will simply hang after the boot menu option is selected, or the 'boot' 
> command is issued from the grub command line.
>
> Currently the farthest I've gotten is using the grub command line and  
> typing in the following commands:
>
> insmod efi_gop # no impact on result
> insmod ext2
> insmod part_gpt
>
> set root=(hd0,gpt3)
> fakeroot # optional, no impact on result

I guess that should be 'fakebios'.

> error: no suitable mode found

After 'insmod efi_gop', could you try 'insmod gfxterm' and then
'terminal_output gfxterm', and see what happens?  Before the
terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
gfxmode=1024x768') to change its mode selection.  gfxterm can help
matters here, as that way you have a working video mode that the kernel
can be told to inherit, rather than having to probe its own.

Unfortunately right now it's hard to get debugging information on EFI
video modes.  Since you're building your own GRUB anyway, though, you
could try this patch against trunk:

  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch

That will give you an 'efi_video_info' command, which should dump out
the available GOP modes, and might be useful to get a slightly better
idea of what's going on.

> booting however
> _
>
> And then nothing else happens.

It's possible that the kernel may have booted successfully, but that you
simply don't have a working console.  It would be useful to try pinging
the machine to test that.

> I've also tried newreloc, but I don't think this has anything to do with 
> relocations.

Agreed.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: UEFI Boot with Grub-Experimental

[stephen]

Hi,

Thanks for the response.

After trying terminal_output, the computer screen would simply go black
and the machine would hang (the numlock key would not respond) after the
terminal_output gfx command was executed; this would happen regardless
of whether or not set gfxmode was called before.  

I also have just tried the efi_video_info patch; the system reports:

GOP info:
List of video modes:
0: 1024 x 768, bitonly, scan line 1024
Current mode: 0

Do i need to pass this information on to the kernel somehow?

Thanks.

On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
wrote:
> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>> grub trunk, I've started trying to compile my own grub and getting it to
>> boot on a new Intel motherboard which supports EFI.  I've not been able
>> to get any output yet from the acutal linux kernel; usually the system
>> will simply hang after the boot menu option is selected, or the 'boot'
>> command is issued from the grub command line.
>>
>> Currently the farthest I've gotten is using the grub command line and
>> typing in the following commands:
>>
>> insmod efi_gop # no impact on result
>> insmod ext2
>> insmod part_gpt
>>
>> set root=(hd0,gpt3)
>> fakeroot # optional, no impact on result
> 
> I guess that should be 'fakebios'.
> 
>> error: no suitable mode found
> 
> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
> 'terminal_output gfxterm', and see what happens?  Before the
> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
> gfxmode=1024x768') to change its mode selection.  gfxterm can help
> matters here, as that way you have a working video mode that the kernel
> can be told to inherit, rather than having to probe its own.
> 
> Unfortunately right now it's hard to get debugging information on EFI
> video modes.  Since you're building your own GRUB anyway, though, you
> could try this patch against trunk:
> 
>   http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
> 
> That will give you an 'efi_video_info' command, which should dump out
> the available GOP modes, and might be useful to get a slightly better
> idea of what's going on.
> 
>> booting however
>> _
>>
>> And then nothing else happens.
> 
> It's possible that the kernel may have booted successfully, but that you
> simply don't have a working console.  It would be useful to try pinging
> the machine to test that.
> 
>> I've also tried newreloc, but I don't think this has anything to do with
>> relocations.
> 
> Agreed.

Re: UEFI Boot with Grub-Experimental

[Reynald Lercier]

Hi,

I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.

(I need full EFI booting on this machine in order to use under linux the 
INTEL graphic card, instead of the NVIDIA GT330M one, and finally increase 
a lot the battery run time)


In my case efi_video_info returns

GOP info:
List of video modes:
0: 1680 x 1050, BGRA8, scan line 1680
Current mode: 0

Same question, what to do now with this ?

Thanks.

On Wed, 30 Jun 2010, stephen@hyarros.com wrote:

> Hi,
>
> Thanks for the response.
>
> After trying terminal_output, the computer screen would simply go black
> and the machine would hang (the numlock key would not respond) after the
> terminal_output gfx command was executed; this would happen regardless
> of whether or not set gfxmode was called before.
>
> I also have just tried the efi_video_info patch; the system reports:
>
> GOP info:
> List of video modes:
> 0: 1024 x 768, bitonly, scan line 1024
> Current mode: 0
>
> Do i need to pass this information on to the kernel somehow?
>
> Thanks.
>
> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
> wrote:
>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>> grub trunk, I've started trying to compile my own grub and getting it to
>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>> to get any output yet from the acutal linux kernel; usually the system
>>> will simply hang after the boot menu option is selected, or the 'boot'
>>> command is issued from the grub command line.
>>>
>>> Currently the farthest I've gotten is using the grub command line and
>>> typing in the following commands:
>>>
>>> insmod efi_gop # no impact on result
>>> insmod ext2
>>> insmod part_gpt
>>>
>>> set root=(hd0,gpt3)
>>> fakeroot # optional, no impact on result
>>
>> I guess that should be 'fakebios'.
>>
>>> error: no suitable mode found
>>
>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>> 'terminal_output gfxterm', and see what happens?  Before the
>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>> matters here, as that way you have a working video mode that the kernel
>> can be told to inherit, rather than having to probe its own.
>>
>> Unfortunately right now it's hard to get debugging information on EFI
>> video modes.  Since you're building your own GRUB anyway, though, you
>> could try this patch against trunk:
>>
>>   http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>
>> That will give you an 'efi_video_info' command, which should dump out
>> the available GOP modes, and might be useful to get a slightly better
>> idea of what's going on.
>>
>>> booting however
>>> _
>>>
>>> And then nothing else happens.
>>
>> It's possible that the kernel may have booted successfully, but that you
>> simply don't have a working console.  It would be useful to try pinging
>> the machine to test that.
>>
>>> I've also tried newreloc, but I don't think this has anything to do with
>>> relocations.
>>
>> Agreed.
>
>
>

Re: UEFI Boot with Grub-Experimental

[stephen]

Hi everyone,

I've had some interesting discoveries / success with this problem in
the past couple of days.  Where I am I have several machines to try out.
On some of the machines, it works; while on others, it doesn't.  I'm
pretty sure this all has to do with the video modes now.  

On my laptop (which also supports UEFI), there is only one video mode
supported as reported by efi_video_modes: 1024x768.  However, when GRUB
is booting, it calls grub_video_set_mode with the string "800x600".  It
then fails to initialize the GOP adapter (which reports it only supports
1024x768).  Then it complains that no suitable mode is found, and tries
to boot nayways without a video mode set.

Does anyone know why it would be trying to boot as 800x600 only and not
the 1024?

I'll be looking into the code more, but thought I'd let those who are
interested know.

-stephen

On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
<reynald.lercier@m4x.org> wrote:
> Hi,
> 
> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
> 
> (I need full EFI booting on this machine in order to use under linux
> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
> increase a lot the battery run time)
> 
> 
> In my case efi_video_info returns
> 
> GOP info:
> List of video modes:
> 0: 1680 x 1050, BGRA8, scan line 1680
> Current mode: 0
> 
> Same question, what to do now with this ?
> 
> Thanks.
> 
> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
> 
>> Hi,
>>
>> Thanks for the response.
>>
>> After trying terminal_output, the computer screen would simply go black
>> and the machine would hang (the numlock key would not respond) after the
>> terminal_output gfx command was executed; this would happen regardless
>> of whether or not set gfxmode was called before.
>>
>> I also have just tried the efi_video_info patch; the system reports:
>>
>> GOP info:
>> List of video modes:
>> 0: 1024 x 768, bitonly, scan line 1024
>> Current mode: 0
>>
>> Do i need to pass this information on to the kernel somehow?
>>
>> Thanks.
>>
>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>> wrote:
>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>> to get any output yet from the acutal linux kernel; usually the system
>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>> command is issued from the grub command line.
>>>>
>>>> Currently the farthest I've gotten is using the grub command line and
>>>> typing in the following commands:
>>>>
>>>> insmod efi_gop # no impact on result
>>>> insmod ext2
>>>> insmod part_gpt
>>>>
>>>> set root=(hd0,gpt3)
>>>> fakeroot # optional, no impact on result
>>>
>>> I guess that should be 'fakebios'.
>>>
>>>> error: no suitable mode found
>>>
>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>> 'terminal_output gfxterm', and see what happens?  Before the
>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>> matters here, as that way you have a working video mode that the kernel
>>> can be told to inherit, rather than having to probe its own.
>>>
>>> Unfortunately right now it's hard to get debugging information on EFI
>>> video modes.  Since you're building your own GRUB anyway, though, you
>>> could try this patch against trunk:
>>>
>>>   http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>
>>> That will give you an 'efi_video_info' command, which should dump out
>>> the available GOP modes, and might be useful to get a slightly better
>>> idea of what's going on.
>>>
>>>> booting however
>>>> _
>>>>
>>>> And then nothing else happens.
>>>
>>> It's possible that the kernel may have booted successfully, but that you
>>> simply don't have a working console.  It would be useful to try pinging
>>> the machine to test that.
>>>
>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>> relocations.
>>>
>>> Agreed.
>>
>>
>>
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: UEFI Boot with Grub-Experimental

[stephen]

Something I forgot to mention that's important -- (sorry for the spam)
-- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
set to.  

set gfxmode=1024x768

will still result in GRUB trying to initalize the video as 800x600
after the 'boot' command is issued.

-stephen

On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
> Hi everyone,
> 
> I've had some interesting discoveries / success with this problem in
> the past couple of days.  Where I am I have several machines to try out.
> On some of the machines, it works; while on others, it doesn't.  I'm
> pretty sure this all has to do with the video modes now.  
> 
> On my laptop (which also supports UEFI), there is only one video mode
> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
> is booting, it calls grub_video_set_mode with the string "800x600".  It
> then fails to initialize the GOP adapter (which reports it only supports
> 1024x768).  Then it complains that no suitable mode is found, and tries
> to boot nayways without a video mode set.
> 
> Does anyone know why it would be trying to boot as 800x600 only and not
> the 1024?
> 
> I'll be looking into the code more, but thought I'd let those who are
> interested know.
> 
> -stephen
> 
> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
> <reynald.lercier@m4x.org> wrote:
>> Hi,
>>
>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>
>> (I need full EFI booting on this machine in order to use under linux
>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>> increase a lot the battery run time)
>>
>>
>> In my case efi_video_info returns
>>
>> GOP info:
>> List of video modes:
>> 0: 1680 x 1050, BGRA8, scan line 1680
>> Current mode: 0
>>
>> Same question, what to do now with this ?
>>
>> Thanks.
>>
>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>
>>> Hi,
>>>
>>> Thanks for the response.
>>>
>>> After trying terminal_output, the computer screen would simply go black
>>> and the machine would hang (the numlock key would not respond) after the
>>> terminal_output gfx command was executed; this would happen regardless
>>> of whether or not set gfxmode was called before.
>>>
>>> I also have just tried the efi_video_info patch; the system reports:
>>>
>>> GOP info:
>>> List of video modes:
>>> 0: 1024 x 768, bitonly, scan line 1024
>>> Current mode: 0
>>>
>>> Do i need to pass this information on to the kernel somehow?
>>>
>>> Thanks.
>>>
>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>> wrote:
>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>> command is issued from the grub command line.
>>>>>
>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>> typing in the following commands:
>>>>>
>>>>> insmod efi_gop # no impact on result
>>>>> insmod ext2
>>>>> insmod part_gpt
>>>>>
>>>>> set root=(hd0,gpt3)
>>>>> fakeroot # optional, no impact on result
>>>>
>>>> I guess that should be 'fakebios'.
>>>>
>>>>> error: no suitable mode found
>>>>
>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>> matters here, as that way you have a working video mode that the kernel
>>>> can be told to inherit, rather than having to probe its own.
>>>>
>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>> could try this patch against trunk:
>>>>
>>>>   http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>
>>>> That will give you an 'efi_video_info' command, which should dump out
>>>> the available GOP modes, and might be useful to get a slightly better
>>>> idea of what's going on.
>>>>
>>>>> booting however
>>>>> _
>>>>>
>>>>> And then nothing else happens.
>>>>
>>>> It's possible that the kernel may have booted successfully, but that you
>>>> simply don't have a working console.  It would be useful to try pinging
>>>> the machine to test that.
>>>>
>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>> relocations.
>>>>
>>>> Agreed.
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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

Re: UEFI Boot with Grub-Experimental

[Seth Goldberg]

Which kernel or os are you loading?  Did you try setting the gfxpayload env var to 1024x768?

  --S

On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:

> Something I forgot to mention that's important -- (sorry for the spam)
> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
> set to.  
> 
> set gfxmode=1024x768
> 
> will still result in GRUB trying to initalize the video as 800x600
> after the 'boot' command is issued.
> 
> -stephen
> 
> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>> Hi everyone,
>> 
>> I've had some interesting discoveries / success with this problem in
>> the past couple of days.  Where I am I have several machines to try out.
>> On some of the machines, it works; while on others, it doesn't.  I'm
>> pretty sure this all has to do with the video modes now.  
>> 
>> On my laptop (which also supports UEFI), there is only one video mode
>> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
>> is booting, it calls grub_video_set_mode with the string "800x600".  It
>> then fails to initialize the GOP adapter (which reports it only supports
>> 1024x768).  Then it complains that no suitable mode is found, and tries
>> to boot nayways without a video mode set.
>> 
>> Does anyone know why it would be trying to boot as 800x600 only and not
>> the 1024?
>> 
>> I'll be looking into the code more, but thought I'd let those who are
>> interested know.
>> 
>> -stephen
>> 
>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>> <reynald.lercier@m4x.org> wrote:
>>> Hi,
>>> 
>>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>> 
>>> (I need full EFI booting on this machine in order to use under linux
>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>>> increase a lot the battery run time)
>>> 
>>> 
>>> In my case efi_video_info returns
>>> 
>>> GOP info:
>>> List of video modes:
>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>> Current mode: 0
>>> 
>>> Same question, what to do now with this ?
>>> 
>>> Thanks.
>>> 
>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Thanks for the response.
>>>> 
>>>> After trying terminal_output, the computer screen would simply go black
>>>> and the machine would hang (the numlock key would not respond) after the
>>>> terminal_output gfx command was executed; this would happen regardless
>>>> of whether or not set gfxmode was called before.
>>>> 
>>>> I also have just tried the efi_video_info patch; the system reports:
>>>> 
>>>> GOP info:
>>>> List of video modes:
>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>> Current mode: 0
>>>> 
>>>> Do i need to pass this information on to the kernel somehow?
>>>> 
>>>> Thanks.
>>>> 
>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>>> wrote:
>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>>> command is issued from the grub command line.
>>>>>> 
>>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>>> typing in the following commands:
>>>>>> 
>>>>>> insmod efi_gop # no impact on result
>>>>>> insmod ext2
>>>>>> insmod part_gpt
>>>>>> 
>>>>>> set root=(hd0,gpt3)
>>>>>> fakeroot # optional, no impact on result
>>>>> 
>>>>> I guess that should be 'fakebios'.
>>>>> 
>>>>>> error: no suitable mode found
>>>>> 
>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>>> matters here, as that way you have a working video mode that the kernel
>>>>> can be told to inherit, rather than having to probe its own.
>>>>> 
>>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>>> could try this patch against trunk:
>>>>> 
>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>> 
>>>>> That will give you an 'efi_video_info' command, which should dump out
>>>>> the available GOP modes, and might be useful to get a slightly better
>>>>> idea of what's going on.
>>>>> 
>>>>>> booting however
>>>>>> _
>>>>>> 
>>>>>> And then nothing else happens.
>>>>> 
>>>>> It's possible that the kernel may have booted successfully, but that you
>>>>> simply don't have a working console.  It would be useful to try pinging
>>>>> the machine to test that.
>>>>> 
>>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>>> relocations.
>>>>> 
>>>>> Agreed.
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: UEFI Boot with Grub-Experimental

[stephen]

Ah, yes -- the gfxpayload variable works.  But now after it
successfully initializes the video mode, it hangs at the boot with the _
(no output yet at all from kernel).

I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
works on some machines, one others it doesn't.

Thanks

On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
<seth.goldberg@oracle.com> wrote:
> Which kernel or os are you loading?  Did you try setting the
> gfxpayload env var to 1024x768?
> 
>   --S
> 
> On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:
> 
>> Something I forgot to mention that's important -- (sorry for the spam)
>> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
>> set to.
>>
>> set gfxmode=1024x768
>>
>> will still result in GRUB trying to initalize the video as 800x600
>> after the 'boot' command is issued.
>>
>> -stephen
>>
>> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>>> Hi everyone,
>>>
>>> I've had some interesting discoveries / success with this problem in
>>> the past couple of days.  Where I am I have several machines to try out.
>>> On some of the machines, it works; while on others, it doesn't.  I'm
>>> pretty sure this all has to do with the video modes now.
>>>
>>> On my laptop (which also supports UEFI), there is only one video mode
>>> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
>>> is booting, it calls grub_video_set_mode with the string "800x600".  It
>>> then fails to initialize the GOP adapter (which reports it only supports
>>> 1024x768).  Then it complains that no suitable mode is found, and tries
>>> to boot nayways without a video mode set.
>>>
>>> Does anyone know why it would be trying to boot as 800x600 only and not
>>> the 1024?
>>>
>>> I'll be looking into the code more, but thought I'd let those who are
>>> interested know.
>>>
>>> -stephen
>>>
>>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>>> <reynald.lercier@m4x.org> wrote:
>>>> Hi,
>>>>
>>>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>>>
>>>> (I need full EFI booting on this machine in order to use under linux
>>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>>>> increase a lot the battery run time)
>>>>
>>>>
>>>> In my case efi_video_info returns
>>>>
>>>> GOP info:
>>>> List of video modes:
>>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>>> Current mode: 0
>>>>
>>>> Same question, what to do now with this ?
>>>>
>>>> Thanks.
>>>>
>>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the response.
>>>>>
>>>>> After trying terminal_output, the computer screen would simply go black
>>>>> and the machine would hang (the numlock key would not respond) after the
>>>>> terminal_output gfx command was executed; this would happen regardless
>>>>> of whether or not set gfxmode was called before.
>>>>>
>>>>> I also have just tried the efi_video_info patch; the system reports:
>>>>>
>>>>> GOP info:
>>>>> List of video modes:
>>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>>> Current mode: 0
>>>>>
>>>>> Do i need to pass this information on to the kernel somehow?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>>>> wrote:
>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>>>> command is issued from the grub command line.
>>>>>>>
>>>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>>>> typing in the following commands:
>>>>>>>
>>>>>>> insmod efi_gop # no impact on result
>>>>>>> insmod ext2
>>>>>>> insmod part_gpt
>>>>>>>
>>>>>>> set root=(hd0,gpt3)
>>>>>>> fakeroot # optional, no impact on result
>>>>>>
>>>>>> I guess that should be 'fakebios'.
>>>>>>
>>>>>>> error: no suitable mode found
>>>>>>
>>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>>>> matters here, as that way you have a working video mode that the kernel
>>>>>> can be told to inherit, rather than having to probe its own.
>>>>>>
>>>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>>>> could try this patch against trunk:
>>>>>>
>>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>>>
>>>>>> That will give you an 'efi_video_info' command, which should dump out
>>>>>> the available GOP modes, and might be useful to get a slightly better
>>>>>> idea of what's going on.
>>>>>>
>>>>>>> booting however
>>>>>>> _
>>>>>>>
>>>>>>> And then nothing else happens.
>>>>>>
>>>>>> It's possible that the kernel may have booted successfully, but that you
>>>>>> simply don't have a working console.  It would be useful to try pinging
>>>>>> the machine to test that.
>>>>>>
>>>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>>>> relocations.
>>>>>>
>>>>>> Agreed.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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

Re: UEFI Boot with Grub-Experimental

[Piscium]

On 1 July 2010 18:54,  <stephen@hyarros.com> wrote:
> Something I forgot to mention that's important -- (sorry for the spam)
> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
> set to.
>
> set gfxmode=1024x768
>
> will still result in GRUB trying to initalize the video as 800x600
> after the 'boot' command is issued.
>
> -stephen

This thread probably fits better in the grub help forum, nevertheless
I will share some of my experience in case it helps.

A few weeks ago I managed to add graphical boot to my PC. It took me a
few hours to figure out how to do it because of lack of documentation.
So I had to read a bunch of shell scripts, as well as some C code, and
see how they string together. I found one page of useful information,
though it is partly out of date:
http://grub.enbug.org/gfxterm

The gist of the story is that to enable graphical boot, which is what
you appear to be trying to do as you are using "set gfxmode", you need
to have fonts available for grub. Moreover they must be in Unicode.
That is where the link I provided above was useful to me, it showed
how to create the fonts.

As I have Windows on my PC, I grabbed one of the Microsoft fonts,
arialuni.ttf, and converted it to pf2. Alternatively you can try to
create it yourself from GNU unifont, and still a third possibility, if
you have Ubuntu installed, is to use unicode.pf2 that is installed in
/boot/grub.

Whichever way you obtain the fonts file, you need to make it
accessible to grub, and let it know where you put it. In my case I
created an "extra" directory off /boot/grub where I put the fonts file
as well as the background image.

The next step is to edit the grub default file. I use the default
upstream location, so the file would be:
 /usr/local/etc/default/grub

Note that if you built and installed grub from upstream sources that
file is not installed automatically, you have to create it and then
add contents to it. I am pasting below the contents of my file,
expunged of comments. Note the last line where I tell grub where to
find the fonts:

GRUB_DEFAULT=0
GRUB_TIMEOUT=4
GRUB_CMDLINE_LINUX_DEFAULT="quiet rhgb"
GRUB_CMDLINE_LINUX="rootfstype=ext4"

GRUB_TERMINAL_OUTPUT=gfxterm
GRUB_GFXMODE=1280x1024x32
GRUB_GFXPAYLOAD_LINUX=1280x1024x32
GRUB_FONT=/boot/grub/extra/arialuni.pf2

I also have a nice background image that I got from Gnome Art. I could
say how I made it work with grub but it is outside the scope of your
question.

Re: UEFI Boot with Grub-Experimental

[Reynald Lercier]

I observed a similar beahaviour as stephen in my side.

Especially I had no dificulty at all to switch to a 1680x1050x32 graphic 
mode (following Piscium's advices) in the grub2 interface with what 
follows in grub.cfg

 	insmod efi_gop
 	insmod font
 	loadfont (hd1,gpt4)/usr/share/grub/unicode.pf2
 	insmod gfxterm
 	set gfxmode=1680x1050x32
 	set gfxpayload=1680x1050x32
 	terminal_output gfxterm

 	insmod part_gpt
 	insmod ext2

 	set timeout=10

 	menuentry "Linux (with fakebios + mbp62hd)" {
   		search  -s -f  /boot/vmlinuz-2.6.34-custom
   		fakebios
   		linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb
   		initrd /boot/initrd.img-2.6.34-custom
 	}

When the power is on, rEFIt first runs, which then, when I select the 
corresponding icon, runs EFI grub2 (that I put in the EFI fat first 
partition), which in turn should boot a linux kernel. But, the laptop 
always hangs here, in the boot comand (black screen, no message).

I tried several linux kernel, the lucid ubuntu's one (2.6.32-22-generic) 
and a recompiled 2.6.34-custom too. But, the laptop still always hangs at 
the boot up (black screen, no message). Unfortunataly, absolutely no 
output in any file of the /var/log directory too.

Just to test further, I tried to patch the 
"linux-2.6.34/drivers/video/efifb.c" linux kernel file too, by adding 
information about my hardware (framebuffer address, stride, etc... of the 
GT330M nvidia crad, all obtained from rEFIt commands: pci, devices, dh, 
etc.) in the dmi_list[] variable as follows

 	static struct efifb_dmi_info {
 		char *optname;
 		unsigned long base;
 		int stride;
 		int width;
 		int height;
 	} dmi_list[] = {
 			...
 	[M_MBP_6_2_HD] = { "mbp62hd", 0x90030000, 2048 * 4, 1680, 1050 },
 	[M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
 	};

I modified acordingly enum definitionw (for M_MBP_6_2_HD) and __initdata 
dmi_system_table.

But,
     linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb:mbp62hd
still behaves badly (black screen).

Any idea about how I could understand further what's going on ?


On Thu, 1 Jul 2010, stephen@hyarros.com wrote:

>
> Ah, yes -- the gfxpayload variable works.  But now after it
> successfully initializes the video mode, it hangs at the boot with the _
> (no output yet at all from kernel).
>
> I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
> works on some machines, one others it doesn't.
>
> Thanks
>
> On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
> <seth.goldberg@oracle.com> wrote:
>> Which kernel or os are you loading?  Did you try setting the
>> gfxpayload env var to 1024x768?
>>
>>   --S
>>
>> On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:
>>
>>> Something I forgot to mention that's important -- (sorry for the spam)
>>> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
>>> set to.
>>>
>>> set gfxmode=1024x768
>>>
>>> will still result in GRUB trying to initalize the video as 800x600
>>> after the 'boot' command is issued.
>>>
>>> -stephen
>>>
>>> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>>>> Hi everyone,
>>>>
>>>> I've had some interesting discoveries / success with this problem in
>>>> the past couple of days.  Where I am I have several machines to try out.
>>>> On some of the machines, it works; while on others, it doesn't.  I'm
>>>> pretty sure this all has to do with the video modes now.
>>>>
>>>> On my laptop (which also supports UEFI), there is only one video mode
>>>> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
>>>> is booting, it calls grub_video_set_mode with the string "800x600".  It
>>>> then fails to initialize the GOP adapter (which reports it only supports
>>>> 1024x768).  Then it complains that no suitable mode is found, and tries
>>>> to boot nayways without a video mode set.
>>>>
>>>> Does anyone know why it would be trying to boot as 800x600 only and not
>>>> the 1024?
>>>>
>>>> I'll be looking into the code more, but thought I'd let those who are
>>>> interested know.
>>>>
>>>> -stephen
>>>>
>>>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>>>> <reynald.lercier@m4x.org> wrote:
>>>>> Hi,
>>>>>
>>>>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>>>>
>>>>> (I need full EFI booting on this machine in order to use under linux
>>>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>>>>> increase a lot the battery run time)
>>>>>
>>>>>
>>>>> In my case efi_video_info returns
>>>>>
>>>>> GOP info:
>>>>> List of video modes:
>>>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>>>> Current mode: 0
>>>>>
>>>>> Same question, what to do now with this ?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the response.
>>>>>>
>>>>>> After trying terminal_output, the computer screen would simply go black
>>>>>> and the machine would hang (the numlock key would not respond) after the
>>>>>> terminal_output gfx command was executed; this would happen regardless
>>>>>> of whether or not set gfxmode was called before.
>>>>>>
>>>>>> I also have just tried the efi_video_info patch; the system reports:
>>>>>>
>>>>>> GOP info:
>>>>>> List of video modes:
>>>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>>>> Current mode: 0
>>>>>>
>>>>>> Do i need to pass this information on to the kernel somehow?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>>>>> wrote:
>>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>>>>> command is issued from the grub command line.
>>>>>>>>
>>>>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>>>>> typing in the following commands:
>>>>>>>>
>>>>>>>> insmod efi_gop # no impact on result
>>>>>>>> insmod ext2
>>>>>>>> insmod part_gpt
>>>>>>>>
>>>>>>>> set root=(hd0,gpt3)
>>>>>>>> fakeroot # optional, no impact on result
>>>>>>>
>>>>>>> I guess that should be 'fakebios'.
>>>>>>>
>>>>>>>> error: no suitable mode found
>>>>>>>
>>>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>>>>> matters here, as that way you have a working video mode that the kernel
>>>>>>> can be told to inherit, rather than having to probe its own.
>>>>>>>
>>>>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>>>>> could try this patch against trunk:
>>>>>>>
>>>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>>>>
>>>>>>> That will give you an 'efi_video_info' command, which should dump out
>>>>>>> the available GOP modes, and might be useful to get a slightly better
>>>>>>> idea of what's going on.
>>>>>>>
>>>>>>>> booting however
>>>>>>>> _
>>>>>>>>
>>>>>>>> And then nothing else happens.
>>>>>>>
>>>>>>> It's possible that the kernel may have booted successfully, but that you
>>>>>>> simply don't have a working console.  It would be useful to try pinging
>>>>>>> the machine to test that.
>>>>>>>
>>>>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>>>>> relocations.
>>>>>>>
>>>>>>> Agreed.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: UEFI Boot with Grub-Experimental

[stephen]

Hi Reynold,

I've made some progress past you recently!  I think there are bugs in
the Linux Kernel now that must be overcome by the folks over at kernel
development.  Did you try the 'noefi' kernl boot flag?  It allowed me to
get past the hang and my system would actually boot.

Also, I'm using the new 2.6.35 RC kernel (the ubuntu-flavoured one,
acutally) -- i get a weird framebuffer hang (my screen turns orange) if
I use the kernel included in lucid (2.6.32).  I've yet to try 2.6.34;
let us know how it goes for you.

-stephen

On Fri, 2 Jul 2010 16:14:53 +0200 (CEST), Reynald Lercier
<reynald.lercier@m4x.org> wrote:
> I observed a similar beahaviour as stephen in my side.
> 
> Especially I had no dificulty at all to switch to a 1680x1050x32
> graphic mode (following Piscium's advices) in the grub2 interface with
> what follows in grub.cfg
> 
> 	insmod efi_gop
> 	insmod font
> 	loadfont (hd1,gpt4)/usr/share/grub/unicode.pf2
> 	insmod gfxterm
> 	set gfxmode=1680x1050x32
> 	set gfxpayload=1680x1050x32
> 	terminal_output gfxterm
> 
> 	insmod part_gpt
> 	insmod ext2
> 
> 	set timeout=10
> 
> 	menuentry "Linux (with fakebios + mbp62hd)" {
>   		search  -s -f  /boot/vmlinuz-2.6.34-custom
>   		fakebios
>   		linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb
>   		initrd /boot/initrd.img-2.6.34-custom
> 	}
> 
> When the power is on, rEFIt first runs, which then, when I select the
> corresponding icon, runs EFI grub2 (that I put in the EFI fat first
> partition), which in turn should boot a linux kernel. But, the laptop
> always hangs here, in the boot comand (black screen, no message).
> 
> I tried several linux kernel, the lucid ubuntu's one
> (2.6.32-22-generic) and a recompiled 2.6.34-custom too. But, the
> laptop still always hangs at the boot up (black screen, no message).
> Unfortunataly, absolutely no output in any file of the /var/log
> directory too.
> 
> Just to test further, I tried to patch the
> "linux-2.6.34/drivers/video/efifb.c" linux kernel file too, by adding
> information about my hardware (framebuffer address, stride, etc... of
> the GT330M nvidia crad, all obtained from rEFIt commands: pci,
> devices, dh, etc.) in the dmi_list[] variable as follows
> 
> 	static struct efifb_dmi_info {
> 		char *optname;
> 		unsigned long base;
> 		int stride;
> 		int width;
> 		int height;
> 	} dmi_list[] = {
> 			...
> 	[M_MBP_6_2_HD] = { "mbp62hd", 0x90030000, 2048 * 4, 1680, 1050 },
> 	[M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
> 	};
> 
> I modified acordingly enum definitionw (for M_MBP_6_2_HD) and
> __initdata dmi_system_table.
> 
> But,
>     linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb:mbp62hd
> still behaves badly (black screen).
> 
> Any idea about how I could understand further what's going on ?
> 
> 
> On Thu, 1 Jul 2010, stephen@hyarros.com wrote:
> 
>>
>> Ah, yes -- the gfxpayload variable works.  But now after it
>> successfully initializes the video mode, it hangs at the boot with the _
>> (no output yet at all from kernel).
>>
>> I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
>> works on some machines, one others it doesn't.
>>
>> Thanks
>>
>> On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
>> <seth.goldberg@oracle.com> wrote:
>>> Which kernel or os are you loading?  Did you try setting the
>>> gfxpayload env var to 1024x768?
>>>
>>>   --S
>>>
>>> On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:
>>>
>>>> Something I forgot to mention that's important -- (sorry for the spam)
>>>> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
>>>> set to.
>>>>
>>>> set gfxmode=1024x768
>>>>
>>>> will still result in GRUB trying to initalize the video as 800x600
>>>> after the 'boot' command is issued.
>>>>
>>>> -stephen
>>>>
>>>> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>>>>> Hi everyone,
>>>>>
>>>>> I've had some interesting discoveries / success with this problem in
>>>>> the past couple of days.  Where I am I have several machines to try out.
>>>>> On some of the machines, it works; while on others, it doesn't.  I'm
>>>>> pretty sure this all has to do with the video modes now.
>>>>>
>>>>> On my laptop (which also supports UEFI), there is only one video mode
>>>>> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
>>>>> is booting, it calls grub_video_set_mode with the string "800x600".  It
>>>>> then fails to initialize the GOP adapter (which reports it only supports
>>>>> 1024x768).  Then it complains that no suitable mode is found, and tries
>>>>> to boot nayways without a video mode set.
>>>>>
>>>>> Does anyone know why it would be trying to boot as 800x600 only and not
>>>>> the 1024?
>>>>>
>>>>> I'll be looking into the code more, but thought I'd let those who are
>>>>> interested know.
>>>>>
>>>>> -stephen
>>>>>
>>>>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>>>>> <reynald.lercier@m4x.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>>>>>
>>>>>> (I need full EFI booting on this machine in order to use under linux
>>>>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>>>>>> increase a lot the battery run time)
>>>>>>
>>>>>>
>>>>>> In my case efi_video_info returns
>>>>>>
>>>>>> GOP info:
>>>>>> List of video modes:
>>>>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>>>>> Current mode: 0
>>>>>>
>>>>>> Same question, what to do now with this ?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the response.
>>>>>>>
>>>>>>> After trying terminal_output, the computer screen would simply go black
>>>>>>> and the machine would hang (the numlock key would not respond) after the
>>>>>>> terminal_output gfx command was executed; this would happen regardless
>>>>>>> of whether or not set gfxmode was called before.
>>>>>>>
>>>>>>> I also have just tried the efi_video_info patch; the system reports:
>>>>>>>
>>>>>>> GOP info:
>>>>>>> List of video modes:
>>>>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>>>>> Current mode: 0
>>>>>>>
>>>>>>> Do i need to pass this information on to the kernel somehow?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>>>>>> wrote:
>>>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>>>>>> command is issued from the grub command line.
>>>>>>>>>
>>>>>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>>>>>> typing in the following commands:
>>>>>>>>>
>>>>>>>>> insmod efi_gop # no impact on result
>>>>>>>>> insmod ext2
>>>>>>>>> insmod part_gpt
>>>>>>>>>
>>>>>>>>> set root=(hd0,gpt3)
>>>>>>>>> fakeroot # optional, no impact on result
>>>>>>>>
>>>>>>>> I guess that should be 'fakebios'.
>>>>>>>>
>>>>>>>>> error: no suitable mode found
>>>>>>>>
>>>>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>>>>>> matters here, as that way you have a working video mode that the kernel
>>>>>>>> can be told to inherit, rather than having to probe its own.
>>>>>>>>
>>>>>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>>>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>>>>>> could try this patch against trunk:
>>>>>>>>
>>>>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>>>>>
>>>>>>>> That will give you an 'efi_video_info' command, which should dump out
>>>>>>>> the available GOP modes, and might be useful to get a slightly better
>>>>>>>> idea of what's going on.
>>>>>>>>
>>>>>>>>> booting however
>>>>>>>>> _
>>>>>>>>>
>>>>>>>>> And then nothing else happens.
>>>>>>>>
>>>>>>>> It's possible that the kernel may have booted successfully, but that you
>>>>>>>> simply don't have a working console.  It would be useful to try pinging
>>>>>>>> the machine to test that.
>>>>>>>>
>>>>>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>>>>>> relocations.
>>>>>>>>
>>>>>>>> Agreed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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

Re: UEFI Boot with Grub-Experimental

[Reynald Lercier]

Hi Stephen,

The situation is a little bit better in my side too...

I recompile the 2.6.34 kernel following the instructions in 
Documentation/x86/x86_64/uefi.txt, from the kernel linux package.
Especially, I defined "CONFIG_FRAMEBUFFER_CONSOLE=y" int the .config file 
instead of "CONFIG_FRAMEBUFFER_CONSOLE=m".

(Do you have a difference in your side between 2.6.32 and 2.6.35 RC in 
view of this variable ?)

Kernel now boots, with the usual logs (YES !), with the noefi option,
but I get a crash when the kernel try to access to the root device...

Maybe,
http://ubuntuforums.org/showthread.php?t=995704&highlight=framebuffer&page=112
can help.

-reynald

On Fri, 2 Jul 2010, stephen@hyarros.com wrote:

>
> Hi Reynold,
>
> I've made some progress past you recently!  I think there are bugs in
> the Linux Kernel now that must be overcome by the folks over at kernel
> development.  Did you try the 'noefi' kernl boot flag?  It allowed me to
> get past the hang and my system would actually boot.
>
> Also, I'm using the new 2.6.35 RC kernel (the ubuntu-flavoured one,
> acutally) -- i get a weird framebuffer hang (my screen turns orange) if
> I use the kernel included in lucid (2.6.32).  I've yet to try 2.6.34;
> let us know how it goes for you.
>
> -stephen
>
> On Fri, 2 Jul 2010 16:14:53 +0200 (CEST), Reynald Lercier
> <reynald.lercier@m4x.org> wrote:
>> I observed a similar beahaviour as stephen in my side.
>>
>> Especially I had no dificulty at all to switch to a 1680x1050x32
>> graphic mode (following Piscium's advices) in the grub2 interface with
>> what follows in grub.cfg
>>
>> 	insmod efi_gop
>> 	insmod font
>> 	loadfont (hd1,gpt4)/usr/share/grub/unicode.pf2
>> 	insmod gfxterm
>> 	set gfxmode=1680x1050x32
>> 	set gfxpayload=1680x1050x32
>> 	terminal_output gfxterm
>>
>> 	insmod part_gpt
>> 	insmod ext2
>>
>> 	set timeout=10
>>
>> 	menuentry "Linux (with fakebios + mbp62hd)" {
>>   		search  -s -f  /boot/vmlinuz-2.6.34-custom
>>   		fakebios
>>   		linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb
>>   		initrd /boot/initrd.img-2.6.34-custom
>> 	}
>>
>> When the power is on, rEFIt first runs, which then, when I select the
>> corresponding icon, runs EFI grub2 (that I put in the EFI fat first
>> partition), which in turn should boot a linux kernel. But, the laptop
>> always hangs here, in the boot comand (black screen, no message).
>>
>> I tried several linux kernel, the lucid ubuntu's one
>> (2.6.32-22-generic) and a recompiled 2.6.34-custom too. But, the
>> laptop still always hangs at the boot up (black screen, no message).
>> Unfortunataly, absolutely no output in any file of the /var/log
>> directory too.
>>
>> Just to test further, I tried to patch the
>> "linux-2.6.34/drivers/video/efifb.c" linux kernel file too, by adding
>> information about my hardware (framebuffer address, stride, etc... of
>> the GT330M nvidia crad, all obtained from rEFIt commands: pci,
>> devices, dh, etc.) in the dmi_list[] variable as follows
>>
>> 	static struct efifb_dmi_info {
>> 		char *optname;
>> 		unsigned long base;
>> 		int stride;
>> 		int width;
>> 		int height;
>> 	} dmi_list[] = {
>> 			...
>> 	[M_MBP_6_2_HD] = { "mbp62hd", 0x90030000, 2048 * 4, 1680, 1050 },
>> 	[M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
>> 	};
>>
>> I modified acordingly enum definitionw (for M_MBP_6_2_HD) and
>> __initdata dmi_system_table.
>>
>> But,
>>     linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb:mbp62hd
>> still behaves badly (black screen).
>>
>> Any idea about how I could understand further what's going on ?
>>
>>
>> On Thu, 1 Jul 2010, stephen@hyarros.com wrote:
>>
>>>
>>> Ah, yes -- the gfxpayload variable works.  But now after it
>>> successfully initializes the video mode, it hangs at the boot with the _
>>> (no output yet at all from kernel).
>>>
>>> I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
>>> works on some machines, one others it doesn't.
>>>
>>> Thanks
>>>
>>> On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
>>> <seth.goldberg@oracle.com> wrote:
>>>> Which kernel or os are you loading?  Did you try setting the
>>>> gfxpayload env var to 1024x768?
>>>>
>>>>   --S
>>>>
>>>> On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:
>>>>
>>>>> Something I forgot to mention that's important -- (sorry for the spam)
>>>>> -- GRUB tries to initalize with 800x600 regardless of what $gfxmode is
>>>>> set to.
>>>>>
>>>>> set gfxmode=1024x768
>>>>>
>>>>> will still result in GRUB trying to initalize the video as 800x600
>>>>> after the 'boot' command is issued.
>>>>>
>>>>> -stephen
>>>>>
>>>>> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> I've had some interesting discoveries / success with this problem in
>>>>>> the past couple of days.  Where I am I have several machines to try out.
>>>>>> On some of the machines, it works; while on others, it doesn't.  I'm
>>>>>> pretty sure this all has to do with the video modes now.
>>>>>>
>>>>>> On my laptop (which also supports UEFI), there is only one video mode
>>>>>> supported as reported by efi_video_modes: 1024x768.  However, when GRUB
>>>>>> is booting, it calls grub_video_set_mode with the string "800x600".  It
>>>>>> then fails to initialize the GOP adapter (which reports it only supports
>>>>>> 1024x768).  Then it complains that no suitable mode is found, and tries
>>>>>> to boot nayways without a video mode set.
>>>>>>
>>>>>> Does anyone know why it would be trying to boot as 800x600 only and not
>>>>>> the 1024?
>>>>>>
>>>>>> I'll be looking into the code more, but thought I'd let those who are
>>>>>> interested know.
>>>>>>
>>>>>> -stephen
>>>>>>
>>>>>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>>>>>> <reynald.lercier@m4x.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I encounter very similar problemes on a my macbook pro 15', a MBP 6,2.
>>>>>>>
>>>>>>> (I need full EFI booting on this machine in order to use under linux
>>>>>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and finally
>>>>>>> increase a lot the battery run time)
>>>>>>>
>>>>>>>
>>>>>>> In my case efi_video_info returns
>>>>>>>
>>>>>>> GOP info:
>>>>>>> List of video modes:
>>>>>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>>>>>> Current mode: 0
>>>>>>>
>>>>>>> Same question, what to do now with this ?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Thanks for the response.
>>>>>>>>
>>>>>>>> After trying terminal_output, the computer screen would simply go black
>>>>>>>> and the machine would hang (the numlock key would not respond) after the
>>>>>>>> terminal_output gfx command was executed; this would happen regardless
>>>>>>>> of whether or not set gfxmode was called before.
>>>>>>>>
>>>>>>>> I also have just tried the efi_video_info patch; the system reports:
>>>>>>>>
>>>>>>>> GOP info:
>>>>>>>> List of video modes:
>>>>>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>>>>>> Current mode: 0
>>>>>>>>
>>>>>>>> Do i need to pass this information on to the kernel somehow?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
>>>>>>>> wrote:
>>>>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>>>>>>>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>>>>>>>>> grub trunk, I've started trying to compile my own grub and getting it to
>>>>>>>>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>>>>>>>>> to get any output yet from the acutal linux kernel; usually the system
>>>>>>>>>> will simply hang after the boot menu option is selected, or the 'boot'
>>>>>>>>>> command is issued from the grub command line.
>>>>>>>>>>
>>>>>>>>>> Currently the farthest I've gotten is using the grub command line and
>>>>>>>>>> typing in the following commands:
>>>>>>>>>>
>>>>>>>>>> insmod efi_gop # no impact on result
>>>>>>>>>> insmod ext2
>>>>>>>>>> insmod part_gpt
>>>>>>>>>>
>>>>>>>>>> set root=(hd0,gpt3)
>>>>>>>>>> fakeroot # optional, no impact on result
>>>>>>>>>
>>>>>>>>> I guess that should be 'fakebios'.
>>>>>>>>>
>>>>>>>>>> error: no suitable mode found
>>>>>>>>>
>>>>>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>>>>>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>>>>>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>>>>>>>>> matters here, as that way you have a working video mode that the kernel
>>>>>>>>> can be told to inherit, rather than having to probe its own.
>>>>>>>>>
>>>>>>>>> Unfortunately right now it's hard to get debugging information on EFI
>>>>>>>>> video modes.  Since you're building your own GRUB anyway, though, you
>>>>>>>>> could try this patch against trunk:
>>>>>>>>>
>>>>>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>>>>>>>>
>>>>>>>>> That will give you an 'efi_video_info' command, which should dump out
>>>>>>>>> the available GOP modes, and might be useful to get a slightly better
>>>>>>>>> idea of what's going on.
>>>>>>>>>
>>>>>>>>>> booting however
>>>>>>>>>> _
>>>>>>>>>>
>>>>>>>>>> And then nothing else happens.
>>>>>>>>>
>>>>>>>>> It's possible that the kernel may have booted successfully, but that you
>>>>>>>>> simply don't have a working console.  It would be useful to try pinging
>>>>>>>>> the machine to test that.
>>>>>>>>>
>>>>>>>>>> I've also tried newreloc, but I don't think this has anything to do with
>>>>>>>>>> relocations.
>>>>>>>>>
>>>>>>>>> Agreed.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: UEFI Boot with Grub-Experimental

[Stephen Kou]

  Most likely the disk enumeration is different than what you have in 
the grub list.

boot into a working system, plug your disk with the linux in, and then 
do sudo blkid

get the UUID of your root filesystem, and then put it as 
root=UUID=000000-0000-0000-0000-000000000 instead of /dev/sda4.

Hopefully that will work for you.

--Stephen

On 7/2/2010 11:46 AM, Reynald Lercier wrote:
> Hi Stephen,
>
> The situation is a little bit better in my side too...
>
> I recompile the 2.6.34 kernel following the instructions in 
> Documentation/x86/x86_64/uefi.txt, from the kernel linux package.
> Especially, I defined "CONFIG_FRAMEBUFFER_CONSOLE=y" int the .config 
> file instead of "CONFIG_FRAMEBUFFER_CONSOLE=m".
>
> (Do you have a difference in your side between 2.6.32 and 2.6.35 RC in 
> view of this variable ?)
>
> Kernel now boots, with the usual logs (YES !), with the noefi option,
> but I get a crash when the kernel try to access to the root device...
>
> Maybe,
> http://ubuntuforums.org/showthread.php?t=995704&highlight=framebuffer&page=112 
>
> can help.
>
> -reynald
>
> On Fri, 2 Jul 2010, stephen@hyarros.com wrote:
>
>>
>> Hi Reynold,
>>
>> I've made some progress past you recently!  I think there are bugs in
>> the Linux Kernel now that must be overcome by the folks over at kernel
>> development.  Did you try the 'noefi' kernl boot flag?  It allowed me to
>> get past the hang and my system would actually boot.
>>
>> Also, I'm using the new 2.6.35 RC kernel (the ubuntu-flavoured one,
>> acutally) -- i get a weird framebuffer hang (my screen turns orange) if
>> I use the kernel included in lucid (2.6.32).  I've yet to try 2.6.34;
>> let us know how it goes for you.
>>
>> -stephen
>>
>> On Fri, 2 Jul 2010 16:14:53 +0200 (CEST), Reynald Lercier
>> <reynald.lercier@m4x.org> wrote:
>>> I observed a similar beahaviour as stephen in my side.
>>>
>>> Especially I had no dificulty at all to switch to a 1680x1050x32
>>> graphic mode (following Piscium's advices) in the grub2 interface with
>>> what follows in grub.cfg
>>>
>>>     insmod efi_gop
>>>     insmod font
>>>     loadfont (hd1,gpt4)/usr/share/grub/unicode.pf2
>>>     insmod gfxterm
>>>     set gfxmode=1680x1050x32
>>>     set gfxpayload=1680x1050x32
>>>     terminal_output gfxterm
>>>
>>>     insmod part_gpt
>>>     insmod ext2
>>>
>>>     set timeout=10
>>>
>>>     menuentry "Linux (with fakebios + mbp62hd)" {
>>>           search  -s -f  /boot/vmlinuz-2.6.34-custom
>>>           fakebios
>>>           linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 video=efifb
>>>           initrd /boot/initrd.img-2.6.34-custom
>>>     }
>>>
>>> When the power is on, rEFIt first runs, which then, when I select the
>>> corresponding icon, runs EFI grub2 (that I put in the EFI fat first
>>> partition), which in turn should boot a linux kernel. But, the laptop
>>> always hangs here, in the boot comand (black screen, no message).
>>>
>>> I tried several linux kernel, the lucid ubuntu's one
>>> (2.6.32-22-generic) and a recompiled 2.6.34-custom too. But, the
>>> laptop still always hangs at the boot up (black screen, no message).
>>> Unfortunataly, absolutely no output in any file of the /var/log
>>> directory too.
>>>
>>> Just to test further, I tried to patch the
>>> "linux-2.6.34/drivers/video/efifb.c" linux kernel file too, by adding
>>> information about my hardware (framebuffer address, stride, etc... of
>>> the GT330M nvidia crad, all obtained from rEFIt commands: pci,
>>> devices, dh, etc.) in the dmi_list[] variable as follows
>>>
>>>     static struct efifb_dmi_info {
>>>         char *optname;
>>>         unsigned long base;
>>>         int stride;
>>>         int width;
>>>         int height;
>>>     } dmi_list[] = {
>>>             ...
>>>     [M_MBP_6_2_HD] = { "mbp62hd", 0x90030000, 2048 * 4, 1680, 1050 },
>>>     [M_UNKNOWN] = { NULL, 0, 0, 0, 0 }
>>>     };
>>>
>>> I modified acordingly enum definitionw (for M_MBP_6_2_HD) and
>>> __initdata dmi_system_table.
>>>
>>> But,
>>>     linux /boot/vmlinuz-2.6.34-custom root=/dev/sda4 
>>> video=efifb:mbp62hd
>>> still behaves badly (black screen).
>>>
>>> Any idea about how I could understand further what's going on ?
>>>
>>>
>>> On Thu, 1 Jul 2010, stephen@hyarros.com wrote:
>>>
>>>>
>>>> Ah, yes -- the gfxpayload variable works.  But now after it
>>>> successfully initializes the video mode, it hangs at the boot with 
>>>> the _
>>>> (no output yet at all from kernel).
>>>>
>>>> I'm trying to boot ubuntu lucid (2.6.32-22-generic).  The EFI boot
>>>> works on some machines, one others it doesn't.
>>>>
>>>> Thanks
>>>>
>>>> On Thu, 1 Jul 2010 11:33:17 -0700, Seth Goldberg
>>>> <seth.goldberg@oracle.com> wrote:
>>>>> Which kernel or os are you loading?  Did you try setting the
>>>>> gfxpayload env var to 1024x768?
>>>>>
>>>>>   --S
>>>>>
>>>>> On Jul 1, 2010, at 10:54 AM, <stephen@hyarros.com> wrote:
>>>>>
>>>>>> Something I forgot to mention that's important -- (sorry for the 
>>>>>> spam)
>>>>>> -- GRUB tries to initalize with 800x600 regardless of what 
>>>>>> $gfxmode is
>>>>>> set to.
>>>>>>
>>>>>> set gfxmode=1024x768
>>>>>>
>>>>>> will still result in GRUB trying to initalize the video as 800x600
>>>>>> after the 'boot' command is issued.
>>>>>>
>>>>>> -stephen
>>>>>>
>>>>>> On Thu, 01 Jul 2010 10:49:59 -0700, <stephen@hyarros.com> wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I've had some interesting discoveries / success with this 
>>>>>>> problem in
>>>>>>> the past couple of days.  Where I am I have several machines to 
>>>>>>> try out.
>>>>>>> On some of the machines, it works; while on others, it doesn't.  
>>>>>>> I'm
>>>>>>> pretty sure this all has to do with the video modes now.
>>>>>>>
>>>>>>> On my laptop (which also supports UEFI), there is only one video 
>>>>>>> mode
>>>>>>> supported as reported by efi_video_modes: 1024x768.  However, 
>>>>>>> when GRUB
>>>>>>> is booting, it calls grub_video_set_mode with the string 
>>>>>>> "800x600".  It
>>>>>>> then fails to initialize the GOP adapter (which reports it only 
>>>>>>> supports
>>>>>>> 1024x768).  Then it complains that no suitable mode is found, 
>>>>>>> and tries
>>>>>>> to boot nayways without a video mode set.
>>>>>>>
>>>>>>> Does anyone know why it would be trying to boot as 800x600 only 
>>>>>>> and not
>>>>>>> the 1024?
>>>>>>>
>>>>>>> I'll be looking into the code more, but thought I'd let those 
>>>>>>> who are
>>>>>>> interested know.
>>>>>>>
>>>>>>> -stephen
>>>>>>>
>>>>>>> On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
>>>>>>> <reynald.lercier@m4x.org> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I encounter very similar problemes on a my macbook pro 15', a 
>>>>>>>> MBP 6,2.
>>>>>>>>
>>>>>>>> (I need full EFI booting on this machine in order to use under 
>>>>>>>> linux
>>>>>>>> the INTEL graphic card, instead of the NVIDIA GT330M one, and 
>>>>>>>> finally
>>>>>>>> increase a lot the battery run time)
>>>>>>>>
>>>>>>>>
>>>>>>>> In my case efi_video_info returns
>>>>>>>>
>>>>>>>> GOP info:
>>>>>>>> List of video modes:
>>>>>>>> 0: 1680 x 1050, BGRA8, scan line 1680
>>>>>>>> Current mode: 0
>>>>>>>>
>>>>>>>> Same question, what to do now with this ?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Wed, 30 Jun 2010, stephen@hyarros.com wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks for the response.
>>>>>>>>>
>>>>>>>>> After trying terminal_output, the computer screen would simply 
>>>>>>>>> go black
>>>>>>>>> and the machine would hang (the numlock key would not respond) 
>>>>>>>>> after the
>>>>>>>>> terminal_output gfx command was executed; this would happen 
>>>>>>>>> regardless
>>>>>>>>> of whether or not set gfxmode was called before.
>>>>>>>>>
>>>>>>>>> I also have just tried the efi_video_info patch; the system 
>>>>>>>>> reports:
>>>>>>>>>
>>>>>>>>> GOP info:
>>>>>>>>> List of video modes:
>>>>>>>>> 0: 1024 x 768, bitonly, scan line 1024
>>>>>>>>> Current mode: 0
>>>>>>>>>
>>>>>>>>> Do i need to pass this information on to the kernel somehow?
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson 
>>>>>>>>> <cjwatson@ubuntu.com>
>>>>>>>>> wrote:
>>>>>>>>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com 
>>>>>>>>>> wrote:
>>>>>>>>>>> After having no luck using the grub-efi-amd64 package in 
>>>>>>>>>>> ubuntu, or the
>>>>>>>>>>> grub trunk, I've started trying to compile my own grub and 
>>>>>>>>>>> getting it to
>>>>>>>>>>> boot on a new Intel motherboard which supports EFI.  I've 
>>>>>>>>>>> not been able
>>>>>>>>>>> to get any output yet from the acutal linux kernel; usually 
>>>>>>>>>>> the system
>>>>>>>>>>> will simply hang after the boot menu option is selected, or 
>>>>>>>>>>> the 'boot'
>>>>>>>>>>> command is issued from the grub command line.
>>>>>>>>>>>
>>>>>>>>>>> Currently the farthest I've gotten is using the grub command 
>>>>>>>>>>> line and
>>>>>>>>>>> typing in the following commands:
>>>>>>>>>>>
>>>>>>>>>>> insmod efi_gop # no impact on result
>>>>>>>>>>> insmod ext2
>>>>>>>>>>> insmod part_gpt
>>>>>>>>>>>
>>>>>>>>>>> set root=(hd0,gpt3)
>>>>>>>>>>> fakeroot # optional, no impact on result
>>>>>>>>>>
>>>>>>>>>> I guess that should be 'fakebios'.
>>>>>>>>>>
>>>>>>>>>>> error: no suitable mode found
>>>>>>>>>>
>>>>>>>>>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>>>>>>>>>> 'terminal_output gfxterm', and see what happens?  Before the
>>>>>>>>>> terminal_output command, you can also use 'set gfxmode=MODE' 
>>>>>>>>>> (e.g. 'set
>>>>>>>>>> gfxmode=1024x768') to change its mode selection.  gfxterm can 
>>>>>>>>>> help
>>>>>>>>>> matters here, as that way you have a working video mode that 
>>>>>>>>>> the kernel
>>>>>>>>>> can be told to inherit, rather than having to probe its own.
>>>>>>>>>>
>>>>>>>>>> Unfortunately right now it's hard to get debugging 
>>>>>>>>>> information on EFI
>>>>>>>>>> video modes.  Since you're building your own GRUB anyway, 
>>>>>>>>>> though, you
>>>>>>>>>> could try this patch against trunk:
>>>>>>>>>>
>>>>>>>>>>  http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That will give you an 'efi_video_info' command, which should 
>>>>>>>>>> dump out
>>>>>>>>>> the available GOP modes, and might be useful to get a 
>>>>>>>>>> slightly better
>>>>>>>>>> idea of what's going on.
>>>>>>>>>>
>>>>>>>>>>> booting however
>>>>>>>>>>> _
>>>>>>>>>>>
>>>>>>>>>>> And then nothing else happens.
>>>>>>>>>>
>>>>>>>>>> It's possible that the kernel may have booted successfully, 
>>>>>>>>>> but that you
>>>>>>>>>> simply don't have a working console.  It would be useful to 
>>>>>>>>>> try pinging
>>>>>>>>>> the machine to test that.
>>>>>>>>>>
>>>>>>>>>>> I've also tried newreloc, but I don't think this has 
>>>>>>>>>>> anything to do with
>>>>>>>>>>> relocations.
>>>>>>>>>>
>>>>>>>>>> Agreed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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

Re: UEFI Boot with Grub-Experimental

[stephen]

I've gotten UEFI booting working on some platforms, while other
platforms are not working.  Specifically, booting on Intel's own
motherobards using Intel's own BIOS software (Specifically, the SOX5810J
motherboard) does not seem to work.  I get the blank screen before the
kernel is about to come alive and after grub hands off execution to the
kernel.  It boots fine with the noefi flag, but without noefi it doesn't
work.

I've tried all sorts of kernel flags to try to get some sort of output:
earlyprintk, debug=all, loglevel=7, vga=771, etc.  However, nothing
works -- the system is hung (numlock doesn't cause the LED to turn
on/off).

Although I suspect this to be a kernel bug, could it be that grub is
setting up the video improperly or something?  The AMIBIOS boards have
some special video mode that uses the gnu unicode font.  The intel
boards only use the default system font.  

Any ideas on how to get some sort of output or kernel panic would be
appreciated.

Thanks,
Stephen

Re: UEFI Boot with Grub-Experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 07/08/2010 01:49 AM, stephen@hyarros.com wrote:
> I've gotten UEFI booting working on some platforms, while other
> platforms are not working.  Specifically, booting on Intel's own
> motherobards using Intel's own BIOS software (Specifically, the SOX5810J
> motherboard) does not seem to work.  I get the blank screen before the
> kernel is about to come alive and after grub hands off execution to the
> kernel.  It boots fine with the noefi flag, but without noefi it doesn't
> work.
>
>   
Check that they bit size of Linux and EFI match. If they don't Linux crashes
> I've tried all sorts of kernel flags to try to get some sort of output:
> earlyprintk, debug=all, loglevel=7, vga=771, etc.  However, nothing
> works -- the system is hung (numlock doesn't cause the LED to turn
> on/off).
>
> Although I suspect this to be a kernel bug, could it be that grub is
> setting up the video improperly or something?  The AMIBIOS boards have
> some special video mode that uses the gnu unicode font.  The intel
> boards only use the default system font.  
>
> Any ideas on how to get some sort of output or kernel panic would be
> appreciated.
>
> Thanks,
> Stephen
>
> _______________________________________________
> 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: UEFI Boot with Grub-Experimental

[Stephen Kou]

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

  Given that grub itself works as 64-bit, I assume that the EFI firmware 
is also 64-bit.  And the grub itself loads a 64-bit kernel, so I'm 
pretty sure everything is 64-bit in the pipeline.

Would 64-bit grub-efi work on a 32-bit efi firmware?



On 7/7/2010 5:11 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 07/08/2010 01:49 AM, stephen@hyarros.com wrote:
>> I've gotten UEFI booting working on some platforms, while other
>> platforms are not working.  Specifically, booting on Intel's own
>> motherobards using Intel's own BIOS software (Specifically, the SOX5810J
>> motherboard) does not seem to work.  I get the blank screen before the
>> kernel is about to come alive and after grub hands off execution to the
>> kernel.  It boots fine with the noefi flag, but without noefi it doesn't
>> work.
>>
>>
> Check that they bit size of Linux and EFI match. If they don't Linux crashes
>> I've tried all sorts of kernel flags to try to get some sort of output:
>> earlyprintk, debug=all, loglevel=7, vga=771, etc.  However, nothing
>> works -- the system is hung (numlock doesn't cause the LED to turn
>> on/off).
>>
>> Although I suspect this to be a kernel bug, could it be that grub is
>> setting up the video improperly or something?  The AMIBIOS boards have
>> some special video mode that uses the gnu unicode font.  The intel
>> boards only use the default system font.
>>
>> Any ideas on how to get some sort of output or kernel panic would be
>> appreciated.
>>
>> Thanks,
>> Stephen
>>
>> _______________________________________________
>> 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


[-- Attachment #2: Type: text/html, Size: 2914 bytes --]

Re: UEFI Boot with Grub-Experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 06/30/2010 07:10 PM, stephen@hyarros.com wrote:
> Hi,
>
> Thanks for the response.
>
> After trying terminal_output, the computer screen would simply go black
> and the machine would hang (the numlock key would not respond) after the
> terminal_output gfx command was executed; this would happen regardless
> of whether or not set gfxmode was called before.  
>   
It's "terminal_output gfxterm", not just "gfx". There may have been bug
in the past thast specifying incorrect terminal lead to bad consequences.
Also be sure not to load efi_uga.
> I also have just tried the efi_video_info patch; the system reports:
>
> GOP info:
> List of video modes:
> 0: 1024 x 768, bitonly, scan line 1024
> Current mode: 0
>
> Do i need to pass this information on to the kernel somehow?
>
> Thanks.
>
> On Wed, 30 Jun 2010 10:40:31 +0100, Colin Watson <cjwatson@ubuntu.com>
> wrote:
>   
>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, stephen@hyarros.com wrote:
>>     
>>> After having no luck using the grub-efi-amd64 package in ubuntu, or the
>>> grub trunk, I've started trying to compile my own grub and getting it to
>>> boot on a new Intel motherboard which supports EFI.  I've not been able
>>> to get any output yet from the acutal linux kernel; usually the system
>>> will simply hang after the boot menu option is selected, or the 'boot'
>>> command is issued from the grub command line.
>>>
>>> Currently the farthest I've gotten is using the grub command line and
>>> typing in the following commands:
>>>
>>> insmod efi_gop # no impact on result
>>> insmod ext2
>>> insmod part_gpt
>>>
>>> set root=(hd0,gpt3)
>>> fakeroot # optional, no impact on result
>>>       
>> I guess that should be 'fakebios'.
>>
>>     
>>> error: no suitable mode found
>>>       
>> After 'insmod efi_gop', could you try 'insmod gfxterm' and then
>> 'terminal_output gfxterm', and see what happens?  Before the
>> terminal_output command, you can also use 'set gfxmode=MODE' (e.g. 'set
>> gfxmode=1024x768') to change its mode selection.  gfxterm can help
>> matters here, as that way you have a working video mode that the kernel
>> can be told to inherit, rather than having to probe its own.
>>
>> Unfortunately right now it's hard to get debugging information on EFI
>> video modes.  Since you're building your own GRUB anyway, though, you
>> could try this patch against trunk:
>>
>>   http://people.canonical.com/~cjwatson/tmp/grub-efivideoinfo.patch
>>
>> That will give you an 'efi_video_info' command, which should dump out
>> the available GOP modes, and might be useful to get a slightly better
>> idea of what's going on.
>>
>>     
>>> booting however
>>> _
>>>
>>> And then nothing else happens.
>>>       
>> It's possible that the kernel may have booted successfully, but that you
>> simply don't have a working console.  It would be useful to try pinging
>> the machine to test that.
>>
>>     
>>> I've also tried newreloc, but I don't think this has anything to do with
>>> relocations.
>>>       
>> Agreed.
>>     
>
> _______________________________________________
> 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: UEFI Boot with Grub-Experimental

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 30.06.2010 19:10, stephen@hyarros.com wrote:
> GOP info:
> List of video modes:
> 0: 1024 x 768, bitonly, scan line 1024
> Current mode: 0
"bitonly" is a fancy way of telling "useless". Now GRUB ignores the GOP 
interfaces like this. Some EFI versions have several GOP interfaces and 
hopefully GRUB will pick up another one. If EFI doesn't you need some 
modeset drivers in Linux

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