[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UEFI Boot with Grub-Experimental

From: stephen
Subject: Re: UEFI Boot with Grub-Experimental
Date: Thu, 01 Jul 2010 10:49:59 -0700
User-agent: RoundCube Webmail/0.3-beta

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.


On Thu, 1 Jul 2010 08:16:34 +0200 (CEST), Reynald Lercier
<address@hidden> 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, address@hidden 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 <address@hidden>
>> wrote:
>>> On Wed, Jun 30, 2010 at 01:54:36AM -0700, address@hidden 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:
>>> 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
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]