Jump to content

Xeon3D

Members
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    1

Xeon3D last won the day on May 23

Xeon3D had the most liked content!

Community Reputation

2 Neutral

About Xeon3D

  • Rank
    Private First Class
  1. Attached is my IOReg @Hervé Marcos’s MacBook Pro.zip
  2. 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[email protected], NVDA,[email protected], NVDA,[email protected], NVDA,[email protected] An HDMI connected screen will show up on NVDA,[email protected] 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 [email protected] with a port number of <04 00 00 00> which also matches the Connector 4 info. NVDA,[email protected] port-number is <05 00 00 00> which matches the Connector 5's info. That leaves us with NVDA,[email protected] 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.
  3. @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
  4. Hello all. I own a otherwise, very supported laptop for OS X (Dell Precision M4800, QHD+ version so with internal eDP connector). After installing macOS and without any kind of injection, I get fully accelerated HDMI and DisplayPort but the internal screen is blank unless I boot with nv_disable=1 (currently using Clover). I've been researching this problem for some weeks now and it seems it may be due to one of these issues: - Bug in K2100M BIOS' DCB table. There's an LVDS entry on the DCB Table (0) which I believe is picked by the Apple Nvidia Drivers. - Errors in DSDT or the SSDT-5 ACPI tables. I've opened up a Repo with the information I already found which is available @ https://github.com/Xeon3D/PrecisionMx800-Hackintosh Sadly my knowledge of ACPI (and I've tried reading the 1000+ PDF, but my lack of programming skills aren't helping as well, not to mention English is not my native language) and connector patching is poor, so I was thinking that maybe with the help of @Hervé and @Jake Lo and You, we might get somewhere.
  5. With that folder and an external HDMI screen, I was able to install it, clover, and copy the EFI folder to the proper place, and the kexts (the marked ones) to /L/E. I'm still unable to see anything on the main lcd and the other one I have is too tiny (7" HDMI) for me to do any proper diagnostics for a while. I'm trying to get a larger HDMI cable so I can connect it to my TV. Any ideas on how to make the internal screen work? mine is eDP
  6. Just did. Will try using that EFI folder now
  7. Quadro K2100M @Bronxteck, do you reckon I should be able to get to the installer with that pack? It seems (looking at config.plist) that it is tailored for iGPU\nVidia combos, as it has intel injection enabled. Which options do you think would be better in my specific case?
  8. Hi. I'm trying to install Mojave in a QHD+ nVidia only (no intel, as it doesn't support QHD+ screens), but I'm unable to get past the verbose part. when it should switch to GUI, it's just a black screen. I've been trying to use one of the packs present here for HighSierra, since I couldn't find any for mojave, but it seems it doesn't work because I don't have an Intel GPU on this laptop (not in windows either). Attached is the pack I'm trying to use. Also attached is a Windows-AIDA64-extracted DSDT.AML First time trying to hackintosh this laptop, previously having owned a (very nice to install osx) Probook 6570b, so i'd appreciate any help given. Dell m6800 HS 10.13.4.zip DSDT.zip
  9. Are you really contemplating giving them any more money? What about next time they figure out a way of extorting more money from us? Move now. I've been online too long to know better.
  10. If one reads their last email properly you will see that they terminated the license and even refunded the last renovation. So the 500 will do nothing in regard to that. But it's enough iirc to get a copy of vbulletin. Use it to transfer the contents of this forum to it and do another donation run to remove their copyright notice. My 0.02€
  11. Hi. I'm a recent (and proud) owner of a M4300 (got it for €30), and I got it since it looked very compatible on the compatibility list, but to my surprise, I guess not much work has been done on the Extra bootpack for it. To be honest, I'm not really up-to-date on the new hackintosh thingies (Clover, et al) even tho I've been here since the deadmoo (or was it deadcow? can't remember!) image days. Every installation media and every install I did, and believe me when I say I've done a few, was either handmade or thru myhack (to save time honestly) and to my surprise, I'm glad you (we?) are using myhack as well to create the media. I really haven't looked at EDP to be honest, but from what I see it looks it's just not updated enough. Then again, I was never a fan of post-install do-it-all apps. It's my believing that whatever Extra folder is able to boot the system, should be able to boot the install media (and vice versa) so I don't really see a point in having something like EDP (or the stupid beast thingy from "thiefymacx"). Having said this, I'm going to be working on creating an updated Extra folder that should be able to boot the Installation media and at the end of the install if the user chooses to install that extra, it should be everything he needs to do to be able to boot and use a nearly fully working OS X. I'll be opening up a repo at github soon where people can contribute. I've already recompiled the DSDT with no errors and three warnings (but I'm trying to get rid of those too), and got a few nice kexts (Patched AppleHDA for Mavericks at least) which should be in the repo soon. And since the M4300 is similar to the D830, everything should work there too. But note that since I only own a Quadro-based FullHD+ M4300, support might not be the best for the Intel GPU-based ones. So if you own a D830 or a M4300 hop in and say hello!
×
×
  • Create New...