kocoman
macrumors 6502
it works you just do the lvds hz fix need to set it lower in the ads file, check out the discord and search my messages and nic3 reply back in last year
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MBP 1,1-10,2 Permanently Disable 2011 15"/17" MacBook Pro Dedicated GPU - gMux IC Bypass
- Thread starter dosdude1
- Start date
- Sort by reaction score
mattodinaturas
macrumors newbie
Hi, i completely missed your message for some reason. I've been really busy in these months. With lvds you mean backight problems? Because for me it works fine, the problem is that when i try to boot a windows install media i keep seeing the circle spin and nothing more. I tried creating an ssd with windows with another pc and if i recall correctly, it BSODs. Thanks and sorry for the late reply
P.S. mind you that i have dosdude's mod with custom gmux fw. Also, which discord group are you talking about?
Last edited:
thanks for sharing. i havent dabbled with flashing in linux before. So u recommend that i install dosdudes coreboot first, then install yours afterwards?
any recommendations as to which linux is easiest to do this on?
thx
hi everyone, I'm trying to collect coreboot for macbook pro 8.2, but I can't do it, I need any help, please help me, I used the autoport and tried all the Assembly instructions I found, I I'll give any log files,please tell me what kind files
It is indeed! The necessary patch for gMux backlight control with GPU disabled is also included in all OCLP versions.
Aguymac
macrumors member
Edit: Sorry, fault on my side....everything is working fine
Last edited:
That pile of MacBook Pros, I remember often seeing a similar sight from my former computer tech job! I was their Apple expert, so I was often assigned to test and reset Mac laptops, especially 2nd-generation MacBook Airs and unibody MacBook Pros, to see if they still had remote MDM enrollment or firmware passwords or any functionality issues before we could either recycle or re-sell them.
Aguymac
macrumors member
Hello again @dosdude1.
Question for you or anybody:
I didn't like OCLP - wasn't working well. I put Linux Mint 22.1 on the MBP instead (15", late 2011 MBP, identifier 8,2, Model A1286, with AMD GPU bypass done by you). I'm trying to get an external monitor going.
I've had it work before (before AMD GPU failed and was bypassed) using TB port to hdmi adapter, I think.
Then, I've had it work even after AMD bypass like so; From MBP TB port -> Kanex Model KTU10 -> Startech USB32HDPRO -> HDMI cable > HDMI port on Gigabyte M32Q monitor.
I also had it working while the MBP was on Catalina, using your Catalina Patcher tool, and it was working with just the Startech adapter (no Kanex adapter) in the MBP usb port, but was pretty "slow" and made the fans run high when I'd try to watch a 1080p video on youtube on the M32Q (but I had macs fan control running, so I duno).
I can't get exernal monitor to work. Doesn't seem to sense anything. I duno if I should try and install a display link adapter driver, and if so - which one, and how (on linux mint).
If anyone can provide some direction I'd appreciate it.
Thanks.
Question for you or anybody:
I didn't like OCLP - wasn't working well. I put Linux Mint 22.1 on the MBP instead (15", late 2011 MBP, identifier 8,2, Model A1286, with AMD GPU bypass done by you). I'm trying to get an external monitor going.
I've had it work before (before AMD GPU failed and was bypassed) using TB port to hdmi adapter, I think.
Then, I've had it work even after AMD bypass like so; From MBP TB port -> Kanex Model KTU10 -> Startech USB32HDPRO -> HDMI cable > HDMI port on Gigabyte M32Q monitor.
I also had it working while the MBP was on Catalina, using your Catalina Patcher tool, and it was working with just the Startech adapter (no Kanex adapter) in the MBP usb port, but was pretty "slow" and made the fans run high when I'd try to watch a 1080p video on youtube on the M32Q (but I had macs fan control running, so I duno).
I can't get exernal monitor to work. Doesn't seem to sense anything. I duno if I should try and install a display link adapter driver, and if so - which one, and how (on linux mint).
If anyone can provide some direction I'd appreciate it.
Thanks.
Yeah, with AMD GPU disabled, it is not possible to get display out from the DisplayPort. The USB-based DisplayLink adapters will work fine, but are slow as you've seen. You will need the correct drivers to get DisplayLink working under any OS.
bobesch
macrumors 68020
Even the sturdy mid2012 15" MBP9,1 may fail eventually ...:
Flickering green/red vertical line on the display. PCIe Lane Width at x8.
😥
Edit: I thought, it was a failing GPU, but I mixed everything up with the early2008 MBP4,1 (where normal PCIe Lane Width is x16 and everything below indicates a failure).
With the MBP9,1 PCIe Lane Width x8 is the normal value.
So I swapped the display-assembly with that of a spare MBP9,1 and found out that the display is the culprit.
Sorry for the misleading post ...
Flickering green/red vertical line on the display. PCIe Lane Width at x8.
😥
Edit: I thought, it was a failing GPU, but I mixed everything up with the early2008 MBP4,1 (where normal PCIe Lane Width is x16 and everything below indicates a failure).
With the MBP9,1 PCIe Lane Width x8 is the normal value.
So I swapped the display-assembly with that of a spare MBP9,1 and found out that the display is the culprit.
Sorry for the misleading post ...
Last edited:
Dear MacRumors friends,
I've traced the wiring.
The MacBook A1286 - 2011 - (820-2915) starts up, there's the startup chime, but no backlight.
Where have I gone wrong? Could you please help me?
I've traced the wiring.
The MacBook A1286 - 2011 - (820-2915) starts up, there's the startup chime, but no backlight.
Where have I gone wrong? Could you please help me?
Hi!
My 2 MBP 8.2, with Sequoia, start to freeze, but the mouse still moves.
a) I Install Monterey in one, but still freeze, in this one I use a new SSD.
It can freeze about 5 minutes after start, or can take more time.....
b)I take my second 8.2, who have a 1 TB SSD (I use it for one drive backup) and bingo !
The same error happens!
In this case, I remember that I open Firefox...
Any one can gave me a help in here, or its the end?☹️
Thanks
My 2 MBP 8.2, with Sequoia, start to freeze, but the mouse still moves.
a) I Install Monterey in one, but still freeze, in this one I use a new SSD.
It can freeze about 5 minutes after start, or can take more time.....
b)I take my second 8.2, who have a 1 TB SSD (I use it for one drive backup) and bingo !
The same error happens!
In this case, I remember that I open Firefox...
Any one can gave me a help in here, or its the end?☹️
Thanks
ToniCH
macrumors 65816
@dosdude1
Somewhat related question: I've seen videos of people replacing the dead GPU chip. Was there ever a fixed or improved chip (like with the 2008 MBPs) or were they just replaced with the same type of chip and similar failure is probable in the future?
EDIT: I just watched your MBP 15" 2008 video and in it you say there are no revised chips available for 2011s and I suspect that has not changed.
Somewhat related question: I've seen videos of people replacing the dead GPU chip. Was there ever a fixed or improved chip (like with the 2008 MBPs) or were they just replaced with the same type of chip and similar failure is probable in the future?
EDIT: I just watched your MBP 15" 2008 video and in it you say there are no revised chips available for 2011s and I suspect that has not changed.
Last edited:
Yep, never was a revised chip produced for those, and never will be.
@dosdude1
Slightly strange question do you think in theory this could be done on a 2010 17 inch Macbook Pro as I just got one for free and it turns out to be missing its GT 330m chip. I was hoping to try out your method as I really don't want the laptop to go to waste? I would really appreciate the help. Thanks
Slightly strange question do you think in theory this could be done on a 2010 17 inch Macbook Pro as I just got one for free and it turns out to be missing its GT 330m chip. I was hoping to try out your method as I really don't want the laptop to go to waste? I would really appreciate the help. Thanks
Hello everyone!
@dosdude1, FYI
Finally, with AI i got fully worked Windows setup on my de-gmux'd MBP2011 with modified stock UEFI firmware
- gmux chip physically removed from the logic board; LVDS lines from the Intel HD 3000 are bridged directly to the panel connector with jumper wires.
- Backlight control routed through a modified hub, hand-wired.
- Linux (native EFI, no coreboot) works perfectly out of the box — correct resolution, no artifacts.
- coreboot builds also work, using a VBT borrowed from a Lenovo ThinkPad T430, but that setup has trade-offs: sleep/resume issues, no ambient light sensor, a few other rough edges.
- Goal: run Windows natively on the stock Apple EFI firmware (no coreboot), via Boot Camp-style Intel graphics driver.
- As soon as the Intel HD 3000 graphics driver loads (both the generic Intel driver and Apple's own Boot Camp driver — same result with either), the display becomes corrupted:
- Image appears stretched, part of it doesn't fit on screen.
- Picture looks like it's drawn "every other line" (interlaced/torn look).
- Colors washed out.
- This happens on the stock, unmodified Apple EFI firmware — not just on coreboot builds.
Extracting and decoding both VBTs with intel_vbt_decode (from intel-gpu-tools) and diffing the LVDS Options block (BDB block 40) revealed the key difference:
Root cause: Apple's own VBT ships with a completely generic/unused LVDS panel timing table, because macOS never reads panel configuration from the Intel VBT at all (it comes from the EFI device tree / AppleGraphicsControl instead). Apple simply never bothered to fill in real values here.
The LVDS EDID available flag tells the Intel driver whether to trust that internal (bogus) timing table, or ignore it and read the real timings straight from the panel via DDC/GMBUS EDID:
- Flag = no (stock Apple) → driver blindly applies the fake 1280x800@72.5MHz mode to the real 1680x1050 panel → exactly the corruption described above.
- Flag = yes (T430 VBT) → driver reads the real EDID from the panel (which is programmed correctly by the panel vendor) and gets correct timings → works.
- Field: LVDS EDID available
- Byte offset within the block: block data + 2 (the 3rd byte of the 24-byte block, right after panel_type/panel_type2)
- Bit mask: 0x40
- Change: 0x33 → 0x73 (only bit 6 changes)
That single byte is located, in this firmware image, inside the FFS file with GUID 6A5F1EF9-C478-42BA-A4DB-C7846CC7DB57 ("Intel(R) Sandybridge Mobile PCI Accelerated SVGA BIOS"), which sits behind an LZMA-compressed, GUID-defined (certificate-wrapped) section. Inside that, at absolute offset 0x1425 within the decompressed 64 KB raw section body, is the byte to change.
2. Open the dump in UEFITool v0.28 (!) (https://github.com/LongSoft/UEFITool/releases/tag/0.28.0)
3. Locate the file with GUID 6A5F1EF9-C478-42BA-A4DB-C7846CC7DB57
4. Drill down through: compressed section → GUID-defined section (certificate/preamble wrapper) → the innermost Raw section. Its body is the 64 KB legacy VBIOS/VBT blob (you'll see the ASCII string $VBT SANDYBRIDGE-M if you inspect the hex).
5. Extract that raw section's body, and at offset 0x1425 change the byte from 0x33 to 0x73.
Note: You can try using my patched VBT that I attached to this comment
6. Back in UEFITool, on that same raw-section tree node, use "Replace body" (not "Replace as is" — the extracted blob is the section body only, without a section header, so "Replace body" is what correctly matches it; UEFITool then re-handles compression/headers for you).
7. Save the image.
8. Sanity-check before flashing:
- Final file size must match the original exactly (8 MB for this board).
- The flash descriptor + Intel ME region should be byte-for-byte identical to the original (diff the two dumps — all changes should fall strictly inside the BIOS region).
- Optionally, extract the VBT again from the patched image and run it through intel_vbt_decode to confirm LVDS EDID available: yes and that nothing else in the VBT changed.
9. Flash the patched image using a programmer. After that you can install the Intel HD 3000 graphics driver (Boot Camp or generic — both work now) in Windows.
I recommend installing Windows in Legacy mode, because the Cirrus Logic sound does not work in UEFI mode.
Caveats / things to verify on your own hardware
- The exact byte offset (0x1425 inside the raw section, block-40 field at block-offset +2) is specific to this particular firmware dump/board revision. If your dump differs, re-locate the $VBT signature and the LVDS Options block (BDB block 40) yourself — the field is the first byte after panel_type/panel_type2, bit 0x40.
- This fix worked without touching the VBT checksum byte — a naive "sum of all VBT bytes = 0" checksum did not validate even on the untouched original dump, suggesting this checksum isn't strictly enforced by this platform's firmware/GOP. If your board behaves differently (e.g. refuses to POST after the patch), you may need to investigate/recalculate the checksum.
- This specific fix (EDID flag) worked cleanly for a 1680x1050 panel, where the LVDS channel count is unambiguous from pixel clock alone. If you're on the base 1440x900 panel, you may also need to deal with the dual-channel-LVDS-vs-clock ambiguity described above, since Windows has no equivalent of Linux's DMI-based quirk table.
@dosdude1, FYI
Finally, with AI i got fully worked Windows setup on my de-gmux'd MBP2011 with modified stock UEFI firmware
Fixing corrupted Windows display on a de-gmux'd MacBook Pro 8,2 (single Intel VBT byte patch)
Background / hardware setup
- MacBook Pro 8,2 (15", mid‑2011), 1680x1050 panel.- gmux chip physically removed from the logic board; LVDS lines from the Intel HD 3000 are bridged directly to the panel connector with jumper wires.
- Backlight control routed through a modified hub, hand-wired.
- Linux (native EFI, no coreboot) works perfectly out of the box — correct resolution, no artifacts.
- coreboot builds also work, using a VBT borrowed from a Lenovo ThinkPad T430, but that setup has trade-offs: sleep/resume issues, no ambient light sensor, a few other rough edges.
- Goal: run Windows natively on the stock Apple EFI firmware (no coreboot), via Boot Camp-style Intel graphics driver.
The symptom
- Boot logo (EFI GOP framebuffer) displays correctly.- As soon as the Intel HD 3000 graphics driver loads (both the generic Intel driver and Apple's own Boot Camp driver — same result with either), the display becomes corrupted:
- Image appears stretched, part of it doesn't fit on screen.
- Picture looks like it's drawn "every other line" (interlaced/torn look).
- Colors washed out.
- This happens on the stock, unmodified Apple EFI firmware — not just on coreboot builds.
Diagnosis
Both firmware images (stock Apple EFI, and the coreboot build using the T430 VBT that works correctly) contain an Intel VBT (Video BIOS Table) embedded inside the legacy "Intel(R) Sandybridge Mobile PCI Accelerated SVGA BIOS" Option ROM module (this same table is also what the native GOP driver and, at runtime, ACPI OpRegion expose to the OS graphics driver).Extracting and decoding both VBTs with intel_vbt_decode (from intel-gpu-tools) and diffing the LVDS Options block (BDB block 40) revealed the key difference:
| Stock Apple VBT | T430 VBT (works) | |
| LVDS EDID available | no | yes |
| LVDS panel timing table (BDB 42 | 1280x800 @ 72.5 MHz (generic placeholder, unrelated to the real panel) | 1024x768 @ 65 MHz (also a placeholder, but irrelevant) |
Root cause: Apple's own VBT ships with a completely generic/unused LVDS panel timing table, because macOS never reads panel configuration from the Intel VBT at all (it comes from the EFI device tree / AppleGraphicsControl instead). Apple simply never bothered to fill in real values here.
The LVDS EDID available flag tells the Intel driver whether to trust that internal (bogus) timing table, or ignore it and read the real timings straight from the panel via DDC/GMBUS EDID:
- Flag = no (stock Apple) → driver blindly applies the fake 1280x800@72.5MHz mode to the real 1680x1050 panel → exactly the corruption described above.
- Flag = yes (T430 VBT) → driver reads the real EDID from the panel (which is programmed correctly by the panel vendor) and gets correct timings → works.
The fix
Flip a single bit in the VBT's LVDS Options block (BDB block 40):- Field: LVDS EDID available
- Byte offset within the block: block data + 2 (the 3rd byte of the 24-byte block, right after panel_type/panel_type2)
- Bit mask: 0x40
- Change: 0x33 → 0x73 (only bit 6 changes)
That single byte is located, in this firmware image, inside the FFS file with GUID 6A5F1EF9-C478-42BA-A4DB-C7846CC7DB57 ("Intel(R) Sandybridge Mobile PCI Accelerated SVGA BIOS"), which sits behind an LZMA-compressed, GUID-defined (certificate-wrapped) section. Inside that, at absolute offset 0x1425 within the decompressed 64 KB raw section body, is the byte to change.
Patch procedure
1. Dump the current firmware (e.g. via flashrom).2. Open the dump in UEFITool v0.28 (!) (https://github.com/LongSoft/UEFITool/releases/tag/0.28.0)
3. Locate the file with GUID 6A5F1EF9-C478-42BA-A4DB-C7846CC7DB57
4. Drill down through: compressed section → GUID-defined section (certificate/preamble wrapper) → the innermost Raw section. Its body is the 64 KB legacy VBIOS/VBT blob (you'll see the ASCII string $VBT SANDYBRIDGE-M if you inspect the hex).
5. Extract that raw section's body, and at offset 0x1425 change the byte from 0x33 to 0x73.
Note: You can try using my patched VBT that I attached to this comment
6. Back in UEFITool, on that same raw-section tree node, use "Replace body" (not "Replace as is" — the extracted blob is the section body only, without a section header, so "Replace body" is what correctly matches it; UEFITool then re-handles compression/headers for you).
7. Save the image.
8. Sanity-check before flashing:
- Final file size must match the original exactly (8 MB for this board).
- The flash descriptor + Intel ME region should be byte-for-byte identical to the original (diff the two dumps — all changes should fall strictly inside the BIOS region).
- Optionally, extract the VBT again from the patched image and run it through intel_vbt_decode to confirm LVDS EDID available: yes and that nothing else in the VBT changed.
9. Flash the patched image using a programmer. After that you can install the Intel HD 3000 graphics driver (Boot Camp or generic — both work now) in Windows.
I recommend installing Windows in Legacy mode, because the Cirrus Logic sound does not work in UEFI mode.
Result
Confirmed working: with this single-bit patch on the stock, unmodified Apple EFI firmware, the Intel HD 3000 driver in Windows now initializes the display correctly on a de-gmux'd MacBook Pro 8,2 with direct LVDS wiring and a hand-wired backlight — no stretching, no interlacing artifacts, correct colors. No coreboot needed, and therefore none of the coreboot-side trade-offs (sleep/resume quirks, missing ambient light sensor, etc.).Caveats / things to verify on your own hardware
- The exact byte offset (0x1425 inside the raw section, block-40 field at block-offset +2) is specific to this particular firmware dump/board revision. If your dump differs, re-locate the $VBT signature and the LVDS Options block (BDB block 40) yourself — the field is the first byte after panel_type/panel_type2, bit 0x40.
- This fix worked without touching the VBT checksum byte — a naive "sum of all VBT bytes = 0" checksum did not validate even on the untouched original dump, suggesting this checksum isn't strictly enforced by this platform's firmware/GOP. If your board behaves differently (e.g. refuses to POST after the patch), you may need to investigate/recalculate the checksum.
- This specific fix (EDID flag) worked cleanly for a 1680x1050 panel, where the LVDS channel count is unambiguous from pixel clock alone. If you're on the base 1440x900 panel, you may also need to deal with the dual-channel-LVDS-vs-clock ambiguity described above, since Windows has no equivalent of Linux's DMI-based quirk table.
NICE! I'll definitely be adding this to my procedure when Demuxing people's MacBooks!