Jump to content

Which macOS for Toshiba L875-S7108?


zydoslav
 Share

79 posts in this topic

Recommended Posts

45 minutes ago, zydoslav said:

not working, I am on alcid=13 now and still no success :D

 
Hmm strange...my model too ALC269 and alcid=6 works fine. Seems like 269 is most troublesome with too many layout-ids 😅:

 

Quote

Possible layout ids: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 32, 33, 34, 35, 40, 44, 45, 47, 55, 58, 66, 69, 76, 77, 88, 91, 93, 99, 100, 127, 128, 188

 

Edited by aben
Link to comment
Share on other sites

Guest 5T33Z0

@zydoslav Which EFI are you using now – Clover or OpenCore? IvyBridge needs SSDT-HPET and additional ACPI patches when OpenCore is used to get audio working. And I don't see those in @aben OpenCore EFI Folder.

 

In other words: you could test any Layout ID until your hairs turn grey without ever hearing sound.

Link to comment
Share on other sites

10 minutes ago, 5T33Z0 said:

@zydoslav Which EFI are you using now – Clover or OpenCore? IvyBridge needs SSDT-HPET and additional ACPI patches when OpenCore is used to get audio working. And I don't see those in @aben OpenCore EFI Folder.

 

In other words: you could test any Layout ID until your hairs turn grey without ever hearing sound.

I am using opencore EFI, thanks, I was just in the half :D How to get SSDT-HPET? I have downloaded SSDTTime but it wants DSDT.aml and I don't have it because I don't use DSDT

Edited by zydoslav
Link to comment
Share on other sites

Guest 5T33Z0

Well you already have the patches and the HPET in the EFI you uploaded early in the thread so you can use those. Check this screenshot. It should give you an idea what amount of work possibly lies ahead of you in regards to getting this thing working nicely. These are all the .aml files and ACPI patches required to get my Ivy Bridge Laptop.

 

20418324_Bildschirmfoto2022-04-16um16_51_17.png.040c6a33ff11fd899d857ee35f4680a4.png

Edited by 5T33Z0
Link to comment
Share on other sites

@zydoslav I actually do use a patched DSDT from SSDTTime tool but only has basic IRQ conflicts/HPET fix patch, nothing else. I believe you had uploaded your system's DSDT dump, which you had retrieved from windows using SSDTTime tool, earlier in the thread. I have attached it below incase you need it.

@5T33Z0 Thanks for your input regarding the HPET requirement, I too believe this is the possible cause for audio missing however most of the other SSDTs and ACPI patches shown in your screenshot is not actually required for these Toshiba variants currently. Basic functions like sleep/wake, power button, lid detection etc. all work perfectly fine natively with no additional patches required, I can vouch for that having tested this machine extensively for the past decade. I believe your laptop requires those OEM defined ACPI specific patches.


Just for your reference below are the patches actually required for the Toshiba L8xx models from the 3rd-gen Intel lineup on current OpenCore release:

1051627485_ScreenShot2022-04-17at00_31_55.png.ec63127dfb561fc6e22dd02bf71eb199.png

DSDT.aml

 

P.S: I do not use OpenCore to boot into other OS(es) so no issues booting into macOS using a patched DSDT with HPET patch from SSDTTime. OpenCore manages the runtime brilliantly.

Edited by aben
  • Like 1
Link to comment
Share on other sites

@zydoslav Please upload your current OpenCore EFI folder. I'll try run some tests and see if any changes/additions required.
 

UPDATE: I did some test runs using my EFI folder without the patched DSDT, and yes can confirm, there will be missing audio (IOHDAcodec), native power management (x86PlatformPlugin) and, in my case, graphics accelerations too for the discrete mobile AMD GPU. Even the boot time taken into macOS is just abysmal - sometimes more than 2 minutes?! which is obviously abnormal boot times, when it usually supposed to take only about 15-20 seconds on SSDs. I believe the same behavior is seen on your end as well?

You will therefore require the final step of having your ACPI table patched a bit, which can be achieved with the help of SSDT(s) or a DSDT, in this case, I can only help assist you, If required. with a properly patched DSDT similar to mine (tested on Big Sur with no issues) which should also not be a problem since both our models are literally identical (even your DSDT table has the same device definitions as mine) with the only difference being the GPU device the BIOS is setup to attach to during boot initialization; PEG0 (dGPU) on mine, GFX0 (iGPU) on yours. 

Edited by aben
  • Like 1
Link to comment
Share on other sites

Guest 5T33Z0

@zydoslav There are 2 directions to go:

 

1. Like I said: put the SSDT-HPET.aml and ACPI patches EFI folder and config and select the correct ALC layout ID to get sound working. See attached files (recommended)

2. Use the DSDT from aben and disable the other SSDTs (not recommended since this DSDT is from a different model, the L850)

 

For your system to run well you still need to generate a SSDT-PM so CPU power management works correctly. You can generate that using ssdtPRgen: https://github.com/Piker-Alpha/ssdtPRGen.sh

 

@aben Of course audio will work when using a patched DSDT since the IRQs conflicts are patched-out. That's why he needs SSDT-HPET + ACPI Pathces when using OpenCore. It's not a possible cause for missing audio, it's the definite cause why audio is not working. It's a well know issue with Ivy Bridge CPUs

 

SSDT-HPET.aml patches_OC.plist

Edited by 5T33Z0
Link to comment
Share on other sites

@zydoslav Please test the below attached EFI. I have included the required DSDT with the necessary patches- HPET/IRQ and others. It's usually frowned upon in the hackintosh community to use a patched DSDT designed for another system since there can be lots of firmware related conflicts with various OEM defined ACPI tables differing massively from each other, even if both are from same x86 CPU generation,  I usually don't recommend this approach as well however in our case I absolutely see no difference whatsoever between your system's DSDT and mine since obviously our OEM (Toshiba) designed Ivy-Bridge models are from the exact same Satellite branded lineup with yours being 17inch -L87x and mine 15inch-L85x; our USB tables are identical reason why my SSDT-UIAC is fully compatible with yours, even your audio device and other peripherals being attached to the same ACPI root device paths too). I see no reason why this DSDT would cause any conflict for your system. I strongly believe this approach should work just fine for your model as well. With this EFI, you should most definitely notice much improved boot times (boot times with these models should be inside 20-25 seconds max. on SSDs) with audio working too.

I have obviously not included the power management SSDT containing the i5-3210M's power management data since it won't be practically compatible with your i3 counterpart so do utilize ssdtPRgen as advised by @5T33Z0 to generate the SSDT for your i3. SSDT-PM for i3-3120M now included with EFI folder. Incase, you are not satisfied with your i3's idle power states (as per Intel's specs: 100 MHz) when using SSDT generated from ssdtPRgen (most likely not) then I would propose you try Acidanthera's CPUFriend project to further fine tune your low-powered i3's efficiency performance which leads to longer battery usage. In my experience, this approach somehow works wonders for low powered CPUs like i3 which are designed to idle at way lower frequencies than their i5 and i7 counterparts.

@5T33Z0 Totally agreed on that. Audio does need HPET/IRQ patches on Ivy-Bridge. I had a look into his DSDT and I see zero difference with the whole structure; device definitions and the conditions that follow (it's literally a carbon copy) so I believe it shouldn't be a problem either ways. Two approaches have been presented: choice is up to him, whichever works best for his system.

UPDATE: @zydoslav I have updated the EFI folder to now include SSDT-PM with power management data from ssdtPRGen for your specific CPU model i3-3120M. You should now have native macOS power management as well from x86PlatformPlugin.

 

 

 

EFI.zip

Edited by aben
Updated EFI to include SSDT-PM for power management
  • Like 1
Link to comment
Share on other sites

@aben I have tested EFI which you have uploaded, but no success - it hangs just at the beginning of booting Big Sur, on apple logo with empty loading bar. :(

@5T33Z0 I have put SSDT-HPET.aml to my EFI folder and updated config.plist with this file and patches with OpenCore Configurator. Big Sur boots OK, so as I understand now I can search for proper layout-id? For the power management, I will check the link you have pasted in your reply. Thank you.

Link to comment
Share on other sites

Guest 5T33Z0

@aben Ivy Bridge and older don't support the X86PlatformPlugin in macOS by default. And it says so the debug section of the SSDT-PM:

 

            Debug = "machdep.xcpm.mode.....: 0" 0 means that it is using the legacy ACPI_SMC_PlatformPlugin instead, which is good in this case.

 

More info here: https://github.com/5T33Z0/OC-Little-Translated/tree/main/01_Adding_missing_Devices_and_enabling_Features/Xtra_Enabling_XCPM_on_Ivy_Bridge_CPUs

 

Link to comment
Share on other sites

Added SSDT-PM to my EFI, generated via ssdtprgen, laptop boots and everything looks ok. Boot time for me is 42 seconds.  I think this is mainly because of an error which is showing during boot - ACPI error, method execution/parse failed.... .... ....AE_NOT_ FOUND psparse-632, something like that. It repeats for about 10-15 seconds so it's making the booting process longer. But this does not affect it at all.

And finally - AUDIO WORKS! For me it's working for layout-id  = 6, just like @aben previously suggested. That's great!

@5T33Z0 is there something else I should check/add to my config.plist to make things better? Uploading mu current EFI.

EFI.zip

Edited by zydoslav
Link to comment
Share on other sites

Guest 5T33Z0

@zydoslav Congrats

  • Use OpenCore Auxiliary Tools to update kext and OpenCore files
  • Correct the remaining errors (OCAT will point at them)
  • Check if you really need SSDT-IMEI: adding this device is only necessary if you combine a 2nd Gen Intel Core CPU with a 3rd Gen mainboard or 3rd Gen CPU with a 2nd Gen mainboard! Disable it and see if the system still boots. Keep a Copy of the EFI Folder on a FAT32 formatted USB stick to boot from it if something goes wrong so you can boot from it
  • Optimize the Framebuuffer patch for your display panel: https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/ivy-bridge.html#configuration-notes
Link to comment
Share on other sites

10 hours ago, 5T33Z0 said:

@aben Ivy Bridge and older don't support the X86PlatformPlugin in macOS by default. And it says so the debug section of the SSDT-PM:

 

            Debug = "machdep.xcpm.mode.....: 0" 0 means that it is using the legacy ACPI_SMC_PlatformPlugin instead, which is good in this case.

 

More info here: https://github.com/5T33Z0/OC-Little-Translated/tree/main/01_Adding_missing_Devices_and_enabling_Features/Xtra_Enabling_XCPM_on_Ivy_Bridge_CPUs

 


@5T33Z0 I appreciate all your guidance and inputs on this thread but please try to read my comments more carefully before giving out irrelevant info just for the sake of it. I never implied anywhere that Ivy Bridge supports the X86PlatformPlugin by default except that it provides the better native power management for Ivy-Bridge CPUs, of course, when coupled with SSDT-PM generated from ssdtPRGen, based off my experience testing with the same hardware as OP. I don't see how your input here is any relevant to what I implied earlier.

Link to comment
Share on other sites

Guest 5T33Z0

@aben Uhhm, didn't you write this:

Quote

UPDATE: . You should now have native macOS power management as well from x86PlatformPlugin.

 

That's what I was referring to. And that's just simply wrong as I explained. And that what's relevant!

Link to comment
Share on other sites

2 hours ago, 5T33Z0 said:

@aben Uhhm, didn't you write this:

 

That's what I was referring to. And that's just simply wrong as I explained. And that what

Nope, read my sentences in full without omitting any preface again…I never mentioned anything about legacy power management here or x86PlatformPlugin being enabled by default; which you were apparently referring to unnecessarily either because: you consider yourself over-privileged to pass some info from your guide or you simply don’t appear to comprehend the context implied here in simple English; I literally just helped include the SSDT from ssdtPRgen and implied that native (by design, not legacy) power management for Ivy Bridge is now achieved by x86PlatformPugin now being enabled with the help of the SSDT; this is obviously understood by anyone who’s decently well-versed with hackintosh including you who also pointed out earlier in the thread that ssdtPRgen does help with better power management for Ivy Bridge. So nope, I’m sorry but you having to make a point and pass relevance about legacy power management and assuming x86PlatformPlugin is being enabled by default here is completely irrelevant and simply unnecessary.

 

After having witnessed these vague assumptions of yours and these random takes you have on certain topics on the forum, I guess Hervé was right all along: you love making extra noise just for the sake of it. All due respect to you for managing your so called “guides” but now I think that’s about it.

Edited by aben
Link to comment
Share on other sites

Guest 5T33Z0

@aben Please don't make me point out every occasion you said something technically wrong during the course of this thread where I had to step in to correct your mistakes and wrong suggestions (so much for being "well-versed")!. I don't have the time nor patience to do this!

 

Facst are:

  • Ivy Bridge CPUs use the legacy platform power management plugin, not X86PlatformPlugin, which your post implied.
  • Fact 2 is: it requires extra kernel patches  to enable it which where not present in your config. So suggesting "You should now have native macOS power management as well from x86PlatformPlugin is simply wrong.

And on this note, I end this conversation. The System is running. End of story. Learn from your mistakes – or don't – I don't care. Just don't point your fingers at me!

Link to comment
Share on other sites

@5T33Z0 Hmm, you just said you have no time or patience in doing this but you actually went ahead and composed your lame argument within the few minutes of me posting 😂. Please, we beg you, kindly refrain from exhibiting this annoying behavior of having to feel over-privileged to point out unnecessary technicalities nobody asked for. So stop pointing fingers at me unnecessarily as well if you simply can't comprehend contexts in which I meant to relay to the OP.
And no, the fact still remains that you don't need any extra kernel patches (like you vaguely implied, as usual, earlier in the thread, with the zillion patches that only applies for your laptop) to enable x86PlatfromPlugin on this model, which you have no access to or experience working with, so stop with the vague assumptions that all Ivy Bridge laptops require all the patches your laptop requires. You simply don't. Get over it, end of story, learn from your mistakes as well. And please stick to not wasting your time polluting the thread anymore. Thank you! 

Link to comment
Share on other sites

@zydoslav Kindly pardon my ignorance. Good to know your Toshiba is now booting Big Sur ok although I'm obviously a bit bummed that the patched DSDT didn't actually work for you haha which would have been perfect since you could have avoided those pesky ACPI parsing-errors and further improved your boot times like my system. (I too have the exact same ACPI parsing-errors as you mentioned when I do not use my patched DSDT) I guess its ok as long are you are happy with the current setup (thanks to @5T33Z0's notable inputs) although I wish I could have helped patched your DSDT better for a more close-to-perfect system. Anyways I do hope you enjoy macOS on your Toshiba.


Also, wanted to confirm with you one last thing - are you able to get working battery status on Big Sur? On my side, when using both SMCBatteryManager OR RehabMan's ACPIBatteryManager + ECEnabler or not, Big Sur weirdly doesn't show the battery status but it does show on all the previous macOS versions using the same config. Did you by any chance happen to notice this behavior when you installed Catalina?

Maybe our great @5T33Z0 will feel obliged to step in with his technical corrections and actually help find you a patch from one of his many bags of patches, hopefully.

Edited by aben
Link to comment
Share on other sites

1 hour ago, Slice said:

@aben

Did you hear something about third BatteryManager?

VoodooBatterySMC for online laptop power monitoring

Nice! Looks like a promising alternative for non-working battery situations 👌 Thank you for this Chief! 
 

@zydoslav Do consider this handy solution in case you’re never able to get battery status to show on Big Sur.
 

Also, like I mentioned way earlier in the thread, my Toshiba’s dGPU is unfortunately only supported native till High Sierra with everything working perfect. I do not believe in forcing legacy hardware to run on macOS not actually supported as per Apple’s specs so I actually consider this model end-of-life for macOS haha but for Windows this machine is still an absolute beast for its time, can easily handle many open-world titles like Far Cry 4, GTA V and ARMA 3 on high graphics with constant 60fps smoothly. 

Edited by aben
Link to comment
Share on other sites

On 4/18/2022 at 8:10 PM, 5T33Z0 said:

@zydoslav Congrats

  • Use OpenCore Auxiliary Tools to update kext and OpenCore files
  • Correct the remaining errors (OCAT will point at them)
  • Check if you really need SSDT-IMEI: adding this device is only necessary if you combine a 2nd Gen Intel Core CPU with a 3rd Gen mainboard or 3rd Gen CPU with a 2nd Gen mainboard! Disable it and see if the system still boots. Keep a Copy of the EFI Folder on a FAT32 formatted USB stick to boot from it if something goes wrong so you can boot from it
  • Optimize the Framebuuffer patch for your display panel: https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/ivy-bridge.html#configuration-notes

@5T33Z0 OCAT detected 3 problems with my config.plist but they were easy to solve, now there are no issues with my config.plist

As for SSDT-IMEI you were right - disabled and system still boots and works fine.

Framebuffer optimized according to the link you have pasted. Thank you very much for everything.

@aben On Catalina I haven't checked if the battery indicator works. On BigSur it does not work. I have also checked the resolution pasted by @Slice but unfortunately battery sensor Is not working - I have access to SSD temperature and SSD life, but battery info is empty. For me this is not a big problem, so I probably won't try to solve it. 

I see that this thread became really hot :) Thank you for all your replies, I have gained a huge amount of really usable information and new tools that I did not know.

I have one more question - you guys think it is safe to install update from 11.6.1 (using it now) to 11.6.5? I am asking because of previous experiences with failed updates (but most likely failed updates were caused by poor EFI completion). I just don't want to get this OS bricked, because for now I am really happy for how it works. :)

  • Like 1
Link to comment
Share on other sites

@zydoslav I just discovered that, when running macOS Big Sur on our models, battery status will not show if the battery module is removed or missing from the board - I have to keep the battery removed for my system because the battery has fully degraded and reached end of its lifespan to hold any further capacity, which now causes issues with system to randomly shutdown when fluctuations with power draw is detected with degraded battery present. However, absence of battery/AC status is not seen on previous macOS releases even if battery module is missing.

 

More importantly, it appears that using SMCBatteryManager.kext plug-in from VirtualSMC somehow does not allow our ACPI battery device (BAT0) to attach and thereby preventing macOS's AppleSmartBatteryManager to load on Big Sur. This is where our well-known and highly respected hackintosh legend RehabMan's many essential gems: ACPIBatteryManager.kext comes to the rescue. Tested and works perfect on Big Sur.

For your convenience, I have updated your current working OpenCore-EFI to include the latest release of RehabMan's kext, omitted unnecessary SSDT-IMEI (IMEI already present in our ACPI table) and also updated your EFI to latest OpenCore release 0.8.0. I believe, with this final addition, your checklist of basic features should now be complete :) 

And, yes! You may confidently update to macOS 11.6.5, not an issue at all.


Note: From personal experience, I would not recommend you utilize 3rd-party configurator tools like OCAT to update your OpenCore EFI and config files, other users on the forum can vouch for this as well. This approach is not really supported by the developers of OpenCore currently and the tool has seen issues like: OpenCore's ocvalidate tool not being updated in a timely manner causing incorrect validation issues with .plist file and user being forced to go through cumbersome steps of manually downloading and updating ocvalidate tool (defies the purpose of OCAT being convenient) AND more recently the concerning issue of config.plist file having its file-size multiplied each time you load/open it through OCAT which is not a good sign at all. Some users will try point out that usage of OCAT is still present in OpenCore DOCS however this section of the DOCS has not been revised by the developers in a long time simply because it's irrelevant. It's just safe and recommended to follow the updated instructions as advised and published by the OpenCore developers here, especially section 4: https://dortania.github.io/OpenCore-Post-Install/universal/update.html#updating-opencore

 

EFI.zip

Edited by aben
  • Like 1
Link to comment
Share on other sites

@zydoslav I think I finally found the reason why the earlier patched DSDT I shared with you was causing a hang at boot. It looks like I overlooked just one important thing: your SATA device is actually defined as SAT0 and not SATA like mine, which was causing conflicts, sorry about that! That's the only difference between your ACPI table and mine, everything else is literally a carbon copy.

I'm attaching the EFI with the corrected DSDT patch. Please test and let me know if your system boots now. Also, you should no longer see any more errors with ACPI parsing which should now improve boot times as well :) 

 

EFI.zip

Edited by aben
  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...