El Capitan on Inspiron 1720

[Hervé]

Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter

https://pci-ids.ucw.cz/read/PC/1180/0822

 

May work with VoodooSDHC kext but it'll need patching with PCI ids.

[griftopia]

So I found (new) VoodooSDHC kext from here (even though some lamented it gives panic on 10.11.6 while allegedly working on 10.11.4)

 

http://www.insanelymac.com/forum/topic/312536-voodoosdhc-sd-card-reader-for-el-capitan/

 

Patched it with my pci VVVV and DDDD. Did not work at all (while also no kernel panic, which is good)

 

Attaching my kext, just in case I'm doing something stupid.

 

 

VoodooSDHC.kext.zip

[Bronxteck]

it shows up in your DSDT under device pcie

Device (CRD0)
{
    Name (_ADR, 0x00010000)  // _ADR: Address
    Method (_INI, 0, NotSerialized)  // _INI: Initialize
    {
        SMI (0x95, 0x04)
    }
    Name (_S1D, Zero)  // _S1D: S1 Device State
    Name (_S3D, 0x03)  // _S3D: S3 Device State
}

weird though it's missing 

Name (_CID, EisaId ("PNP0D40"))  // _CID: Compatible ID

I guess the bios is super old.

you can try adding it in like this on top

Device (CRD0)
{
    Name (_CID, EisaId ("PNP0D40"))  // _CID: Compatible ID
    Name (_ADR, 0x00010000)  // _ADR: Address
    Method (_INI, 0, NotSerialized)  // _INI: Initialize
    {
        SMI (0x95, 0x04)
    }

    Name (_S1D, Zero)  // _S1D: S1 Device State
    Name (_S3D, 0x03)  // _S3D: S3 Device State
}

[Hervé]

It's the exact same model as fitted to the good old D430:

D430_ML:~ admin$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01)
00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01)
00:1c.1 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 2 [8086:27d2] (rev 01)
00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 3 [8086:27d4] (rev 01)
00:1d.0 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01)
00:1d.1 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 [8086:27c9] (rev 01)
00:1d.2 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 [8086:27ca] (rev 01)
00:1d.3 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 [8086:27cb] (rev 01)
00:1d.7 USB controller [0c03]: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 01)
00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation N10/ICH 7 Family SMBus Controller [8086:27da] (rev 01)
02:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev b4)
02:01.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] (rev 09)
02:01.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 18)
09:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express [14e4:1600] (rev 02)
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4311 802.11a/b/g [14e4:4312] (rev 01)
D430_ML:~ admin$ 

From memory, we could get it detected through VoodooSDHC kext but could not get it to work properly because the device apparently shares an IRQ with the Ethernet. I cannot say whether it would be the same on the 1720 of same generation but an older VoodooSDHC kext may work provided it can load under Sierra.

 

Griftopia, try this fat binary kext:

VoodooSDHC.kext.zip

[griftopia]

@Bronxtech. Funny you are concluding it is CRD0. Maybe I misread the IOReg. It showed CRD0 at DDDD = 0832 while Windows is showing the SD Host Controller at 0822. Anyways, it is what it is. Regarding the BIOS - what I have is latest from Dell.

 

@Herve. I will try your Voodoo kext. I'm assuming the way I patched it was okay (unless you also patched it), I will look. 

 

Not sure if I need both DSDT edit and Voodoo kext, so I will try all combinations and report results.

[Hervé]

The IOReg shows various devices under PCIE@1E:

* ethernet@0 -> Broadcom LAN card
* CRD0@1     -> Ricoh Co Ltd R5C832 IEEE 1394 Controller (1180,832)
* FRWR@1,4   -> Ricoh Co Ltd xD-Picture Card Controller (1180,852) so DSDT _DSM method seems inappropriate to me

then 3 x Ricoh devices:

* 1180,822@1,1 -> Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter
* 1180,843@1,2 -> Ricoh Co Ltd R5C843 MMC Host Controller 
* 1180,592@1,3 -> Ricoh Co Ltd R5C592 Memory stick Bus Host Adapter

In the DSDT, only CRD0, FRWR and CRD1 are defined. You do not necessarily need to inject anything for those missing devices in the DSDT. The LAN card is the vey proof of it; you just need the correct driver.
 
Use DPCIManager->PCI List tab to identify which kext is used for each device. You may have to add the other device 843 + 592 to the kext too. Experiment...
 
I take it you initially worked according to this, right?
 
This being said, you could also give a try to a DSDT Patch that injects a device for the card reader and declares it compatible with Apple's default SD card reader. This would be placed alongside the existing devices under PCIE and would look like this:

                Device (SDXC)
                {
                    Name (_ADR, 0x00010001)
                    Method (_INI, 0, NotSerialized)
                    {
                        SMI (0x95, 0x04) // or SMI (0x9D, 0x04)
                    }
                    Name (_S1D, Zero)
                    Name (_S3D, 0x03)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package ()
                        {
                            "device_type", 
                            Buffer ()
                            {
                                "Media controller"
                            }, 
                            "AAPL,slot-name", 
                            Buffer (0x09)
                            {
                                "Built-in"
                            }, 
                            "model", 
                            Buffer ()
                            {
                                "Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter"
                            },
                            "compatible", 
                            Buffer ()
                            {
                                "pci14e4,16bc"
                            },
                        }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                }

No guarantees of course, these are just pointers/ideas for experimentation...

 

I've got one question though: is the DSDT you posted of Inspiron1720 origin or does it come from another computer like the D630 (because it really looks like it does!)? I would not mind the raw table...

[griftopia]

@Herve. That explanation made more sense.

 

So I dropped in your Kext. I saw you already patched with PCI ids. Rebooted, and it stuck on boot. Found with -v the problem is I had left the SD Card in the slot. Not a real issue. More importantly I saw Voodoo kext getting loaded. I did see "Fail..." and "Dump..." lines on console. 

 

So tried again with SD card removed. Still don't see in System info under Card Reader or PCI sections, but decided to give it a shot. It "worked". Card was mounted on desktop and I was able to open and view the folder. However I have two problems

 

1) I put laptop to sleep leaving SD card in. When I resumed, I got back to desktop but laptop really sluggish. Mouse moves but I can't do anything. Also noticed Wifi and Bluetooth stop working and grayed out in task bar. USB ports also stopped working.

 

2) Power cycled laptop. Wanted to check if Voodoo kext causing sleep issues, because I know from prior failed experiences with card, it did break my sleep. This time never bothered to insert sd card. Simply put laptop to sleep. Then resumed. Blank display! This is interesting because seems it card in slot it wakes up, but not the other devices. But with card out, it does not find anything to wake up and thinks why bother turning display on? Needless to say, I had to power cycle the laptop.

 

After I removed the kext, my resume-from-sleep works as before and USB ports also continue to work after resume along with wifi/bluetooth. Phew!

 

So this is pretty much identical to anywhere I have gotten with any of my laptops as far as experimentation with SD card goes. Maybe like bronxtech said, my laptop/bios/etc maybe just too old. I will repeat the experiment with the DSDT edit as well as kext, and then only with just the DSDT. Meanwhile, if anything jumps out if you can advise...

[Hervé]

VoodooSDHC is known to cause Wake issues. I know of no fix unfortunately. That's why we've been lucky the DSDT patch to inject compatibility with Apple's device works on the Latitude Series.

 

Good luck with your future experimentations.

[Bronxteck]

sounds like the same issues we had with the D430 it shared IRQ's with other devices. devices would disappear.

[Hervé]

There were 2 x VoodooSDHC kext implementations: one with dma, one without. I guess Griftopia should try them both. From memory, they're still available on the Voodoo web site, failing that Google is our friend as usual...