Hervé

It would appear there is no bootloader installed on the media you attempt to boot (USB key or HDD). Start with that before installing/replacing the EFI folder.

You should enable integrated NIC, but that's not what causes the issue you experience. System reset on a Haswell platform is often due to absence of kernel power management (PM) patch. Make sure you enable KernelPm patch in your Clover config.plist (AsusAICPUPM patch is not required on Haswell and later platforms). If you used JakeLo's bootpack, you should be Ok, as long as you installed it in the right place of course: the hidden EFI partition that you'll 1st mount with Clover Configurator.

KP due to vanilla AICPUPM kext... If you use Clover, enable the AsusAICPUPM patch. If you use Enoch, you should either use NullCPUPM kext or the pre-patched AICPUPM kext. You may refer to my E6220 guide (and pack).

Please try and list your own computer's true specs, not those published on the Lenovo brochure.

Wifi with this card is discussed at great length on the forum. You can use the Search facility. Trackpad works fine with Dr Hurt's driver Release 4. You can look ut the thread in the associated R&D forum subsection. The files for the TrackPad PrefPane are also mentioned and provided.

Again, what des the KP say??? You will get audio if: 1) you use the correct patched DSDT (HDEF layout-id set to 12 / 0x0C) 2) you install the IDT 92HD93 definition dummy kext, ideally in /L/E (/S/L/E will do to) 3) replace the vanilla AppleHDA in /S/L/E by the patched version (details of patch provided before) or configure the on-the-fly patches in Clover config.plist Again, repair permissions and rebuild cache after any mod to kexts in /L/E or /S/L/E.

If your KP refers to AppleIntelCPUPowerManagement, then you need to install the patched AIPCUPM kext in /S/L/E (overwriting the vanilla kext), repair permsissions and rebuild the cache. If you get an "error 77..." message, retype the touch + kextcache commands.

Why don't you try to create your new USB installer directly on the E6230? It makes no difference that it already runs EC.

This patch applies to PCIe SD card readers only, not USB readers. It's known to work with several O2 Micro devices but may not work with all of them. It does not appear to work with non-O2 Micro devices (Ricoh or Realtek for instance). To patch your DSDT, use the following process: 1) Using IORegistryExplorer, identify your DSDT device (pay good attention to displayed PCI vendor and device ids). The device will differ from one system to another. 2) Open up your DSDT with MacIASL 3) look for your SD card device identified in step #1 (for instance: device PXSX under RP05) 4) paste the following code under the _ADR and _PWR sections: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package () { "AAPL,slot-name", // Optional Buffer (0x09) // Optional { // Optional "Built-in" // Optional }, // Optional "device_type", // Optional Buffer (0x11) // Optional { // Optional "Media Controller" // Optional }, // Optional "model", // Optional Buffer () // Optional { // Optional "<specify your model here>" // Optional }, // Optional "compatible", Buffer (0x0D) { "pci14e4,16bc" } }) } 5) Recompile your DSDT and replace your initial table. Below is an example for the Latitude E6230 (with original DSDT device "PXSX" renamed to "SDXC"):

Just apply the CellPhoneHelper patch, whether in the kext itself or in FakeSMC. No guide has ever mentioned anything else so don't get ahead of yourself and stick to known working patching methods that have been published so far.

Oh, you've been on Alexandervos's E6430?

If you have a proper installation, all subsequent upgrades are straight forward and trouble free. One only ever needs to re-apply the audio patches on non-Clover installation.

What "data" are you talking about? I've only ever applied patches to CellPhoneHelper. Stick to that to begin with.

You're getting warmer... So, now that you've identified that the card was based on a Sony Ericsson chip, you have to ask yourself why you picked a Sierra wireless profile for your WWAN patch? You did not confuse Sierra Wireless -a wireless communication equipment manufacturer- and macOS Sierra, did you? You may now refer to the other pointers of post #6.

1st of all, note that you obviously must not use the Legacy_sierra_qmi kext posted by Skvo under macOS Sierra because it's based on Yosemite's CellPhoneHelper kext. This kext is not compatible with Sierra and won't work under macOS 10.12. This extends naturally to any patch built on it. Secondly, you must not use Legacy_sierra_qmi kext AND patched CellPhoneHelper kext. You may use either/or but not both. Did you try the patch I detailed above? It was just a basic and rapid adaptation of Skvo's posted patch for macOS Sierra. I might have missed something in my code of course. Lastly, please note that, SIM inserted, if the reported WWAN module does not list software version and network name, it's simply not operating properly. 1st thing to do is get your module fully recognised. Skvo wasn't exactly thorough or generous with details in his thread so, not owning this particular WWAN module myself, I'm not in a position to undertake any tests and cannot be of much further help on this. I can only offer you to send me your module to try and get it working.

Well, I think you got it wrong somehow. I invite you to conduct some research about your hs2330 module so that you know what it's based on and then refer to the thread related to the HP hs2340. I'm pretty sure that, provided you collect the correct information, you should find certain similarities between the 2 modules. I'm sure you'll also find useful info and trends in the other WWAN guides I posted.

I guess your CellPhoneHelper patch is possibly incorrect. But we don't know what you did...

WWAN modules do not get listed as 3G cards but as modems or WWAN cards. Consult the existing threads on the matter if you want to get your card registered as a proper WWAN module and work out the necessary CellPhoneHelper patch (that you can inject into FakeSMC's Info.plist to avoid having to re-patch CellPhoneHelper kext after each OS update).

You have not generated your CPU-specific SSDT and, as such, have no native CPU SpeedStep. Yet, you have a copy of the SSDT generator script in the ACPI folder. Why don't you run it?

Does the guide say you need a different DSDT for different CPUs? No. Does it say you need a different SSDT for different CPUs? Yes. Of course, it does; this is directly linked to obtaining CPU SpeedStep... Guys, please follow the guides and don't look for complications where there are none. Thank you.

Sounds like you do not have CPU native SpeedStep in place and that sure will cause quicker battery drainage... On an IvyBridge platform such as yours, CPU SpeedStep is obtained through AICPUPM patch (patched kext or Clover on-the-fly AsusAICPUPM patch) and generated CPU-specific SSDT (using the well-known generator script of Pike R Alpha). You still have not uploaded your zipped EFI folder (you can leave out the Themes subfolder).

https://osxlatitude.com/index.php?/topic/8006-sierra-wireless-qmi-modules-mcem73xx8805-dell-dw557058085809/ You can rule out a USB port issue, your module is clearly listed in SysProfiler, i.e. detected and correctly reported in IOReg. So, it's more to do with CellPhoneHelper patch (if it's supported on this 4G module) or the QMI kext posted by Skvo. You have to base the patch on Sierra's vanilla kext, not an older version such as Yosemite's because Apple tends to modify these kexts from one OS X version to another (like they also like to do for Bluethooth kexts). For instance Skvo's patch made references to Yosemite's AppleUSBMergeNub kext as per CellPhoneHelper kext whereas, in Sierra, that kext does not exist and was replaced by AppleUSBHostMergeProperties. Try the following patch in Sierra which you can simply add to FakeSMC's Info.plist through any text editor: <key>0x413C Dell Wireless (based on Sierra QMI) modules</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleUSBHostMergeProperties</string> <key>IOClass</key> <string>AppleUSBHostMergeProperties</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>IOProviderMergeProperties</key> <dict> <key>DeviceModemOverrides</key> <dict> <key>AccessPointName</key> <string>Obtain From Service Provider</string> <key>ConnectionPersonality</key> <string>Sierra GSM Personality</string> <key>ConnectionScript</key> <string>WWAN.ccl</string> <key>DeviceContextID</key> <string>1</string> <key>DeviceModel</key> <string>GSM</string> <key>DeviceVendor</key> <string>Sierra Wireless</string> </dict> <key>DevicePPPOverrides</key> <dict> <key>LCPMTU</key> <integer>1450</integer> </dict> <key>InfoCommands</key> <dict> <key>ATCommands</key> <dict> <key>DirectoryNumber</key> <string>+cnum</string> <key>IMEI</key> <string>+cgsn</string> <key>IMSI</key> <string>+cimi</string> <key>Manufacturer</key> <string>+cgmi</string> <key>Model</key> <string>+cgmm</string> <key>ModemSW</key> <string>+cgmr</string> <key>Serial#</key> <string>+gsn</string> </dict> <key>HiddenProperties</key> <dict> <key>CommandPortBaseName</key> <string>wwan</string> <key>ControlPortBaseName</key> <string>wwan</string> <key>DataPortBaseName</key> <string>wwan</string> <key>StatusType</key> <string>CellPhoneGSM</string> </dict> </dict> <key>Initializing</key> <true/> <key>InterfaceMapping</key> <dict> <key>0</key> <string>wwanDM</string> <key>2</key> <string>wwanGPS</string> <key>3</key> <string>wwan</string> </dict> <key>WWAN</key> <true/> </dict> <key>bcdDevice</key> <integer>6</integer> <key>idProduct</key> <string>*</string> <key>idVendor</key> <integer>16700</integer> </dict> -

Or try this Enoch guide... It works.

Difficult to say really. Power management can't be 100% identical in OS X than Windows. In addition, OS X is more graphics hungry. For the rest, let's not try any guess until you post your EFI folder to have a look.

No idea, try and experiment by yourself. Please use a separate thread for your M6800 issue.