Hervé

What about card reader or Webcam (USB internal devices)? According to your previous IOReg extract, it looks like they're fully working too, right? Maybe you can post a new zipped IOReg output + a zipped SysInfo output.

Please note that the iGPU properties injection in this OC config are arguable. I guess they derived from the initial settings used for HiRes Capri FB 0x01660004 that only natively supports 1 x LVDS display output (for built-in LCD) and for which additional display outputs, taken from the LoRes layout, were injected. Given their origin, these properties don't really do any harm to FB 0x01660003 but they're not required at all. One noticeable item is the absence of property injection for the Capri FB memory size (to reduce it from 16MB to 8MB). Only 2 x properties should be used for patching the Capri LoRes framebuffer: 1 x for FB memory size and 1 x for HDMI audio. The properties injection should therefore look like: AAPL,ig-platform-id 03006601 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA A few other things look irrelevant, like the -lilubeta boot arg; but these things are probably inherited from a time where Big Sur was beta and not fully supported by our well-known add-on kexts. Things can however be cleaned up now.

More likely the card than the adapter... Anyway, you clearly have defective hardware, so nothing to do on the Hackintosh side so to speak.

You can seek inspiration in existing Latitude 7490/7400 guides and threads. But as usual, post your hardware specs (CPU, chipset, LAN, wireless, audio, USB, card reader, etc.); we actually recommend to add those in signature... Good luck!

For your Atheros AR8121/AR8113/AR8114 Fast or Gigabit Ethernet LAN card (1969:1026), try this kext: AttansicL1eEthernet.kext.zip

Leave /S/L/E alone and full vanilla as a general rule. If you want to cache kexts rather than inject them through Clover, use /L/E. Good that you got audio with VoodooHDA. It shows that you've got ALC888 audio codec so you could remove VoodooHDA to experiment with Lilu + AppleALC + various audio layouts (from the AppleALC wiki). Place this patched DSDT in the ACPI/patched folder of your Clover EFI and use this new config file (without nv_disable=1 ) Patched_DSDT_6930G.aml.zip config_nv#3.plist.zip

Sorry, my mistake... You'll have to add VoodooHDA before looking again in DPCIManager re: audio codec.

Remove VoodooTSCSync

DW1510 should work with this.

Try this new config (without boot arg nv_disable=1): config_nv#2.plist.zip Once you obtain graphics acceleration on that GeForce 9300M GS, you can expect the following GPU power states (GPU core/memory clocks in MHz): 169/100, 275/250, 500/400, 580/400 or something like that... This if you replace the FakeSMC of my initial pack with this revised version: FakeSMC.kext.zip Perfectly normal that you have no audio (among other things), it's not been looked into yet. Try to run DPCIManager old app, it may show the codec your Acer runs with. If not we'll just got for VoodooHDA later on.

Answer to #1 is a definite "No!", this is an old Broadcom card for an old and obsolete CD/C2D MacBook A1181 of some sort so you can forget about that card (A1185 is the actual battery for Mac model A1181 by the way!). If you've read our inventories + my previous answer, answer is obviously "Yes!" to the other 3...

You should consider replacing that card by a fully supported Broadcom model. These AR9462 (and other AR9485/AR9565) were only supported with a special re-written Atheros40 kext and support has always been sort of poor not to say inexistant since Catalina. Assuming your E7240 is fitted with a mini-PCIe slot, go for one of those DW1550, AW-CB123H or AW-CB160H. If you have a full size slot, you may even consider a real Apple card (eg: BCM94360CD) in an adapter.

If the card you're talking about is meant to be a real Apple card, then it obviously requires no additional kexts than what macOS natively provides... As such, remove any such kexts from /L/E and/or your EFI kexts subfolder as well as any mention to it in your OC config file. Reboot and make sure to Reset NVRAM. Now, it'd be greatly appreciated if you would provide some specific details about your trouble rather than "does not seem to work"... What's not working? wireless, Bluetooth, both? Do you see the wireless card (PCIe) + BT module (USB) in IOReg? An Apple card requires an adapter so that it can be fitted to a standard mini-PCIe slot or M.2 slot. What do you use in that respect and how is it fitted? Note that, a few years ago, fake Apple cards were sold from a large country in Asia. Therefore beware and check the wireless + BT pci ids of your device.

Ok, we'll probably have to look into injecting adequate properties for your nVidia dGPU afterwards. Once you've finished installing High Sierra, you may update all the way to Security Update 2020-006 (build 18G14042). Take an IOReg extract from IORegistryExplorer, zip it and post it here. Meantime, you may try this config. Place the unzipped file alongside your existing config and select it from Options->Config menu when you reach Clover's main boot screen. config_nv.plist.zip

You'll have to switch to OpenCore and follow the steps/guidance already available in the numerous Big Sur threads relating to Latitude 7480. Look these up.

If you use a USBPorts kext previously created with a different SMBIOS, yes, that's perfectly normal. Why? Because your mapping of USB ports no longer matches what you created. So you either: 1) revert to MBP11,x SMBIOS you previously used and add boot arg -no_compat_check or: 2) re-create your USBPorts kext with hackintool.

Obviously, Atheros40 kext is for Atheros cards and would therefore be of no use at all for a Broadcom card! Try this.

@tanya, you did not inject the properties I recommended. In addition, you've entered a totally invalid property "layout-id" which you should remove. Make sure you inject the following properties: AAPL,ig-platform-id 00001219 DATA framebuffer-patch-enable 01000000 DATA framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA framebuffer-pipecount 3 NUMBER framebuffer-portcount 4 NUMBER framebuffer-memorycount 3 NUMBER framebuffer-con1-enable 01000000 DATA framebuffer-con1-alldata 01050900000800008701000002040A00000400008701000003060A000004000087010000 DATA hda-gfx onboard-1 STRING and add the following boot arg to your NVRAM section, it's mandatory: agdpmod=pikera Of course, you may also experiment with the ig-platform-id value JakeLo gave in his post.

Copy the contents of the attached zip pack to your Clover EFI folder. It's very basic and, on the understanding that Acer Aspire 6930g is fitted with a Synaptics Touchpad, I've included the kexts than Dinesh developed and posted here. Aspire_6930G_10.13_Clover_Pack.zip We may need to revisit this if yours has an ALPS Touchpad because Acer's web site shows this as possible hardware too... One thing I'll ask you to do when you next boot your Clover USB installer is to press [F4] once you get to clover main menu. This will dump your BIOS tables to the ACPI/origin folder of the USB key. Zip that origin folder and post it so that we look at your DSDT and assess need for patching.

@Jorge1964, you need to understand that installing Big Sur requires something like 3 or 4 phases: you boot your USB installer, prepare your target disk/partition in Disk Utility (scheme + format) and complete 1st installation phase where all packages get copied to the target disk 1st reboot of the target partition (not the USB installer) where Big Sur packages will get properly installed on the target disk/partition 2nd reboot where the Big Sur installation completes 3rd reboot that gets you to the completed Big Sur installation and 1st boot system finalisation (setting of language/keyboard/user account/etc.) As JakeLo mentioned, it looks like you never went past phase #1...

Having the Clover EFI folder at the root level is not an issue; you may now check if Clover boots or not (you won't go very far but you'll see if USB key is now bootable). I'll prepare a basic pack that, hopefully, will allow you to proceed with installation, pending post-install tuning.

Did you or did you not install the OpenCore EFI folder to your target disk's EFI partition?

Did you try your Big Sur disk via F12 boot menu? That would normally be expected to add an entry in the UEFI boot list. Also check if you have Secure Boot set somwhere in your BIOS as you would probably need to have that disabled.

Same on my 7490, BIOS UEFI menu doesn't look anything like that. I never had to manually specify any UEFI path to boot, these were automatically added. @Jorge1964, you've got to make sure you place your OpenCore EFI folder in the SSD EFI partition. Of course, you have to mount it 1st and you can do that with various tools such as Clover Configurator, OpenCore Configurator, EFIMounter or manually through Terminal commands. See here for instance.

You need to: inject additional properties for the desired output ports (i don't think you need to inject device-id 1B19 by the way) change SMBIOS from Mac mini8,1 (a Coffee Lake model) to iMac 17,1 (a Skylake model). add boot arg agdpmod=pikera to bypass the native graphics output restrictions that apply to the selected (SMBIOS) Mac model Refer to the link I posted here. You'll then have everything.