Bug 528232 - Hang with EFI booting on iMac and Macbook Pro 6.2
Summary: Hang with EFI booting on iMac and Macbook Pro 6.2
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 521474 (view as bug list)
Depends On:
Blocks: SOAS-4
TreeView+ depends on / blocked
 
Reported: 2009-10-09 21:39 UTC by Luke Macken
Modified: 2016-09-20 02:40 UTC (History)
34 users (show)

Fixed In Version: kernel-2.6.35.4-28.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-27 07:41:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
EFI Shell Screenshot #1 (188.51 KB, image/jpeg)
2009-10-09 21:40 UTC, Luke Macken
no flags Details
EFI Shell Screenshot #2 (177.68 KB, image/jpeg)
2009-10-09 21:40 UTC, Luke Macken
no flags Details
dmidecode output (13.74 KB, application/octet-stream)
2009-10-15 13:43 UTC, Luke Macken
no flags Details
dmidecode output (13.74 KB, text/plain)
2009-10-15 13:45 UTC, Luke Macken
no flags Details
lspci output (10.63 KB, text/plain)
2009-10-17 17:57 UTC, Luke Macken
no flags Details
efifb: support framebuffer for NVIDIA GeForce 8800 GS in iMac 8,1 (1.61 KB, patch)
2010-08-22 01:41 UTC, Luke Macken
no flags Details | Diff
efifb: support framebuffer for the Macmini 4,1 (1.59 KB, patch)
2010-08-22 01:54 UTC, Luke Macken
no flags Details | Diff
/0003-efifb-support-framebuffer-for-the-iMac10-1.patch (1.62 KB, patch)
2010-08-27 03:21 UTC, Luke Macken
no flags Details | Diff
0004-efifb-support-framebuffer-for-the-Macmini3-1.patch (1.62 KB, patch)
2010-08-27 03:22 UTC, Luke Macken
no flags Details | Diff
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch (1.65 KB, patch)
2010-08-27 03:24 UTC, Luke Macken
no flags Details | Diff
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch (1.65 KB, patch)
2010-08-27 03:31 UTC, Luke Macken
no flags Details | Diff
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch (1.65 KB, patch)
2010-08-27 03:33 UTC, Luke Macken
no flags Details | Diff
efifb: Support framebuffer for a variety of Macs (10.91 KB, patch)
2010-08-27 19:01 UTC, Luke Macken
no flags Details | Diff
Combined patch (3.04 KB, text/plain)
2010-08-27 19:23 UTC, Chuck Ebbert
no flags Details
Consolidated patch containing EFI framebuffer support for 14 more macs (4.96 KB, patch)
2010-09-02 06:13 UTC, Luke Macken
no flags Details | Diff

Description Luke Macken 2009-10-09 21:39:51 UTC
I've been unable to get Fedora to EFI boot on my 24-inch iMac.  I've tried dd'ing the efiboot.img, using livecd-iso-to-disk --mactel, and using the latest EFI code in the liveusb-creator.  Both F11 and desktop-x86_64-20091008.15

I can get to grub, but when attempting to boot a kernel, the screen just stays on the grub background, and nothing happens.

Version-Release number of selected component (if applicable):
F11 & F12 20091008 snapshot

Comment 1 Luke Macken 2009-10-09 21:40:30 UTC
Created attachment 364290 [details]
EFI Shell Screenshot #1

Comment 2 Luke Macken 2009-10-09 21:40:52 UTC
Created attachment 364291 [details]
EFI Shell Screenshot #2

Comment 3 Luke Macken 2009-10-15 13:43:39 UTC
Created attachment 364911 [details]
dmidecode output

Comment 4 Luke Macken 2009-10-15 13:45:00 UTC
Created attachment 364912 [details]
dmidecode output

Comment 5 Luke Macken 2009-10-17 17:57:03 UTC
Created attachment 365132 [details]
lspci output

Comment 6 Luke Macken 2009-10-17 17:58:59 UTC
So I wrote this patch, and have been testing it with various base values (0x80010000, 0xc0010000, 0xc0000000), but to no avail.  I'm not even quite sure if it's taking the proper code-path and detected my system as M_I24.  Since I do not see any kernel output, only the grub background, its really difficult for me to debug this.

--- a/drivers/video/efifb.c
+++ b/drivers/video/efifb.c
@@ -62,7 +62,7 @@ static struct efifb_dmi_info {
    [M_I17] = { "i17", 0x80010000, 1472 * 4, 1440, 900 },
    [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050 }, /* guess */
    [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050 },
-   [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200 }, /* guess */
+   [M_I24] = { "i24", 0xc0010000, 2048 * 4, 1920, 1200 }, /* guess */
    [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768 },
    [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800 },
    [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800 },
@@ -90,6 +90,7 @@ static struct dmi_system_id __initdata dmi_system_table[] = {
    EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "iMac6,1", M_I24),
    EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac6,1", M_I24),
    EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac7,1", M_I20_SR),
+   EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac8,1", M_I24),
    EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "Macmini1,1", M_MINI),
    EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook1,1", M_MB),
    /* At least one of these two will be right; maybe both? */

Comment 7 Bug Zapper 2009-11-16 13:28:28 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Peter Robinson 2010-01-25 20:55:47 UTC
Adding as a SOAS-3 blocker as this is causing issues with the SOAS liveCD on Macs which alot of schools have.

Comment 9 Luke Macken 2010-01-25 21:36:20 UTC
CC'ing Ajax and Peter, whom I discussed this with at FUDCon.

So, to figure out the base address, this apparently involves writing code to walk through memory writing various pixel values, and figuring out which one displays the correct output.

I think Peter said he had already written this, or was going to?

Comment 10 Bug Zapper 2010-03-15 12:55:56 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Axel 2010-03-31 21:10:53 UTC
I have a similar problem on a macbook pro 3,1 , when trying to run the Fedora 13 live CD (both with an USB media or a DVD).
The screen is stuck just after booting on the Fedora 13 entry. No kernel message, no anaconda message.
Is there a way I could debug this boot process ? By giving boot options or something else ?

Comment 12 Peter Robinson 2010-06-26 14:20:11 UTC
Updating to rawhide, also not sure if there's a 'generic' way we can do this for all Mac's or EFI systems as we're going to get a lot more EFI systems this release cycle

Comment 13 Matt Domsch 2010-06-26 15:06:09 UTC
ping pjones.

Comment 14 Marius Andreiana 2010-07-27 06:11:43 UTC
Confirming this bug with desktop-x86_64-20100725.17. I have same question as Axel.

Comment 15 Bug Zapper 2010-07-30 10:45:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Marius Andreiana 2010-08-09 21:04:28 UTC
Probably dupe: #521474 (older, but this report has more info)

@RedHat: Any info on how we can get more data to help you debug this?

Comment 17 Peter Robinson 2010-08-09 21:16:21 UTC
pjones: any update on this? i believe you had plans to fix the mac graphics initialisation issues.

Comment 18 Michael Hughes 2010-08-17 02:17:42 UTC
Used a custom Fedora spin to get around Bug 608034 with the new Mac Mini (mid 2010), than ran into this bug! Confirming.

Comment 19 Michael Hughes 2010-08-17 05:38:55 UTC
Not sure if this helps... but Ubuntu works on the new Mac Mini with this patched version of 10.04:

https://help.ubuntu.com/community/Macmini4-1/Lucid

Comment 20 metatech 2010-08-21 07:05:08 UTC
Please run the following command in a MacOS X terminal in order to get the values you need :

sudo ioreg -lw0 |grep manufacturer|cut -b25-80;sudo ioreg -lw0|grep "product-name"|cut -b 25-80;sudo dtrace -qn 'BEGIN{boot_args=((struct boot_args*)(`PE_state).bootArgs);printf("FrameBuff erBase: 0x%08x\nPixelsPerScanLine: %d\nHorizontalResolution: %d\nVerticalResolution: %d", boot_args->Video.v_baseAddr, boot_args->Video.v_rowBytes/4, boot_args->Video.v_width, boot_args->Video.v_height);exit(0)} '

Comment 21 Michael Hughes 2010-08-21 14:58:18 UTC
That gave:

 <"Apple Inc.">
 <"Macmini4,1">
FrameBuff erBase:0xc0010000
PixelsPerScanLine: 2048
HorizontalResolution: 1920
VerticalResolution:1200

So the only solution at the moment is to use the patch included in comment 6 (with correct values)?

Comment 22 metatech 2010-08-21 15:52:09 UTC
M.H.,
Yes my understanding is that with the current kernel code, hard-coding these values per model is the only way to make  it work.
In the longer term, the kernel could retrieve these values using the EFI API or grub-efi could maybe pass these values to the kernel (grub-efi is already using it).
Regards,
metatech

Comment 23 Luke Macken 2010-08-22 01:41:59 UTC
Created attachment 440178 [details]
efifb: support framebuffer for NVIDIA GeForce 8800 GS in iMac 8,1

This patch gets the efifb working on my iMac, with the following specs:

 <"Apple Inc.">
 <"iMac8,1">
FrameBuff erBase: 0xc0060000
PixelsPerScanLine: 2048
HorizontalResolution: 1920
VerticalResolution: 1200

Comment 24 Luke Macken 2010-08-22 01:54:47 UTC
Created attachment 440179 [details]
efifb: support framebuffer for the Macmini 4,1

A patch to enable the Macmini4,1 framebuffer, based on the values provided in Comment #21

Comment 25 Luke Macken 2010-08-22 15:31:27 UTC
I spun up a live F13 image with both of these patches: http://lewk.org/livecd-fedora-livecd-desktop-201008212237.iso

I also had to pass in the 'nomodeset' argument to the kernel.

Comment 26 Michael Hughes 2010-08-26 21:06:06 UTC
Confirmed the patched kernel included in the image from comment 25 works with my Mac mini.

Comment 27 Luke Macken 2010-08-27 03:21:06 UTC
Created attachment 441383 [details]
/0003-efifb-support-framebuffer-for-the-iMac10-1.patch

<"Apple Inc.">
<"iMac10,1">
FrameBuff erBase: 0xc0010000.
PixelsPerScanLine: 2048
HorizontalResolution: 1920
VerticalResolution: 1080

Comment 28 Luke Macken 2010-08-27 03:22:42 UTC
Created attachment 441385 [details]
0004-efifb-support-framebuffer-for-the-Macmini3-1.patch

<"Apple Inc.">
<"Macmini3,1">
FrameBufferBase: 0x40010000
PixelsPerScanLine: 1024
HorizontalResolution: 1024
VerticalResolution: 768

Comment 29 Luke Macken 2010-08-27 03:24:50 UTC
Created attachment 441387 [details]
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch

<"Apple Computer, Inc.">
<"MacBookPro2,2">
FrameBufferBase: 0x80010000
PixelsPerScanLine: 1472
HorizontalResolution: 1440
VerticalResolution: 900

Comment 30 Luke Macken 2010-08-27 03:31:51 UTC
Created attachment 441389 [details]
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch

Multiply the PixelsPerScanLine by 4, like every other entry.

Comment 31 Luke Macken 2010-08-27 03:33:08 UTC
Created attachment 441390 [details]
0005-efifb-support-framebuffer-for-the-MacBookPro2-2.patch

Actually upload the right patch this time...

Comment 32 metatech 2010-08-27 07:00:03 UTC
Luke,

From the kernel source it seems that it is not needed to recompile the kernel, adding this kernel parameter should be enough (the values are specific to your model, coming from the ioreg/dtrace output) :

video=efifb:base:0xc0030000,stride:2048,width:1440,height:900

I could not test it yet because my grub is still hanging after loading initrd...

metatech

Comment 33 Marius Andreiana 2010-08-27 09:18:33 UTC
We have a possible patch, looks like an easy fix. Increasing priority, as it's also affecting most of new Mac users.

Luke, would you please help on having somebody at RH close this? Hoping this will be fixed for FC14 beta.

Comment 34 Chuck Ebbert 2010-08-27 18:48:15 UTC
*** Bug 521474 has been marked as a duplicate of this bug. ***

Comment 35 Luke Macken 2010-08-27 19:01:03 UTC
Created attachment 441597 [details]
efifb: Support framebuffer for a variety of Macs

A patch against our current F14 kernel package

Comment 36 Luke Macken 2010-08-27 19:22:11 UTC
Tommaso, could you please provide us with the output from the command in Comment #20 for your MacBookPro5,5?

Comment 37 Chuck Ebbert 2010-08-27 19:23:56 UTC
Created attachment 441600 [details]
Combined patch

Rollup of the five patches

Comment 38 metatech 2010-08-27 20:11:41 UTC
Other values reported by users are available here :
http://ubuntuforums.org/showthread.php?t=1557326

Comment 39 Axel 2010-08-27 20:15:02 UTC
<"MacBookPro3,1">
FrameBuff erBase:0xc0030000
PixelsPerScanLine: 2048
HorizontalResolution: 1440
VerticalResolution:900

Comment 40 Axel 2010-08-27 20:16:13 UTC
I d like to add that Fedora 13 live doesn't boot either on a Virtualbox virtual machine setup with an EFI rom. Is this problem related ?

Comment 41 metatech 2010-08-27 20:43:30 UTC
I was considering improving the grub2 code in order to automatically add the correct efifb values : 

In file loader/i386/efi/linux.c, in the "for" loop after the line "dest = grub_stpcpy (dest, argv[0]);"

If the parameter "video=efifb:auto" exists, it would be replaced by
"video=efifb:base:0xc0030000,stride:2048,width:1440,height:900"
with the values dynamically discovered at the beginning of the function (fb_base + line_len).

Do you think it would work ?

metatech

Comment 42 metatech 2010-08-27 21:27:49 UTC
Warning : beware that these values seem to depend on the amount of RAM when it is 4GB or less.
http://ubuntuforums.org/showthread.php?t=995704&page=17 post #164
So they cannot be hard-coded, except as a fallback value for those models.

Comment 43 Luke Macken 2010-09-02 00:05:10 UTC
I just sent a patch upstream containing entries for a dozen new macs:
http://lkml.org/lkml/2010/9/1/346

I only added models that did not conflict with any existing entries.  As
mentioned in Comment #42, hard-coding these values is not a proper solution.
The driver currently matches based on vendor+model, yet there are many models
that contain different addresses/resolution/etc.  The efifb driver will
probably need to be improved to match against PCI
vendor/model/subvendor/submodel IDs.

Here are some machines that I omitted due to conflicts:

    <"MacBookPro3,1">
    FrameBuff erBase:0xc0030000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1440
    VerticalResolution:900

    <"Apple Inc.">
    <"Macmini3,1">
    FrameBufferBase: 0xc0010000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1280
    VerticalResolution: 800

    <"Apple Inc.">
    <"MacBookPro4,1">
    FrameBuff erBase: 0xc0060000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1440
    VerticalResolution: 900

    <"Apple Inc.">
    <"iMac10,1">
    FrameBuff erBase: 0xc0010000
    PixelsPerScanLine: 1920
    HorizontalResolution: 1920
    VerticalResolution: 1080

    <"Apple Inc.">
    <"MacBookPro5,1">
    FrameBufferBase: 0x90010000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1440
    VerticalResolution: 900

    <"MacBook6,1">
    FrameBuff erBase: 0x80010000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1280
    VerticalResolution: 800

    <"MacBook6,1">
    FrameBuff erBase: 0xc0010000
    PixelsPerScanLine: 2048
    HorizontalResolution: 1280
    VerticalResolution: 800

    <"Apple Inc.">
    <"iMac10,1">
    FrameBuff erBase: 0xc0010000 
    PixelsPerScanLine: 2048
    HorizontalResolution: 1920
    VerticalResolution: 1080

Comment 44 metatech 2010-09-02 05:01:34 UTC
Hi Luke !

Thanks for the nice compilation work !
I intended to do the patch, but you did it before me...

The following model has no conflicts but was not part of the submission :
[M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900 },
Can you add it to your patch or I generate a new patch ?

Thanks.

metatech

Comment 45 Luke Macken 2010-09-02 06:09:33 UTC
(In reply to comment #44)
> Hi Luke !
> 
> Thanks for the nice compilation work !
> I intended to do the patch, but you did it before me...

Ah, sorry about that.  Once you mentioned the command to spit out the appropriate values, I wanted to enable as much hardware as possible before F14.  Thank you for helping to wrangle a lot of machine.

> The following model has no conflicts but was not part of the submission :
> [M_MBP_5_3] = { "mbp53", 0xd0010000, 2048 * 4, 1440, 900 },
> Can you add it to your patch or I generate a new patch ?

Thanks, I just sent an updated patch upstream with the MacBookPro5,3 and MacBook6,1 (I gathered conflicting values for the 6,1, but we might as well have 1 entry listed in the driver as opposed to none).

Comment 46 Luke Macken 2010-09-02 06:13:16 UTC
Created attachment 442546 [details]
Consolidated patch containing EFI framebuffer support for 14 more macs

Comment 47 metatech 2010-09-04 10:05:29 UTC
Luke,

Regarding the out-of-the-box support for these models, the sooner the better ! So it is good if your patch can already be fast tracked into Fedora Core 14.  Will it be already included in the beta release ?

Regarding the conflicts, when there are several values for the FrameBufferBase, I would always take the smallest one, because it is the value of the standard model variant, without memory upgrade options.  This is the variant that people are the most likely to have.

Thanks again for your work,

metatech

Comment 48 Luke Macken 2010-09-04 18:52:06 UTC
(In reply to comment #47)
> Luke,
> 
> Regarding the out-of-the-box support for these models, the sooner the better !
> So it is good if your patch can already be fast tracked into Fedora Core 14. 
> Will it be already included in the beta release ?

The patch has already been committed to the F14 kernel branch, so I assume it'll be in the beta.

> Regarding the conflicts, when there are several values for the FrameBufferBase,
> I would always take the smallest one, because it is the value of the standard
> model variant, without memory upgrade options.  This is the variant that people
> are the most likely to have.

Peter just wrote a patch for the efifb driver that will allow us to define multiple entries for each model containing different values.  The driver will then only use the entry containing a base address that falls within the range of a PCI BAR on a VGA device in the machine.

http://git.kernel.org/?p=linux/kernel/git/pjones/efi.git;a=commitdiff;h=0678f5a34a3d6a42ed234195d0e93298e0f6ae15;hp=2bfc96a127bc1cc94d26bfaa40159966064f9c8c

Comment 49 metatech 2010-09-05 07:03:26 UTC
Luke and Peter,

Thanks for your progress on the matter !

I have another suggestion that might eliminate the need for hard-coded framebuffer base [list of] values altogether.

Grub2 contains code to automatically discover the framebuffer base address : see
grub 1.98 in file loader/i386/efi/linux.c function "find_framebuf".
Unfortunately, the PCI code looks cryptic to me, so I do not dare to give a try.
Do you think the same logic could be used in the efifb driver ?

Thanks.

metatech

Comment 50 Marius Andreiana 2010-09-11 15:54:25 UTC
(In reply to comment #48)
> The patch has already been committed to the F14 kernel branch, so I assume
> it'll be in the beta.
The nightly F14 branch compose from here
http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/
still doesn't work: grub, loads, counts down, then remains on blue screen. 

Does it work for anybody else? Should it? (is the patch actually in)

Comment 51 Luke Macken 2010-09-11 18:24:16 UTC
(In reply to comment #50)
> (In reply to comment #48)
> > The patch has already been committed to the F14 kernel branch, so I assume
> > it'll be in the beta.
> The nightly F14 branch compose from here
> http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/
> still doesn't work: grub, loads, counts down, then remains on blue screen. 
> 
> Does it work for anybody else? Should it? (is the patch actually in)

That live image does not work for me.  It looks like the patch made it into the F14 kernel branch, but not rawhide (which is what I assume the nighly-composes are based on).

Comment 52 Peter Robinson 2010-09-13 17:36:26 UTC
(In reply to comment #51)
> (In reply to comment #50)
> > (In reply to comment #48)
> > > The patch has already been committed to the F14 kernel branch, so I assume
> > > it'll be in the beta.
> > The nightly F14 branch compose from here
> > http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/
> > still doesn't work: grub, loads, counts down, then remains on blue screen. 
> > 
> > Does it work for anybody else? Should it? (is the patch actually in)
> 
> That live image does not work for me.  It looks like the patch made it into the
> F14 kernel branch, but not rawhide (which is what I assume the nighly-composes
> are based on).

Nightly composes are based on the upcoming release and not rawhide so its likely its made it to rawhide and not F-14.

Comment 53 Marius Andreiana 2010-09-13 19:23:32 UTC
Today's rawhide doesn't work either. 

I'll wait for somebody to confirm patch was actually committed, mark this issue fixed, let us know what live boot iso we can use for testing and gladly test it.
Thanks

Comment 54 John Poelstra 2010-09-14 20:17:51 UTC
FWIW

Discussed at blocker meeting today.  Under #4 http://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria this bug does not qualify as a release blocker.

Comment 55 Fedora Update System 2010-09-15 04:59:56 UTC
kernel-2.6.35.4-28.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/kernel-2.6.35.4-28.fc14

Comment 56 Fedora Update System 2010-09-17 04:05:05 UTC
kernel-2.6.35.4-28.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/kernel-2.6.35.4-28.fc14

Comment 57 Fedora Update System 2010-09-22 04:09:42 UTC
kernel-2.6.35.4-28.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 58 metatech 2010-09-26 19:45:52 UTC
It would be interesting to know whether the patched kernel actually works on a MBP 6.2, I suppose the original poster owns one ?
I have some doubts, because in the post #1140 in this thread http://ww.ubuntuforums.org/showthread.php?t=995704&page=114, Andreas Heider, author of the GPU swiching driver in this thread http://ubuntuforums.org/showthread.php?t=1564298, reports that on a MBP6,2 this other kernel patch is needed https://patchwork.kernel.org/patch/119823/ in order to boot without "noefi" kernel parameter.  Unfortunately, the "noefi" has serious inconveniences, such as disabling the screen brightness control.  
On my MBP5,3, I also need to use the "noefi" parameter to allow EFI booting.

metatech

Comment 59 Michael Griepentrog 2010-09-27 06:13:03 UTC
I just tried desktop-x86_64-20100924.16.iso on a usb drive using liveusb-creator, and my MacBook Pro 6,2 currently does not boot using EFI. I'm able boot GRUB ok, but once I select a boot option it freezes like originally reported. Is there an easy way to generate a livecd iso with the above patch? I'm comfortable compiling the kernel, but not very familiar on how to prepare the kernel for a live cd. Let me know if there's any additional information I can provide to solve this issue.

Comment 60 Michael Griepentrog 2010-09-27 08:15:11 UTC
I'm looking at the git branch for f14, and it looks like this patch didn't get fully applied. efifb-add-more-models.patch only appears to add a subset of what was proposed here and what was recently applied upstream here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a5757c2a474a15f87e5baa9a4caacc31cde2bae6. Among the models missing is the MacBook Pro 6,2. I'm in the process of building the kernel from source using a vm with the upstream patch, and substituting the kernel rpm in the livecd-creator config. I'll post an update later today if I'm able to boot with this change.

Comment 61 Marius Andreiana 2010-09-27 18:56:45 UTC
Re-opening per above comments.

This would be critical to fix before F14 release rather than as an update, as MBP 6.2 (and maybe others?) can't even boot.

Comment 62 metatech 2010-09-27 20:02:53 UTC
Peter,
I finally found out why passing the efifb parameters on the kernel parameter line like the following does not work (anymore) :
video=efifb:base:0xc0030000,stride:2048,width:1440,height:900

In function "efifb_init" :
481         dmi_check_system(dmi_system_table);
482
483         if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
484                 return -ENODEV;
485
486         if (fb_get_options("efifb", &option))
487                 return -ENODEV;
488         efifb_setup(option);

The check at line 483 is done too soon : it should be done after line 488.  This seems to be a side effect of the efifb/imacfb consolidation two years ago.

Can you please move or remove the check, so that unknown systems can easily be supported by editing grub configuration file ?

Other topic: I saw that the PCI checking code already made its way to the Linux main branch, I guess it will part of 2.6.36... that is awesome !

Thanks in advance,

metatech

Comment 63 metatech 2010-09-28 07:45:09 UTC
Give me a bit of time to do more tests regarding my last comment, something does not sound quite right in the reasoning. I will keep you posted.

Comment 64 metatech 2010-09-29 06:32:06 UTC
I confirm comment#62, but a step is missing : the orig_video_isVGA is 0, so it must be set to VIDEO_TYPE_EFI (same reason I guess as the past contribution of Brian Maly in efifb.c).
I will post the patch once it cleanly works on my machine.

metatech

Comment 65 Fedora Update System 2010-10-08 18:57:35 UTC
kernel-2.6.35.6-39.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/kernel-2.6.35.6-39.fc14

Comment 66 Fedora Update System 2010-10-09 03:31:48 UTC
kernel-2.6.35.6-39.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 67 Dinesh 2010-10-10 03:04:01 UTC
Support for the iMac9.1 also needs to be added. The details are:


 <"Apple Inc.">
 <"iMac9,1">
FrameBuff erBase: 0xc0060000
PixelPerScanLine: 2048
HorizontalResolution: 1920
VerticalResolution:1200

Comment 68 Marius Andreiana 2010-10-11 06:23:59 UTC
Tested desktop-x86_64-20101009.19 on MacBook Pro 6,2: it still freezes right after grub countdown gets to 0.

Adding "noefi text" will start booting with a garbled screen resolution (can't read text), and then freeze after ~3seconds. It looks like the same behaviour as the regular boot.

Comment 69 Luke Macken 2010-10-18 17:17:26 UTC
(In reply to comment #68)
> Tested desktop-x86_64-20101009.19 on MacBook Pro 6,2: it still freezes right
> after grub countdown gets to 0.

Can you run the command in Comment #20 and give us the output?  Thanks.

Comment 70 Marius Andreiana 2010-10-18 18:00:58 UTC
Sure, I've missed that comment:

 <"Apple Inc.">
 <"MacBookPro6,2">
FrameBuff erBase: 0x90030000
PixelsPerScanLine: 2048
HorizontalResolution: 1680
VerticalResolution: 1050

Please let me know if I can help with other info, testing or anything.

Comment 71 Luke Macken 2010-10-18 19:00:44 UTC
(In reply to comment #70)
> Sure, I've missed that comment:
> 
>  <"Apple Inc.">
>  <"MacBookPro6,2">
> FrameBuff erBase: 0x90030000
> PixelsPerScanLine: 2048
> HorizontalResolution: 1680
> VerticalResolution: 1050
> 
> Please let me know if I can help with other info, testing or anything.

These numbers match up with the patch found in kernel-2.6.35.6-39.fc14, which is in the desktop-x86_64-20101009.19 live image.

Comment 72 Marius Andreiana 2010-10-18 19:59:43 UTC
(In reply to comment #71)
> These numbers match up with the patch found in kernel-2.6.35.6-39.fc14, which
> is in the desktop-x86_64-20101009.19 live image.

With desktop-x86_64-20101016.18 I still get results in comment #68. I've tried nomodeset, video=efifb... parameters (with my numbers), still freezes at grub blue screen when it attempts to boot.

The only parameter making a difference is noefi, which gets Fedora booting, but with garbled screen and a freeze seconds later.

Comment 73 Garrett Holmstrom 2010-10-19 19:33:25 UTC
I'm a bit concerned that the EFI bootloader isn't even running, because I can run the i386 efidisk.img and I get the same result.  I shouldn't even be able to get to the i386 bootloader in that environment.

FWIW, my MacBookPro6,2 has a different resolution but the same base address.  It has 4 GiB of memory; does the address move around based on how much RAM a system has?

 <"Apple Inc.">
 <"MacBookPro6,2">
FrameBuff erBase: 0x90030000
PixelsPerScanLine: 2048
HorizontalResolution: 1440
VerticalResolution: 900

Comment 74 marco_rf2004 2010-10-26 21:09:14 UTC
Here is mine :

 <"Apple Inc.">
 <"MacBookPro5,5">
FrameBufferBase:0xc0010000
PixelsPerScanLine: 2048
HorizontalResolution: 1280
VerticalResolution:800

Comment 75 François Kooman 2010-11-02 21:22:56 UTC
Same on my MacBookPro 5,5 with 4G of memory:

 <"Apple Inc.">
 <"MacBookPro5,5">
FrameBuff erBase: 0xc0010000
PixelsPerScanLine: 2048
HorizontalResolution: 1280
VerticalResolution: 800

Comment 76 Peter Robinson 2010-11-03 16:23:41 UTC
Another one to add to the list. 

 <"Apple Inc.">
 <"MacBookAir2,1">
FrameBuff erBase: 0x80010000
PixelsPerScanLine: 2048
HorizontalResolution: 1280
VerticalResolution: 800

Comment 77 satellitgo 2010-11-03 21:21:32 UTC
Fedora-14-x86_64-Live-SoaS.iso Final release as CD

CD boots with USB external DVD/CD in Apple MacBook Air if you select the second option on boot menu: (contains nomodeset xdriver=vesa)

The first boot option works but display is garbled.

Comment 78 satellitgo 2010-11-03 22:20:04 UTC
I could not get your command to run:

Here is About this machine/more/Graphics/Display info

<"Apple Inc.">
 <"MacBookAir3,1">


  Chipset Model:	NVIDIA GeForce 320M
  Type:	GPU
  Bus:	PCI
  VRAM (Total):	256 MB
  Vendor:	NVIDIA (0x10de)
  Device ID:	0x08a2
  Revision ID:	0x00a2
  ROM Revision:	3571
  Displays:
Color LCD:
  Resolution:	1366 x 768
  Pixel Depth:	32-Bit Color (ARGB8888)
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
  Connection Type:	DisplayPort
Display Connector:
  Status:	No Display Connected

Comment 80 Marius Andreiana 2010-11-06 08:29:40 UTC
Still not booting on 6.2 with "nomodeset xdriver=vesa"

Comment 81 Marius Andreiana 2010-11-12 16:36:03 UTC
I was booting from an USB stick, which results in a freeze after passing grub boot. 
Booting from CD works on 6.2, with "nomodeset xdriver=vesa"

Comment 82 all_bugzilla 2010-12-16 21:18:26 UTC
Marius, you and I have the same MBP6,2 model - a mid-2010 15-inch with the hi-resolution display, Intel Core i7 2.66GHz CPU.  

I too am experiencing the problem in this thread.  I tried several times to boot from a USB flash drive containing either the x86_64 netinst.iso image, or the x86_64 efidisk.img found on the DVD and extracted to the USB flash drive.  I simply could not get either to boot properly...   

The x86_64 F14 netinst.iso simply did not boot at all from USB.  

The x86_64 F14 efidisk.img, extracted from the DVD, actually booted(!) from the USB drive, and I got to see the Fedora 14 initial splash screen and countdown, but at the end of the countdown (14 seconds?), it would hang and go nowhere.  

After many unsuccessful attempts, last night, I gave up and just inserted the F14 x86_64 DVD into the MBP CD/DVD drive slot, and...  It booted right up!  I continued and did the entire F14 installation off the DVD.  I got all the way through, no problems at all, and the video/display was perfect from the beginning of the installation, all the way through to the end.  

On the final reboot at the end of the installation, the MBP could not EFI boot my new F14 installation.  So, I went and got the latest rEFIt v0.14 bootloader and installed that onto Mac OS X, restarted 2 times, and on the second restart, I saw the prompt to boot either Mac OS X or the penguin (F14)...  I chose F14 and booted right into my new F14 installation!  

Warning:  Get rid of the rghb kernel startup param, and the quiet param, and anything else graphically related, in order to see exactly what's going on during the F14 boot process...  Why?  Because I got a prompt from SELinux that it would have to make changes to the partition.  I'm not certain why, but I went ahead with that, and did not touch anything and allowed SELinux to proceed, which took about 10 minutes.  If all those graphical booting images and crap were active, then the user would not even know what's going on, and would likely think that the boot process had hung - because during an F14 boot on the MBP, you cannot SHIFT-ALT-F1, F2, F3...  Anyway, I just let it go, and eventually it finished, and I was prompted for another reboot, and sure enough, I got into F14 and began the yum updating, via wired ethernet, because the wireless was not detected.  

One thing I forgot to mention:  After the F14 and the rEFIt installs, you might need to use the rEFIt partition utility to write the new MBR/GPT.  

So, it does seem like F14 has problems EFI-booting from USB flash drives, or any image installed on them, for MBPs, and maybe even all Macs, in general?  

I really have to congratulate the whole Red Hat and Fedora teams because Fedora 14 is just wonderful.  Yes, there are problems, but I have been using Fedora since v6, and it just keeps getting better, and better.  

Frankly, I really hate having to rely on rEFIt to EFI dual boot Mac OS X and Fedora, so I hope that this gets fixed and that F15  EFI boots from any media!  

Thanks, guys.

Comment 83 satellitgo 2010-12-16 22:21:35 UTC
look at:
I am routinely booting live USB's with persistence on my MacBook Air 

http://people.sugarlabs.org/Tgillard/soas-3-boot-test.txt (Credits to Programmer)
http://people.sugarlabs.org/Tgillard/soas-3-boot-test.iso (f13)
http://www.wronkiewicz.net/soas-4-boot-test.iso (f14)
http://wiki.sugarlabs.org/go/Mac_OS_X-Boot_USB_with_Virtualbox#Boot_Helper_CD.27s

These Helper CD's boot fine in a MacBook Air by holding "C" until fedora Blue boot screen appears (Use low graphics selection) and look for a USB labelled FEDORA (CAPS) 

fat 16 in OSX Disk utility / erase) /(fat16) Label=FEDORA
Note: attempting to boot this Live USB outside of OSX ruins it. I do not know why.

Comment 84 Marius Andreiana 2010-12-16 22:28:12 UTC
all_bugzilla: I can confirm your experiences, same here

Comment 85 Luke Macken 2011-01-31 23:08:44 UTC
I updated our patch to support the following models:

iMac9,1
MacBookAir2,1
MacBookPro5,5
MacBookPro6,2

I also spun up an F14 x86_64 live image with this patch.  Testing appreciated.

http://lewk.org/livecd-fedora-live-desktop-201101311532.iso

Comment 86 Michael Griepentrog 2011-02-01 07:26:45 UTC
Tried the above image on USB with no luck. I have a MacBook Pro 6,2 with efifb values matching those in comment #70.

I tried booting with the default commands, noefi, and setting the efifb addresses manually. Should there be a specific command I should be trying?

Comment 87 satellitgo 2011-02-01 11:19:21 UTC
MacBook Air 11.3"  128GB Test:
boot with "C" held down using Mac External DVD/CD Drive.

Boots to (gdm) Automatic Login from Live CD
Then to Gnome Desktop  Live System User
Magic Mouse and wireless DO NO WORK
Plug in MacBook USB Ethernet adapter and it finds network.
Wired Network Auto eth0
Bluetooth on
Laptop Battery (98.1%)

Works Nicely
----------------------------------
About this computer:

Release
Kernel Linux 2.6.35.10-81.fc14x86_64
Gnome 2.32.0

Hardware:
Memory 1.7 GiB
Processor 0: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz
Processor 1: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz

System Status
Available disk space: 192.2 Mib

File Systems:
Device               Directory  Type  Total   Free      Available   Used
/dev/mapper/live-rw  /          ext4  3.0 GiB 222.9 MiB 192.2 MiB   2.7 GiB

Comment 88 satellitgo 2011-02-01 12:49:36 UTC
Installs to VirtualBox 4.02 8GB HD correctly
firstboot/smolt/gdm login
Installed sugar-desktop
 #yum groupinstall sugar-desktop
 #yum install sugar-emulator
 (About my computer: Fedora release 14 (Laughlin)
                    Sugar: 0.90.1

Telepathy gabble works on f1 on Jabber 
software update does not work (known bug)
keyring knows user password
sugar-browse works and downloads IRC-8.xo from ASLO

Comment 89 Matthew Kurowski 2011-05-15 21:17:05 UTC
Using the patched 201101311532.iso burned to a DVD, I was able to do the Live boot on my Macbook Pro 3,1. (I could not get it to boot from a USB I normally use to install on Lintel systems, but I believe that's related to the old Apple EFI.)

From the Live OS, I ran liveinst (from a terminal as the desktop file wasn't launching). The install went perfectly.

The Apple trackpad did not work until I did the update. Now with the closed nvidia drivers, life is beautiful.

Many thanks Luke!

Comment 90 satellitgo 2011-05-15 21:43:25 UTC
EFI boot works.
http://alt.fedoraproject.org/pub/alt/stage/15.RC3/Live/i686/Fedora-15-i686-Live-SoaS.iso
Macbook Pro8,1  2.7 Ghz Intel core i7
Intel HD Graphics 3000 GPU 1280x800 32 bit
Burned to a CD it boots with"C" key held on power on. 
Does not require safe graphics
wish the Airport Extreme (0x14E4, 0xD6) Broadcom BMC43xx 1.0 5.100.198.10.2
card worked...
Wired ethernet does work.


Thanks

Comment 91 metatech 2011-05-17 19:26:02 UTC
Hello satellit,
You say you are using the i686 version, which should not work on a 64-bit EFI (at least without "noefi" option).
Also, MacBookPro8,1 is 13 inch model with only one graphic card card (Intel, no ATI), so the benefit of EFI is not so big.
Are you sure you are using the EFI boot and not the BIOS boot ?
Thanks,
metatech

Comment 92 metatech 2011-05-17 19:42:54 UTC
All,
For the record, I came to the conclusion that the "efifb.c patching" is the wrong approach. 
Normally the bootloader is responsible for querying the graphics hardware properties (FrameBufferBase, PixelsPerScanLine, HorizontalResolution, VerticalResolution), and then it passes them to the kernel through the "linux_kernel_params" structure.
Grub2 can do that, for both UGA (PCI scanning trick) or GOP (returned by the official EFI API).
The kernel should not have this list of hard-coded values.  Furthermore, these values are not unique for a Mac model, but can very depending on the amount of RAM and possibly also on the connected devices at boot time.
See user submissions in this thread :
http://ubuntuforums.org/showthread.php?t=1557326
On top of that, these values in efifb.c are really misleading : someone looking for a reason why the EFI boot does not work on a brand new model might think that his model is missing in the list and that causes the problem, which is a wrong track.
I think we should remove these hard-coded values from the kernel and only rely on values passed by the booloader (which should be dynamically queried), so that it will work on all models.
Regards,
metatech

Comment 93 satellitgo 2011-05-17 23:21:58 UTC
RC3 Version burned to CD
"C" held at boot until CD Boots
TAB at boot;
> vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-15-i686-Live-Desktop.iso rootfstype=auto re liveimg quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0
-------
Plymouth boot (f)
startx starts (Note no 5 minute delay here like soas spin has) 
gnome3-shell
system Info: Gnome3.0.1
Intel Core i7-2620M CPU @2.70 GHzx4
Graphics Intel Sandybridge Mobile  (Standard)
32 bit
3.1 GB

Normal Gnome3-shell exept no wireless available (wired works fine)

Comment 94 Matthew Garrett 2011-05-18 18:45:44 UTC
grub2 has support for probing UGA systems to determine the screen pitch and framebuffer offset. No other EFI bootloader has that support, so right now that data lives in the kernel. For the GOP machines, entries have only been added to efifb.c when the firmware gives us back lies (such as an incorrect pitch on 11" Macbook Airs). The alternative to patching the kernel in these cases is to patch the system firmware, which is generally considered less practical and maintainable.

Comment 95 Glen Turner 2011-05-25 07:00:31 UTC
MacBook Pro 15in from 1Q2011. All variants have "Intel HD Graphics 3000" and "AMD Radeon HD 6490M". The amount of GDDR5 memory attached to the Radeon varies: machines with a 2.0GHz Core i7 having 256MB, those with a 2.2GHz Core i7 having 1GB. In the 15in variants there are three display options: "Glossy widescreen display" (1440x900), "Hi-res glossy widescreen display" (1680x1050), and "Hi-res antiglare widescreen display" (1680x1050).

This particular machine MacBook Pro 15in from 1Q2011 has: 2.2GHz Core i7, and thus 1GB memory for the Radeon; "Hi-res antiglare widescreen display". The program from #20 prints:

 <"Apple Inc.">
 <"MacBookPro8,2">
FrameBuff erBase: 0x90010000
PixelsPerScanLine: 1728
HorizontalResolution: 1680
VerticalResolution: 1050

Comment 96 Mike Harris 2011-06-02 20:40:36 UTC
I'm using a MacBookPro6,2 with the same values as https://bugzilla.redhat.com/show_bug.cgi?id=528232#c73.

Using the efidisk.img from Fedora 15, and I'm getting the standard "hangs after grub countdown." Is there a new image I can try?

Comment 97 metatech 2011-06-04 13:24:11 UTC
Mike,

On MacBookPro 6,x or 8,x the following kernel patch is known to act as a good workaround :
"Run EFI in physical mode"
https://patchwork.kernel.org/patch/337911/

The patch "Retain boot service code until after switching to virtual mode" can provide an actual fix.
https://patchwork.kernel.org/patch/798202/

Comment 98 Mike Harris 2011-06-05 01:05:12 UTC
> The patch "Retain boot service code until after switching to virtual mode" can
> provide an actual fix.
> https://patchwork.kernel.org/patch/798202/

Is there an ETA for getting this in mainline or Fedora's kernel? And then a rebuilt efidisk.img?

Comment 99 metatech 2011-06-05 06:12:04 UTC
Mike,
The patch "Retain boot service code until after switching to virtual mode" is included in 2.6.39.1 (and higher).
Hopefully it will provide a fix most (if not all) users.

Comment 100 metatech 2011-06-05 06:51:09 UTC
Mike,
In the mean time, you can try booting using the "noefi" or "noexec=off" kernel parameters.

Comment 101 Chuck Ebbert 2011-06-27 07:41:24 UTC
This should finally be fixed in F16, please test and file bugs against rawhide.

Comment 102 Raffaele Candeliere 2011-09-12 23:19:04 UTC
Good day.
I apologize if this is probably the incorrect place to put my question, but so far this is the closest thing i've been able to find to what i'm seeking for.
I've installed FC15 on an iMac 7,1 (with an ati HD2600pro card) and use the open source ati driver for graphical output. 
Well, i've installed grub2 and i've been able to boot flawlessly into Fedora in single mode (i.e. no X!) using EFI.
What isn't working is X, and i've found confusing indications about X supporting my graphic card in EFI mode. Googling around, it seems that X *can* start on apple systems (noticeably, Ubuntu distros) with ATI cards, even using KMS (and grub2 obviously) but i've found no explicit reference to my hardware combination (iMac 7,1 an ati HD2600pro).
I've tried various combinations of grub2 hacks (such as fakebios, loadbios, or so) but to no avail. X starts, the screen stays blank but the system is not frozen. I can issue commands (such as quitting X for example).
So my question is: X is still heavily relying on bios for setting up the graphic card, or what? 

Thank you for any hint and again i apologize if this is not the correct thread.

Comment 103 Raffaele Candeliere 2011-09-13 18:27:42 UTC
I've forgotten one more little question. I have expanded the RAM in my iMac to 4GB  so that the framebuffer base address is different from iMacs with only 1 GB (which is the default configuration).
The question is: with recent version of the kernel (>= 2.6.40)is it possible to pass the base address via the video=efifb:base:0xXXXXXXXXX... trick or these settings are still ignored? Do i need to recompile the kernel from scratch?

Thanks again


Note You need to log in before you can comment on or make changes to this bug.