M4800: Clover EFI pack requested for Catalina

[fabio64370]

Hi zogthegreat

 

I have got one DELL M4800 with AMD Fire Pro 5100, can you share your EFI folder please?

This should me to install Catalina on it?

Thanks for your help.

Fabrice

[Riley Cassel]

I hate to chime in with me too, however...

 

I have a m4800 with an i7-4800mq cpu, high res screen and Nvidia K2100 graphics.  I haven't been able to find an efi config that'll run the installer. 

 

If somebody could post one it'd be much appreciated

[Xeon3D]

@Riley Cassel, I have a working clover folder for Catalina, and the same hardware as you (K2100M, QHD+ screen which means eDP motherboard).

Good News = It boots into Catalina and most of the hardware is already setup.

Bad News = No internal screen unless you disable the nvidia drivers (nv_disable=1)

 

You can also find more information on my GitHub Repo regarding the M4800 and Hackintoshing here: https://github.com/Xeon3D/PrecisionMx800-Hackintosh

EFI.zip

[Hervé]

Guys, you may want to consult this old thread that explained a few things...

 

And @Xeon3D's repo is quite extensive on the matter too. It's a highly recommended reading as far as I'm concerned.

 

[leo_maccomic]

@Xeon3D, i have M4800 with the same hardware as you, can you give me your EFI with  K2100M, Full HD screen eDP fixed?

[Hervé]

eDP models were out of luck as far as built-in LCD is concerned (see @nsmartin last post in M4800 thread I linked above). I've not seen anything that changed this in the last 4 years. @Xeon3D quite clearly confirms this too...

 

This being said, I remember the days when Precision M4600 with nVidia graphics would too end up in a black screen when using MBP8,x Sandy Bridge SMBIOS. See here (Chameleon/Enoch) and here (Clover) for instance. People obtained a black screen unless they using a specifically tuned MBP6,x SMBIOS where the board-id was replaced by that of nVidia GPU-based MBP10,1 (Credits to @DuongTH from memory). MBP8,x models were either HD3000 (MBP8,1) or dual HD3000 + AMD Radeon HD 6xxx graphics (MBP8,2/MBP8,3).

 

So, given that:

• MBP6,x were Arrandale platforms running with dual 1st gen Intel HD + nVidia GeForce GT 330M (Tesla 2.0 GT216) graphics
• MBP10,1 was Ivy Bridge platform running with dual Intel HD4000 + nVidia GeForce GT 650M (Kepler GK107) graphics
• MBP11,1 was Haswell platform running with Intel Iris 5100 graphics only
• MBP11,3 was Haswell platform running with dual Intel Iris Pro 5200 + nVidia GeForce GT 750M (Kepler GK107) graphics
• MBP11,5 was Haswell platform running with dual Intel Iris Pro 5200 + AMD Radeon R9 M370X (Tropo GCN1.0) graphics

and that:

• Precision M4800:
  • nVidia Quadro K1100M is Kepler GK107
  • nVidia Quadro K2100M is Kepler GK106
  • AMD FirePro M5100 is Venus GCN1.0
• Precision M6800:
  • nVidia Quadro K3100M is Kepler GK104
  • nVidia Quadro K4100M is Kepler GK104
  • nVidia Quadro K5100M is Kepler GK104
  • AMD FirePro M6100 is Saturn GCN2.0

it may be worth looking into the SMBIOS matter again even as a desperate last attempt. Can't remember if that were ever considered or looked into in the past.

 

NB: MacBookPro11,x were last Mac laptops fitted with nVidia graphics to date.

[Xeon3D]

Hi @Hervé. I haven't quite given up on this yet. I believe that with your help we might solve this. Sadly my knowledge of OS X internals is not that great even tho I've been around since the deadmoo days.
 

From my findings in fiddling with Linux (xrandr + nvbios from nouveau's envytools), I managed to find out the connector numbers and where they'd go, this information is also confirmed by looking at my vbios' dcb table and is mostly the same as reported by fassl's old nvidia info mac utility:

 

So according to Linux and the VBIOS, there's 4 connectors of interest 4, 5, 7 and 8 (External Display Port, An Unknown (I assume it's a Dock connector), External HDMI and the internal eDP).

If we put together the VBIOS listing and the schematic we can assume:

 

Connector 4 ( DCB Entries 5 and 6) - Schematic's DP_A (which go to the DisplayPort Port)

Connector 5 ( DCB Entries 3 and 4 ) - Schematic's DP_B (which go indeed to the Dock Port)

Connector 7 ( DCB Entries 10 and 11 ) - Schematic's DP_C (which go to the HDMI Port)

Connector 8 ( DCB Entry 8 ) - Schematic DP_D (which go to the internal eDP connector)

 

If we look closely at the schematic, one also see's another connection from DP_D (maybe it's not DP_D but a fifth port?) to a LVDS Mux (where a connection from the iGPU also connects after passing thru a eDP to LVDS converter) which also go to the internal eDP/LVDS connector.

Since no iGPU is presented to us on the PCI bus, I'm assuming the line iGPU -> eDP to LVDS -> LVDS Mux -> LVDS/EDP Connector doesn;t exist. So what we have are 4 lines from the MXM Card to the various connectors. The ones that go thru either a converter or Mux (Like the MXM DP_C connection that goes thru a DP MUX then a DP/HDMI Demux or the DP_A that goes thru a DP Redriver before reaching the connector) work flawlessly. One can plug and replug different monitors at any time and macOS will find them and work wonderfully. I even tried a HDMI to DVI cable and connect it to a DVI only screen and it worked wonders.

 

So DCB Table-wise, what we need to focus on is the Connector 0 and 8.

When booting macOS Catalina without any kind of injection or DSDT modding, 4 outputs (is that the proper naming?) are found on IOReg: NVDA,Display-A@0, NVDA,Display-B@1, NVDA,Display-C@2, NVDA,Display-D@3

 

An HDMI connected screen will show up on NVDA,Display-D@3 with a port-number of <07 00 00 00> which matches the Connector 7 info.

An DP connected screen (thru a DP to HDMI adapter as I don't own any DP-able monitors) will show up under NVDA-Display-B@1 with a port number of <04 00 00 00> which also matches the Connector 4 info.

NVDA,Display-C@2 port-number is <05 00 00 00> which matches the Connector 5's info.

That leaves us with NVDA,Display-A@0 which should have a port-number of <08 00 00 00> since it's our internal screen, but it's port-number is <00 00 00 00> which is the DCB Entry 0 which goes to the LVDS connector using LVDS Signal Type which our system doesn't have. This is why the Motherboard with LVDS works wonderfully even with the same graphics card.

 

More notes from ioreg:

- All the connector-type properties for each "output" are <00 08 00 00> (HDMI) but Display-A and Display-B should be <00 04 00 00> (Display Port), I think.

 

According to some page I've read (I think it was the nvidia injection thread on insanelyMac), the nvidia driver goes thru the VBIOS and the DCB Table and starts checking which ports have a display connected. It seems it's catching the first DCB Table entry (which is invalid) and the other working 3 ports. This might be one reason why it isn't working.

 

Another possible reason why it doesn't work is our ACPI Tables. Namely the DSDT and SSDT-5.

 

Since DELL does use the same BIOS for every version (I counted 7) of the M4800's motherboard, the BIOS has to be LVDS and eDP compatible. But apart from the connector on the motherboard, there's also the difference of the eDP motherboards not having a iGPU.

 

Yet, on a Clover DUMP from the A26 BIOS for the m4800, on the DSDT.dsl there is:

- a _SB.PCI0.GFX0 Scope with 8 Devices in it (CRT,LCD,DVI,DVI2,DVI3,DP,DP2,DP3) and a couple of LID-related methods (ILID, ILDE) amongst others, Also on the _DOD Method, the return package contains:

 

        Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
        {
            If ((ECGB () == One))
            {
                Return (Package (0x08)
                {
                    0x0100, // (Device (CRT))
                    0x0400, // (Device (LCD))
                    0x0302, // (Device (DVI))
                    0x0303, // (Device (DVI2)
                    0x0300, // (Device (DP))
                    0x0301, // (Device (DP2))
                    0x0304, // (Device (DVI3)
                    0x0305  // (Device (DP3))
                })
            }
            Else
            {
                Return (Package (0x08)
                {
                    0x0100, 
                    0x0400, 
                    0x0302, 
                    0x0303, 
                    0x0300, 
                    0x0301, 
                    0x0304, 
                    0x0305
                })
            }
        }

Could it be that since the CRT is the first device, the nVidia driver is catching it first? Also, I don't get why the else bit is exactly the same. (the notes after // were added by me)

 

- another _SB.PCI0.GFX0 Scope with just a IBL1 Method.

- a _SB.PCI0.PEG0.PEGP Scope with a few Methods as well.

 

According to Windows, the screen is connected to the _SB.PCI0.PEG0.PEGP yet this scope (and I'd think this should be a device and not a scope) has only a few methods in it.

 

You can find a copy of the DSL here: https://pastebin.pl/view/raw/2fa08212

 

There's also the SSDT as I mentioned. On the SSDT-5-NvdTabl.dsl there is another Scope (\_SB.PCI0.PEG0.PEGP), this one with a lot of methods and another _DOD.

 

Here the story is a bit different:

Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
        {
            If ((ECGB == 0x01))
            {
                Return (Package (0x08)
                {
                    0x80000100, // CRT
                    0x80000400, // LCD (when ECGB = 1)
                    0x80007302, // DVI
                    0x80007303, // DVI2
                    0x80006300, // DP
                    0x80006301, // DP2
                    0x80007304, // DVI3
                    0x80006305  // DP3
                })
            }
            Else
            {
                Return (Package (0x08)
                {
                    0x80000100, 
                    0x8000A450, // LCD When ECGB=0
                    0x80007302, 
                    0x80007303, 
                    0x80006300, 
                    0x80006301, 
                    0x80007304, 
                    0x80006305
                })
            }
        }

So it seems here is the proper section regarding the dGPU and the one on the DSDT is regarding the iGPU.

Again the CRT device is returned first, and here the LCD address changes depending on the ECGB variable.

Sadly my ACPI knowledge isn't much more than this.

 

So in my understanding it could be fixed by doing one of these:

- Fix the device properties so that the proper properties are injected (so that connector 8 gets injected instead of 00 00 00 00)

- Fix the DSDT by removing the iGPU related stuff and maybe fixing the SSDT or even moving the properties from there to the DSDT if it is indeed the cause of the blank screen.

- Patching the VBIOS so that only the proper connectors work.

[Hervé]

You could possibly try and inject properties for the 1st output port NVDA,Display-1@0 in an attempt to redefine its properties; can't say if it'd work but nothing to lose really. Also, in order to avoid all confusion on the matter, I'd rename GFX0 (@00020000) to iGPU, then PEGP (@00010000) to GFX0.

 

Try and post a zipped copy of your IOReg if you can.

 

[Xeon3D]

Attached is my IOReg @Hervé

Marcos’s MacBook Pro.zip

[Hervé]

I see: no display detected on 1st output port.

 

I would suggest 2 x things:

1. try MBP11,3 SMBIOS
2. inject boolean property @0,AAPL,boot-display (set to 1) to 1st output port