Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

hungerfish · 2015-07-20 10:22:28

I haven't used the wireless since going to 4.1 but I'll give it a try later. I've never tried with the broadcom-wl, but I know from days past that using b43 has always been kind of a hassle.
It frequently lost connections, or degraded in performance, and no amount of fiddling seem to really help. I hope(d) that after 4.0 it would be working better, because the devs cleaned up the b43 driver, but I haven't done any extensive testing lately, because I just use ethernet when at home these days.
I'll give it a whirl later, meanwhile, try the other driver, maybe you'll be lucky and it will just work.

Sidenote: If you are running in efi mode, maybe going back to csm could yield an improvement.
I'm not really satisfied with the mbp's 'behaviour' when running linux in efi mode, despite the 'gains' we've made here...

boterock · 2015-07-20 14:03:14

I don't need dual boot (i'm only running arch) so I don't need CSM-mode if I understand correctly.
So I could just run arch in BIOS and would be ok? I installed in EFI-mode because I remember running windows with bootcamp did not have any power management (never tried running windows only, with the disk as mbr, but i imagine it would be no different) and the pc was always running hot and with poor battery life
I wanted power management so I thought EFI was the way to go
If installing bios-only works better, and has power management, I don't have really any reason to keep using EFI

hungerfish · 2015-07-21 07:27:20

So first off, running '4.1.2-2-ARCH' with the b43 driver gives me a working wireless setup after boot. No need for the 'suspend->resume-cycle'.
I don't have anything configured for this to work (I think), and this holds true for both efi- and csm-modes.

I'm sadly still having the same connectivity problems that I've always had using this driver, so during my 'extensive testing'(in efi-mode) consisting of about 30min of browsing and watching a youtube video (1080 & 720*see below) I got to about half-time before the connection 'brakes'(it does not disconnect). I could however, just reconnect/reset the connection and continue browsing.
I am using the b43-firmware by the way.

I don't need dual boot (i'm only running arch) so I don't need CSM-mode if I understand correctly.

In an ideal world, you would never need csm-mode on an efi system (like the mbp) and the 'ugly hacks'(hybrid mbr) that go along with it.
But Apple implemented it the way they did (on the mbp7.1), presumably because of better support for windows 7 (only later windows versions 'properly' support efi).

Up until recently, you had to do csm-mode when running linux to get the proprietary nvidia driver to work at all.
Thanks to fumfi we now have a way of getting the nvidia blob to work when booting in efi-mode, so using csm/efi-modes doesn't really depend on you having a dualboot setup at all.

I wanted power management so I thought EFI was the way to go

I don't know about power-management problems specific to csm-mode, if anything I've found the mbp's 'behaviour' as alluded to in my earlier post slightly better performance/power/thermal wise (subjective!). So you could try csm-mode and see if you get better results. Note that you will need to probably change your partition table(refer to wiki) so make backups!

*note: As mentioned, my 'testing' included watching youtube vids. I've noticed that when in efi-mode, I can forget about 1080 as 'accelerated video rendering' is disabled according to youtube's flashplayer. The same video, while in csm-mode works fine in 1080. So maybe another reason to just stick with csm-mode?

** I've written this post whilst in csm-mode and I've been connected via wifi for well over 30mins, so maybe the connectivity is also better...

boterock · 2015-07-21 13:14:32

okay I understand, I confused csm-mode with hybrid-mbr, csm-mode is bios-booting, while the other is bios-booting with gpt...
I've been watching videos fine with my efi installation (using html5 player, seen no issues)
anyway I will try csm-mode, its too bad that efi does not work well... I hope that solves all my issues
thank you again

JohnWinkerbelt · 2015-07-21 18:28:02

Hey there again, it's nice to see that a solution has shown up about this problem, so to carry on the post, on my old Arch with CSM it were always broadcom-wl. Are there technical benefits in using the b43 or brcm80211 driver? Except that the first one is reverse engineered and the second one opensourced? I once saw my friend installed the b43 driver in the past, but he had a lot of trouble getting it to work properly. That scared me somehow.

A big thumbs up for otonvm hinting to this solution, it was a rough way to go.. only because of two settings apparently..

About the CSM-mode, just like hungerfish mentioned, it is "nasty", "ugly" and "not even standard", but it works. With this, you can use MacOS, which only uses the GUID Partition Table (gpt) and another OS, which only works with the master boot record (mbr).
This hybrid-mbr is created by making a normal gpt table and partition, then forcefully write an mbr table (with same information of the gpt partitions) into the header. Voilà, there you have a "pimped" gpt partition with mbr header (hybrid-mbr), which can be read by both EFI and BIOS systems. Naturally, you have to redo these steps, if you changed the partitioning.

Now back to the EFI-mode and its little nice detail, the nvidia graphics clock is even lower than it was in CSM-mode (~240 Mhz vs. ~101 MHz). It seems that due the pure efi mode, the API to control the clocking finally works properly. Maybe now, the overclocking works too?
After measuring the system with powertop, I conclude the EFI-mode even consumes about ~15% less power than the CSM-mode. Of course, no real and complex measure tools are used here.

About the lack of youtube acceleration with flash, which hungerfish has to fight with, assuming you have everything about vdpau installed, this is something you should try:

sudo mkdir /etc/adobe
sudo echo -e "EnableLinuxHWVideoDecode = 1\nOverrideGPUValidation = 1" | sudo tee /etc/adobe/mms.cfg

After creating the config and setting the important parameters, reload the page or restart firefox, look at the "nerd stats" of the flashplayer or the stats in the nvidia-settings, if it finally accelerate properly with gpu.

That's all for now.

Last edited by JohnWinkerbelt (2015-07-25 19:03:24)

otonvm · 2015-07-22 11:26:51

boterock wrote:

Hello, hope you are still here.
A little time ago (like a month) I started using arch with gnome, after using ubuntu (and hating unity) for like 3 months.
I thought trying arch would be a great way to learn about arch (and it surely has been).
Your guide (hungerfish and fumfi) has been a great help and I also have my macbook with arch with nvidia drivers. Thank you very much for that
The only issue I have left is the wireless, requiring to close and open the lid to work.
I think this also has others issues behind, because the wireless is very unstable, today I was trying to get steam home streaming to work, and even setting it in the lowest bitrate did not work, jumping between 3mbit and 200kbit every 20 seconds or so..
you say that the 4.0.1-ARCH kernel seems to work, but I have 4.1.2-2-ARCH and it does not work. I don't know what could be happening.
I installed the b43 driver following the instructions here https://wiki.archlinux.org/index.php/Broadcom_wireless, installing AUR: b43-firmware, is that the one you are using too?
I don't know what else it could be, any help would be appreciated.
Thank you again for your help

Hello!
I don't know about the others but I'm still resisting.
I've been using arch exclusively for a month now, almost since the new grub/efi hacks were discovered.

Unfortunately wifi is a moving target. First only wl drivers worked, now only b43 drivers work and not too well as you suggested.
It's "ok" for small stuff but at home I'm using a usb stick from Tp-link, the TL-WN722N which loads the atheros drivers that should be compatible and stable.
And it's allright but I still get random disconnects from time to time, just rarely.

So yeah... Get a long ethernet cable?

Still, even with these problems, I'm happier with arch+gnome on my old laptop than I was with MacOS that recently became virtually unusable.

Oh, and get libinput set up for the touchpad, it's great!

Good luck!

markus21 · 2015-08-28 13:54:00

Hey there!

I just wanted to migrate to Linux / Arch again. Last time I've installed it was back in 2011 with refit and legacy grub.
Now I finally got systemd-boot to start Arch in EFI mode but the proprietary nvidia driver obviously won't work.

The wiki entry to the macbook 7,1 metions the ability to a) use a special grub parameter or b) use a udev script as a workaround.

"Running the drivers in efi-mode requires setting some PCI registers before the kernel modules get loaded, preferably using a udev hook or GRUB script."

Reading this thread I only found the grub solution. So I was wondering how a udev script could look like to get the same effect with systemd-boot...
I could not find anything about this...

Thanks for advise!

* I created a new thread, because I mostly would like to know how to issue the setpci command during a systemd-boot process: https://bbs.archlinux.org/viewtopic.php … 0#p1557330

Last edited by markus21 (2015-08-29 07:34:05)

hungerfish · 2015-08-29 08:38:26

While I'm not saying that this isn't possible 'somehow' without using grub, I really don't understand why you don't just use grub!? Grub in efi mode is just another *.efi binary, which you can use to issue the setpci commands, then load the kernel - or if you so choose another *.efi binary, like systemd-boot. I myself looked around for a non-grub solution and came up empty. I don't know what the wiki is referring to as all my attempts to call the setpci commands 'after' loading the kernel didn't work. Maybe save yourself some time

On the other hand, if you figure this one out, be sure to tell us how!

markus21 · 2015-08-29 08:57:47

Well right now, I wished I would have installed grub2 in the first place. I wasn't really aware of this problem before I tried out systemd-boot.
I thought systemd-boot is the best way to go, since i only need arch to boot and nothing else... So i thought it would be faster, too.

But as you pointed out grub seems to make more sense here...

BTW: braodcom-wl-dkms from aur works just fine for me, including 5GHz support... Looks like there was an update to the wl driver, so it works again with 4.x kernel

Last edited by markus21 (2015-08-29 10:06:10)

fumfi · 2015-09-01 22:34:47

hungerfish wrote:

I don't know what the wiki is referring to as all my attempts to call the setpci commands 'after' loading the kernel didn't work.

I added this udev idea to the wiki because you're right: after loading the kernel, to be more specific, after loading the nvidia kernel module, it might be too late for setting the registers. Even more if systemd is involved with its parallelized boot which might run X too early. So my thought was actually towards creating a udev rule that hooks into the PCI subsystem on the PCI bridge and graphics device ids that (1) issues the setpci commands and (2) modprobes the nvidia module. That way (hypothetically), The X driver would wait for the kernel module and udev ensures that the setpci commands are executed first. So there would be a resolution of the grub dependency and make it a more generic solution.

But to be honest, I never tried this out. And meanwhile, I have sold that mbp 7,1 and replaced it with a 2015 air which btw boots fine from an SDXC in pure EFI. It has other issues with the Intel driver, though...

sleeping · 2016-01-09 23:53:20

Thank you for all your efforts to make people able to use their MacBooks with a more worthy operating system.
In my case, I tried to install Darwin Debian, Xubuntu, Linux Mint; in all cases I was able to set the correct PCI like explained here, but unfortunetely, x-org still was unable to load the NVIDIA module.

In the hope that Arch would offer me more flexibility, I decided to give it a last shot.
However, unlike the Darwin-based distros, Arch (obviously) does not install grub by default.
My question is if I can install GRUB alongside with refind, so that I can select GRUB from refind...
If so, where should I install grub?

Any help is greatly appreciated.

Last edited by sleeping (2016-02-06 19:16:40)

hungerfish · 2016-01-11 13:44:39

My question is if I can install GRUB alongside with refind, so that I can select GRUB from refind...

To answer your question, yes, yes you can!
Once you have REFIND installed it should automatically find grub on your disk if its installed.
This assumes you already have a working system though, but since you don't provide any details about your system/setup its not really possible to assist you more specifically.
Also, I'm pretty certain you meant 'Debian', not 'Darwin'

besworks · 2019-02-27 00:08:52

I know this thread (and this hardware) is kind of old but hopefully this helps somebody out there.

I managed to get the proprietary Nvidia drivers to work using rEFInd without GRUB by setting the PCI registers and booting via an EFI shell script like this:

mm 04000004 1 ;PCI :7
mm 0017003E 1 ;PCI :8
fs1:\linux.efi root=PARTUUID=27f79559-272a-e340-99fd-0c3ad19e53b2 rw initrd=/initramfs-linux.img

You might need to change fs1:\ to point to your /boot partition depending on your partition table layout.

linux.efi is a symlink that I created pointing to vmlinuz-linux because the shell won't run any executable that doesn't end in a .efi extension.

You need to specify your unique PARTUUID of your root partition.

Save the script to the root of your ESP partition as macbook-arch.nsh

Download the v1 uefi shell binary and put it in refind's tools_x64 directory.

Then add a boot entry to your refind.conf like so (assuming fs0 is your ESP) :

menuentry "Arch" {
        icon /EFI/refind/icons/os_arch.png
        loader /EFI/refind/tools_x64/shell.efi
        options "fs0:\macbook-arch.nsh"
}

robopepe · 2019-06-07 05:48:48

besworks wrote:

I know this thread (and this hardware) is kind of old but hopefully this helps somebody out there.

Thank you so much for posting this! This got my 3d acceleration working on the Geforce 320M (mac mini) in arch. Nouveau wouldn't work so the nvidia blob using this method was my only option. You legend. The only thing I did differently was get the v1 efi shell from the arch install media (location found from checking the arch wiki:

https://wiki.archlinux.org/index.php/Un … UEFI_Shell

Last edited by robopepe (2019-06-07 05:52:38)

hubearth · 2019-07-18 17:21:35

besworks wrote:

I know this thread (and this hardware) is kind of old but hopefully this helps somebody out there.
I managed to get the proprietary Nvidia drivers to work using rEFInd without GRUB by setting the PCI registers and booting via an EFI shell script like this:

Hey besworks!

Thank you so much for this. It is the only way that my Nvidia GT 330M (on a macbook pro 15" mid-2010) doesn't end up straight to blackscreen on boot.
Although, I still have the same problem that I have booting in BIOS mode. The nouveau driver work somewhat fine, but with some issues that push me to proprietary driver.

I've tried most of the solution found online, but nothing works.
In the last resort, I'm looking to disable the integrated intel gpu before loading the kernel. And I think you can help me with that.

Can you point me to documentation or give me a hint as to how to do that in a efi shell script?

Affecting the '04' and '3E' PCI registers on the bus and the nvidia card did the trick, but I don't have a clue as to what these registers are and how to find what register needs to be set on a specific device to disable it. Any idea as to where I should start?

The nvidia page mention that gpu card may be unstable if the intel card is not properly disabled.

The problem I'm facing is that the nvidia GPU powers off as soon as it receive a call. From a system booted in single mode, the nvidia module loads without error, but as soon as I start nvidia-persistence service or run nvidia-bug-report.sh, the screen become messed up. When I start X, I see the desktop loading and, after 1 second, the screen shuts down. The machine is still responding and is accessible via ssh.

Since the hardware is kinda old, I suspect that the system tries to jump back to intel card after load, and that the nvidia driver is not preventing it properly.

fortytwo · 2020-04-06 12:30:03

Hey, thank you very much for posting, besworks.
Could you elaborate how you came up with this?

mm 04000004 1 ;PCI :7
mm 0017003E 1 ;PCI :8

These are my IDs

pci@0000:00:17.0          bridge         MCP89 PCI Express Bridge
pci@0000:04:00.0          display        MCP89 GeForce 320M

And could you tell me where i can find refind tools directory when i installed refind from within osx recovery?
Thanks for any support.

xirxes · 2020-06-14 04:08:35

Edit: 2020/06/20 Removed statement about booting without .efi extension as I was wrong about it working. Added pacman hook.

In an effort to clean up and make sure this laptop would keep going long term, I tried to simplify the boot process, skipping rEFInd and just booting the EFI shell directly. This should work for you on a Geforce 320m equipped Macbook Pro, or Mac Mini. You'll still need your kernel to have a .efi file extension for the older EFI shell to boot it. I use a pacman hook to copy the vmlinuz_linux file to vmlinuz_linux.efi after updates. If your EFI partition supports symlinks you can do that instead of the hook.

To start, download the x64 compatibility EFI Shell from tianocore here

Copy it to the root of your system EFI partition as shellx64.efi

Create startup.nsh in the root of your EFI partition and populate it with the following, substituting your own PARTUUID, and ensuring fs0: corresponds with your EFI partition number.

mm 04000004 1 ;PCI :7
mm 0017003E 1 ;PCI :8
fs0:\vmlinuz-linux.efi root=/dev/sda2 rw initrd=intel-ucode.img initrd=initramfs-linux.img

To make your system boot the EFI Shell directly, add the shell as a boot option with the following command, ensuring your disk matches the drive your EFI partition is on.

efibootmgr --create --disk /dev/sda --loader shellx64.efi --label "EFI Shell" --verbose

Run efibootmgr to view your current boot options, and set your new option as the primary like so.

$ efibootmgr
BootCurrent: 0002
BootOrder: 0002,0001,0000,0080
Boot0000* rEFInd Boot Manager
Boot0001* GRUB
Boot0002* EFI Shell
Boot0080* Mac OS X
Boot0081* Mac OS X
Boot0082* 
BootFFFF*
# efibootmgr -o 2,1,0,80

If you want this integrated into rEFInd just add the following entry to your refind.conf.

menuentry "Arch PCIEfix" {
    icon    /.VolumeIcon.icns
    loader  /shellx64.efi
}

I have rEFInd installed in the fallback location, so if I need to boot to it instead of the EFI shell I can just hold the option key on boot and choose the drive from Apples boot manager. Just use the --usedefault option when running refind-install

refind-install --usedefault /dev/sdXY

For now, just copy your vmlinuz_linux to vmlinuz_linux.efi (Don't rename, you'll need the original if you want to use an alternative boot method) or symlink it if your efi file system supports it.

Add this pacman hook to automate copying the kernel after updates.
/etc/pacman.d/hooks/999-kernel-efi.hook

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux

[Action]
Description = Copying vmlinuz-linux to vmlinuz-linux.efi to enable efi stub booting on efi 1.x firmware
When = PostTransaction
Exec = /usr/bin/cp -f /boot/vmlinuz-linux /boot/vmlinuz-linux.efi

Last edited by xirxes (2020-06-20 20:39:53)

atcq · 2020-09-29 19:05:17

Love this thread so much information in here

Unfortunately setting the PCI registers doesn't work for me (anymore?).

I tried every approach to set the registers pre kernel load. Using

setpci - s "00:17.0" 3e.b=8

via Grub

mm 0017003E 1 ;PCI :8

via EFI shell v1.x script in rEFInd/directly via efibootmgr

and even doing it directly in the (presumably) EFI shell v2.x with

mm 0017003E 8 -w 1 -PCIE

and then booting.

Checking setpci when the system is running always provides the following output for 0017003E though:

# setpci -s "00:17.0" 3e.b
0a

At first I thought the commands didn't work to set the registers until finally I had the idea to check in Grub console via setpci and there it told me for address 0017003E it was indeed set to 8.

So now I'm quite confused and have no idea at which point the value could change from 08 to 0a after loading the kernel.

Any ideas as to how to debug/investigate this further are welcome! I know the hardware is old and quite restrictive but as long as it works I'd like to try to use it

AnEnthusiastOfSorts · 2022-03-30 14:59:00

Seems like I'm not the only one. I've tried a variety of Linux distributions just to make sure it wasn't just me. It seems like for whatever reason, Arch does not properly set the PCI registers in any form or fashion. I made a post about this without any replies (my best guess is that no one knows why). I wonder if there may be a bug that no one has detected somewhere.

atcq wrote:

Love this thread so much information in here
Unfortunately setting the PCI registers doesn't work for me (anymore?).
I tried every approach to set the registers pre kernel load. Using
setpci - s "00:17.0" 3e.b=8
via Grub
mm 0017003E 1 ;PCI :8
via EFI shell v1.x script in rEFInd/directly via efibootmgr
and even doing it directly in the (presumably) EFI shell v2.x with
mm 0017003E 8 -w 1 -PCIE
and then booting.
Checking setpci when the system is running always provides the following output for 0017003E though:
# setpci -s "00:17.0" 3e.b
0a
At first I thought the commands didn't work to set the registers until finally I had the idea to check in Grub console via setpci and there it told me for address 0017003E it was indeed set to 8.
So now I'm quite confused and have no idea at which point the value could change from 08 to 0a after loading the kernel.
Any ideas as to how to debug/investigate this further are welcome! I know the hardware is old and quite restrictive but as long as it works I'd like to try to use it

Time4Tea · 2023-01-09 02:05:16

Hi, I wanted to post here, as I have been trying to get the nvidia GPU driver to work with this Macbook hardware and have also been having a lot of problems. I have read many of the previous posts here and have tried the suggestions about setting the pci registers before loading the nvidia module, but nothing is working - I invariably get a black screen and a system hang as soon as I try to start X11 (startx).

Firstly, I can confirm that those setpci commands to set the pci registers are definitely working. If I boot up the system into X11 with nouveau, and then change the pci register for the video card with setpci ... , the system freezes up right away.

I have tried a different approach to setting the pci registers on boot to the suggestions above. I have made a udev rule, as follows:

# Udev rule to set correct PCI register values for NVidia 320M GPU
# this is required for proprietary NVidia driver to work properly

KERNEL=="sda", SUBSYSTEM=="block", ATTRS{rev}=="1A01", \
DRIVERS=="sd", RUN+="/root/Scripts/set_pci_registers.sh"

I am triggering off of /dev/sda, since it seems likely the hard disk will be loaded early in the boot sequence. I have nvidia blacklisted, so it isn't being loaded on boot, and my udev rule is running the following script:

#!/bin/bash

# Script to set correct PCI registers on boot for NVidia 320M GPU

if [[ $(setpci -s "00:17.0" 3e.b) != 08 ]] ; then
  
        date > /root/pci_check.log

        echo "Checking for nvidia:" >> /root/pci_check.log
        lsmod | grep nvid >> /root/pci_check.log

        # Set pci registers:

        echo "Registers before:" >> /root/pci_check.log
        setpci -s "00:17.0" 3e.b >> /root/pci_check.log
        setpci -s "04:00.0" 04.b >> /root/pci_check.log

        setpci -s "00:17.0" 3e.b=8
        setpci -s "04:00.0" 04.b=7

        # Check registers are set correctly and output to a file:

        echo "Registers after:" >> /root/pci_check.log
        setpci -s "00:17.0" 3e.b >> /root/pci_check.log
        setpci -s "04:00.0" 04.b >> /root/pci_check.log
fi

This ensures that nvidia is not loaded before the pci registers are set. After booting to the terminal, I then verify that the registers have been set correctly, then modprobe nvidia and try startx (as a user). However, I get the same black screen and from the kernel.log file, it seems the nvidia module is tainting the kernel and causing an 'oops'.

So, I suspect the pci registers being set is not the issue here, but that the nvidia driver may have become broken at some point by a recent update. Does anyone know what was the last version of the nvidia-340xx driver that was known to work? Is there some way we can 'roll back' and try that?

I am using nvidia-340xx-dkms-340.108-31 on the LTS linux kernel (5.15.85-1-lts).

AnEnthusiastOfSorts · 2023-01-11 17:02:18

On Debian/Debian based distro(s), I used this:

https://www.if-not-true-then-false.com/ … a-patcher/

This didn’t give me any issues. It’ll probably work on Arch.

The only major thing I noticed was that you couldn’t see anything that’s CLI with the drivers, because it would give a black screen. Otherwise, everything worked fine.

I wonder how well or poorly KDE might run on this old GPU. Unfortunately, we are all stuck on Xorg, and since Nvidia doesn’t maintain their old drivers for their older hardware, there’s little chance that we’ll see full Wayland compatibility at full speed on this chip. You might encounter screen tearing, there’s a quick fix for Nvidia but I don’t remember where that is.

Last edited by AnEnthusiastOfSorts (2023-01-11 17:02:47)

Arch Linux

#76 2015-07-20 10:22:28

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#77 2015-07-20 14:03:14

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#78 2015-07-21 07:27:20

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#79 2015-07-21 13:14:32

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#80 2015-07-21 18:28:02

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#81 2015-07-22 11:26:51

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#82 2015-08-28 13:54:00

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#83 2015-08-29 08:38:26

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#84 2015-08-29 08:57:47

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#85 2015-09-01 22:34:47

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#86 2016-01-09 23:53:20

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#87 2016-01-11 13:44:39

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#88 2019-02-27 00:08:52

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#89 2019-06-07 05:48:48

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#90 2019-07-18 17:21:35

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#91 2020-04-06 12:30:03

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#92 2020-06-14 04:08:35

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#93 2020-09-29 19:05:17

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#94 2022-03-30 14:59:00

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#95 2023-01-09 02:05:16

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#96 2023-01-11 17:02:18

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

Board footer