Hervé

When you boot the USB installer and reach the Catalina installation screen, do not initialize your disk as an APFS drive. Instead, format your target partition as HFS+ (Journaled) and ensure you've used the GUID partition scheme of course. Your drive/partition will automatically get converted to APFS volume during Catalina's installation.

Yes, but no DFS; if you use AirportBrcmFixup, you may want to experiment with -brcmfx-country=#a boot arg... Or without the kext (and its boot arg of course!).

Native support for the card has nothing to do with your reported observation. You do what I've just posted!

The driver, no. Some boot parameters for add-on wireless driver such as AirportBrcmFixup, possibly. Then rates really depend on your card and the network/channel you connect on (2.4GHz/5GHz). The IOReg you provided in your previous XPS9350 thread reveals wireless card with PCI id 14e4:43ba, i.e. a card based on Broadcom BCM43602 chipset such as a DW1830. That card is 802.11ac so capable of great speeds on a 5GHz network within the right surrounding conditions of course. Press [Opt] key whilst clicking on the Wireless icon of your Finder's bar and you'll see the connection settings for your network. You want to see DFS, 5GHz and 40MHz/80MHz values... If you don't check your boot parameters and experiment with them (see AirportBrcmFixup kext documentation). You may also check your wireless box/router settings and adjust of necessary.

No impact.

Just follow the usual process... make up your list of detailed hardware specs create a bog standard Clover config for a standard Haswell desktop computer with standard HD4600 iGPU fine-tune after basic installation Good luck. Want us to do all the hard work for you? Contribute to the running up and maintenance the forum: make a donation!

Some of you may remember Sinetek's initial work back at the beginning of 2017 on the development of a macOS driver for those PCIe Realtek RTS card readers fitted to many of our laptops. Whilst Sinetek's work never fully completed and only reached limited success, Cholonam recently resumed development work for the RTS525a card reader of his Dell XPS 9350. This resulted in great success in the sense that we now have a working driver for several RTS card readers, albeit with some limitations in respect of performance or supported hardware models. The driver is available off Cholonam's Github repo. Discussion on this new driver is available in continuation of Sinetek's original topic at insanelymac. We've also reported on development progress of this kext in this thread where we invite owners of Hackintosh laptops fitted with Realtek RTS card readers to feedback their own test results. Credits and thanks to Cholonam and Sinetek of course! View full article

New version v2.2 released today with bug fixes.

Check your hibernation status and, if required, disable it as per our FAQ topic on the matter.

IOGraphicsFamily patch that used to fix the Apple logo glitch at boot time is normally irrelevant and deprecated with Lilu + WEG.

All those you cache, yes.

@Tubardus, try again with boot args: bpr_handshake=0 bpr_presetdelay=250 On the other topic, yes you may load with your cached kexts (from /L/E) and inject kexts from /E/C/k/O if you set kexts injection to "Yes" in your Clover config.

Try again to cache the 3 x kexts I had uploaded a couple of days ago, but this time, add the following boot argument to your Clover config: bpr_handshake=0

It used to with the PS2 controller used on old D Series Hackintosh. You could try and compare the settings of the Info.plist files of the PlugIns of both set of kexts.

Your Clover config does indeed apply the expected and required patches to IOReg device located @00020000 (i.e. the IGPU). Open up your config file in Clover Configurator, go to Devices tab, click on Properties and select device PciRoot(0x0/Pci(0x2,0x0). In the right section, you'll see that HDMI connector-type 00080000 is applied to FB@1/port #5 and revised DP connector-type 00040000 is applied to FB@2/port #6. This is the expected config to activate and support HDMI output + DP output. So yes, HDMI will work if you plug an HDMI display into the laptop's HDMI port for instance. Same should be applicable for DP outputs out of an E/Dock. With regards to VRAM increase to 2GB, the patching guide also explains what to do on the matter and in that same properties section as above, you should notice a 1st line starting with a #. # character means that the line is commented out and that it actually corresponds to the VRAM increase patch. Uncomment the line by removing the # character and you'll obtain 2GB VRAM.

Please refer to the Haswell iGPU patching guide in R&D graphics section. It's illustrated with the E6440 I used to own.

Cholonam has now issued a version v2.1 which appears to work for some of our Realtek RTS52xx car readers. https://www.insanelymac.com/forum/topic/321080-sineteks-driver-for-realtek-rtsx-sdhc-card-readers/?do=findComment&comment=2718154 https://github.com/cholonam/Sinetek-rtsx/releases I've tested the driver successfully on my Latitude 7490 fitted with Realtek RTS525a microSD card reader. I experienced a read/write limitation to 5MB/s max. It was reported to Cholonam who is aware of this. Other than that, it works fine. It's probably the best we'll get for some time as Cholonam indicated he was unlikely to pursue work on his driver given that it works for the RTS525a card reader of his Dell XPS 9350. If that were the case, hopefully someone will be able to pick from there and resume work in the future. Please note that I've only tested this driver under Catalina since that's the only version I've got installed on my Latitude 7490. Would be grateful if people would feedback with their own tests under other macOS/OS X versions. Also note that if Clover is booted off the microSD card, laptop will need to be put through 1 x sleep/wake cycle to initialize access to the card.

Item #2 -> Please read our FAQ !

I've never really looked into this PCIe auto power setting matter so I'm afraid I don't know. It's not a boolean parameter if that's what you thought. I found that some cards on some laptops require this to be disabled (value 0). But, on my 7490 for instance, I didn't have to touch this with the 2 x DW1820a 0VW3T3 cards I initially bought. On the other hand, it was required with other DW1820a models... Anyway, that's off-topic.

@Tubardus, those cards are combo: they have a wireless chip (BCM4350) and a Bluetooth chip (BCM2045A0). The two are totally separate things.

Latest Broadcom patching kext set is build 2.5.2. Build 2.0.6 is old now. You should only be using Repo or Data. 1st one if you cache kexts, 2nd if you inject them through Clover. I very recently posted about my experimentation and findings re: Bluetooth of DW1820a and those patching kexts here.

No, because on p1, you posted the same BT module ids (0a5c:6412).

To clarify the matter: I added my own extracted and uncompressed firmware files, hence the .hex extensions I tested shorter name with both uncompressed .hex files and compressed .zhx files. BT worked in both cases I did not rename a compressed .zhx file to a .hex extension; I only renamed the firmware files to a shorter name and BT started to work. The kexts I uploaded in my previous post contain my added uncompressed firmware v5974. Make sure the BT module is actually fully enabled. Go to your BIOS settings and disable Bluetooth + Apply change enable Bluetooth + Apply change then, reboot into macOS. I don't think you need to redo all the tests I did, but it's up to you.

I've sanitised your last post and added specific details such as the facts that you're now running Catalina and that you switched from BrcmPatchRAM2 to BrcmPatchRAM3 on April 12th, probably after you came to realise things were not working with your 1st Catalina-incompatible firmware patching kext. This being said, I notice that your firmware does not appear to get updated by the patching kexts. I suspect you could be facing the same situation as I did on my DW1820a and that the name of the firmware file used for deployment on the Bluetooth module actually causes a fail in that respect. Maybe you ought to try the adjustment I detailed here to fix things, in a nutshell shorten the name of the firmware file.