Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

I tested CloverX64 that Jief posted 3hours ago - probably kernel patches do not work(my hack must have two kernel patches for properly boot, if none or don't works in some reason - kernel panic on early stage running, POST code 04 and light led catastrofic_error on motherboard)

  • Sad 1
Link to comment
Share on other sites

1 hour ago, Slice said:

[CC] BootFixes3 Section 1 .text mCoffOffset=576(0x240) mCoffOffsetNew=576(0x240) diff=0(0x0) Section 5 .eh_frame mCoffOffset=37520(0x9290) mCoffOffsetNew=38336(0x95c0) diff=816(0x330) Section 3 .data mCoffOffset=38336(0x95c0) mCoffOffsetNew=37568(0x92c0) diff=-768(0xfffffd00) Section 1 .text mCoffOffset=576(0x240) mCoffOffsetNew=576(0x240) diff=0(0x0) Section 5 .eh_frame mCoffOffset=63984(0xf9f0) mCoffOffsetNew=65536(0x10000) diff=1552(0x610) Section 3 .data mCoffOffset=65536(0x10000) mCoffOffsetNew=64000(0xfa00) diff=-1536(0xfffffa00) [GENFW] XhciDxe

If I remember well, these are not error, but log when I modified mtoc for the new C++ section.

 

 

Some others had also lto failure (with seg fault). Which Gcc or Xcode are you using ?

1 hour ago, Slice said:

The better idea will be using OpenCore sources on C as an additional libraries for Clover.

This is basically what I'm doing now. OpenCore also use globals, so I fill the needed globals before calling loadimage/startimage.

Link to comment
Share on other sites

I have integrated FuzzyMatch, KernelCache and kernel Quirks in Clover.

in KernelAndKextPatches section, you can now add 

		<key>OcFuzzyMatch</key>
		<true/>
		<key>OcKernelCache</key>
		<string>Auto</string>
		<key>OcQuirks</key>
		<dict>
			<key>AppleCpuPmCfgLock</key>
			<false/>
			<key>AppleXcpmCfgLock</key>
			<false/>
			<key>AppleXcpmExtraMsrs</key>
			<false/>
			<key>AppleXcpmForceBoost</key>
			<false/>
			<key>CustomSMBIOSGuid</key>
			<false/>
			<key>DisableIoMapper</key>
			<true/>
			<key>DisableLinkeditJettison</key>
 			<true/>
			<key>DisableRtcChecksum</key>
			<false/>
			<key>DummyPowerManagement</key>
			<false/>
			<key>ExternalDiskIcons</key>
			<false/>
			<key>IncreasePciBarSize</key>
			<false/>
			<key>LapicKernelPanic</key>
			<false/>
			<key>PanicNoKextDump</key>
			<true/>
			<key>PowerTimeoutKernelPanic</key>
			<true/>
			<key>ThirdPartyDrives</key>
			<false/>
			<key>XhciPortLimit</key>
			<false/>
		</dict>

 

23 minutes ago, yapan4 said:

probably kernel patches do not work

Did I forget to tell that kernel patches doesn't work yet. Sorry if I forgot. I'll do them in few hours.

  • Like 1
Link to comment
Share on other sites

I've just checked compilation DEBUG/RELEASE GCC53/XCODE8 works. For all except RELEASE/GCC53, compilation finish with this error

GenPage...
/JiefLand/5.Devel/Clover/Clover-projects/Clover--CloverHackyColor--opencore_integration2/Build/Clover/RELEASE_XCODE8/FV/Efildr20Pure: ERROR 16386: Invalid parameter option

Efi still generated correctly.

 

gcc version 9.2.0

Xcode 11.2, Build version 11B52

Mojave

 

 

Link to comment
Share on other sites

I made success compilation DEBUG/XCODE8 and tested.

Bigsur installation (I have beta4) stops at

IMG_0280.jpeg

Because first install has no OSVersion

95:651  0:066  UniOSVersion == 
95:760  0:108  UniShortOSVersion == 

Then I go to Mojave as usual and stopped after lines

101:133  0:090  start image 'boot.efi'
101:241  0:108  Using load options 'boot.efi slide=0 darkwake=0 msgbuf=1048576 -v '
101:314  0:072  OSInfo:OSName called
101:556  0:241  OSInfo:OSVendor called

while 5122 booted fine.

Link to comment
Share on other sites

1 hour ago, vit9696 said:

Released Macs this year (e.g. iMac20,1) will be supported for at least 7 years from now. So we expect at least 5 more operating systems after 11.0 that will support Intel Macs. We are also interested in making older operating systems work on vintage computers and virtual machines (even on ARM Macs when they are released). So yes, we believe there is some good reason to support a clean thing.

 

The primary reason we started OpenCore was that Clover has many "automatic" actions, which behaviour is not documented anywhere. This caused many issues on various platforms from Macs and virtual machines to even hacks. There also were some design issues like no bless model (operating system discovery that works not like on Macs and often breaks), legacy kext injection, a lot of legacy in the configuration, and so on.

whereas I ask @Slice a question and he answers it, yet you and your opencore people ignore me, I asked 1 question 10 times for 2 months, not one response. I choose clover people over you        P.S. Broadwell-E section on Dortania is not accurate with numerous errors that don't comport with booting Catalina or older,with sanity check or discord talkers, and discord has un-nice people not answering basic opencore questions for anyone but their buds

 

Edited by jmacie
Link to comment
Share on other sites

@jmacie Except that you posted off-topic garbage, the issue has been looked at for other reasons before. I'd be shy of calling it such yet, but it looks to me like an obvious NULL deref, so very likely an Apple bug, unrelated to OC or Clover. I scrolled through your post history and found posts exclusively in unknown niche threads and here (where we are currently checking only due to the OC code integration ongoing), so maybe try to use proper communication channels rather than complaining?

  • Like 1
Link to comment
Share on other sites

1 hour ago, vit9696 said:

Released Macs this year (e.g. iMac20,1) will be supported for at least 7 years from now. So we expect at least 5 more operating systems after 11.0 that will support Intel Macs. We are also interested in making older operating systems work on vintage computers and virtual machines (even on ARM Macs when they are released). So yes, we believe there is some good reason to support a clean thing.

 

The primary reason we started OpenCore was that Clover has many "automatic" actions, which behaviour is not documented anywhere. This caused many issues on various platforms from Macs and virtual machines to even hacks. There also were some design issues like no bless model (operating system discovery that works not like on Macs and often breaks), legacy kext injection, a lot of legacy in the configuration, and so on.

Good to know it'll going on for a while, thanks.

 

All what you said about Clover is true. That's why it needed more developers than competitors :). Maybe you're right, a good rewrite is sometime good. But currently, I can't use OpenCore because (at least last time I tried) it doesn't see all my partitions.

 

That said, I still think none of the 2 has the better structure. I think a project should the GUI. This project would know nothing about patching injecting etc. This project will only select the boot partition and then call a booter, depending of the macOS version. That way, when we move to a new macOS version, the older version won't be touch and we'll avoid regression.
Because currently, we do a lot of initialisation, drivers loading, config reading before even know if it'll be needed (maybe windows will be booted). Going toward a structure more or less like this can make it easy for both project to collaborate. By having the possibility to have a boot selector as an efi module for OpenCore, it's a bit like what I say.

  • Like 3
Link to comment
Share on other sites

9 minutes ago, Jief_Machak said:

That's why it needed more developers than competitors

Sorry, but if you check history right before OC, we both directly and indirectly contributed to Clover (AMF, AIF, FileVault 2, kext injection fixes, and so on). After we spent almost a week RE'ing entirely unrelated code for FV2 because we did not realise Clover silently stripped leading backslashes in paths until I compared its calls with Ozmosis', it was kind of clear something with no undocumented hacks was needed. Also it was easier to start from scratch than refactoring literally every component of Clover individually. Let's just say that was not a popular choice at the time. :)

 

13 minutes ago, Jief_Machak said:

I think a project should the GUI. This project would know nothing about patching injecting etc. This project will only select the boot partition and then call a booter, depending of the macOS version. That way, when we move to a new macOS version, the older version won't be touch and we'll avoid regression.

Sorry, I have no idea what you are saying here. Are you saying there needs to be a way to have a boot configuration per OS? Because that makes no sense. Do you mean it should choose between Clover and OC based on macOS version? Please no, absolutely not. If you are saying GUI needs to be separate from booting logic, that is exactly what OC implements. We do already support external GUIs, please refer to NDK.

 

17 minutes ago, Jief_Machak said:

I can't use OpenCore because (at least last time I tried) it doesn't see all my partitions.

If you do not have a weird laptop with APFS issues, this sounds very much like a configuration error (ConnectDrivers off, ScanPolicy inadequate, UnblockFsConnect quirk required, and so on).

Link to comment
Share on other sites

6 hours ago, vit9696 said:

Released Macs this year (e.g. iMac20,1) will be supported for at least 7 years from now. So we expect at least 5 more operating systems after 11.0 that will support Intel Macs.

 

The primary reason we started OpenCore was that Clover has many "automatic" actions, which behaviour is not documented anywhere. 

 

First - I'm a huge acidanthera fan and admirer of your work.  As far as I'm concerned, you all walk on water and produce some amazing stuff.

 

That said...

 

While I hope your crystal ball is accurate, I'm skeptical about the 7 years.  Don't quote me on the exact years, but I believe Apple announced Intel at 2005 WWDC, sold the first Intel-based systems in 2006 and released its first Intel-only OS (Snow Leopard) in 2009.

 

If there are a lot of "automatic" actions, is Clover hiding a lot of "ACPI sins" that would be left exposed with OpenCore?  I'm not an OC user, but based on what I've read, Clover is just easier to use.

 

Competition is healthy.  Long live CLOVER and OC.

 

 

 

 

  • Like 2
Link to comment
Share on other sites

4 hours ago, tonyx86 said:

 

First - I'm a huge acidanthera fan and admirer of your work.  As far as I'm concerned, you all walk on water and produce some amazing stuff.

 

That said...

 

While I hope your crystal ball is accurate, I'm skeptical about the 7 years.  Don't quote me on the exact years, but I believe Apple announced Intel at 2005 WWDC, sold the first Intel-based systems in 2006 and released its first Intel-only OS (Snow Leopard) in 2009.

 

If there are a lot of "automatic" actions, is Clover hiding a lot of "ACPI sins" that would be left exposed with OpenCore?  I'm not an OC user, but based on what I've read, Clover is just easier to use.

 

Competition is healthy.  Long live CLOVER and OC.

 

 

 

 

 

I'm skeptical about the ARM Macs in general. They can use it on low end MacBooks but I just don't understand how they can use ARM on iMac and Mac Pro for example and compete with performance. Well they can but who would buy those :) Also I think they are shooting themself on the leg with this because there is no way they can keep up with AMD and Intel in the end. I'm pretty sure there has been some executive "why can't we use our own processors on all products? Just do it!" attitude in Apple. I don't know it just does not seem to make sense for Mac Pro, maybe they just dropped Intel and are going to use ARM and AMD.

 

Anyway I have owned many Macs just bought two 16" MacBook Pro's in summer. We do have Intel support for couple of years at least and this laptop is junk then anyway, but I have been thinking. I'm tired of Apple's decisions and backwards compatibility of old games etc and I won't buy Mac 's after another processor switch. On Windows I can play games I bought in 1992. I think that I'll say bye bye to MacOs completely then.

 

Anyway I don't think Slice can be convinced to jump to OC and vice versa. But I do agree there is no sense in developing and maintaining two bootloaders. You all should start a new open source bootloader that's designed together and then taking the best bits from Clover and OC.

 

If it's then going in the right direction and everyone is happy then drop both OC and Clover.

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

10 hours ago, Jief_Machak said:

Does that means this config.plist must works with Big Sur, do you think ?

 

How do you want me to know if my config.plist for Catalina is sufficient for Big Sur? I trust the developers to add the useful functions. 

Link to comment
Share on other sites

14 minutes ago, Jief_Machak said:

Exactly, we can't be sure. That's why I suggested to make an exact translation of your Big Sur OpenCore configuration into a Clover EFI (same drivers, same versions, same kext patch, same SSDT etc.).

That way we will be sure.

 

 

You are right. What do you need to do an exact translation of my OC Big Sur setup to Clover EFI. I am already using the same kexts for both bootloaders. The problem is that I have a DSDT for Clover and for OC I don't need DSDT, only some SSDT, and optional patch for RTC Bug.

Please tell me what you need. :)

Link to comment
Share on other sites

21 minutes ago, Matgen84 said:

Please tell me what you need. :)

I was hoping you could do it, as this thing already give a lot of work :whistle:

 

2 minutes ago, Matgen84 said:

I build latest commit 7e31ca13 (Opencore Integration branch): stuck at GUI/Options 

What's stuck ? Compilation or boot ? Any debug.log

Link to comment
Share on other sites

11 hours ago, Jief_Machak said:

I have integrated FuzzyMatch, KernelCache and kernel Quirks in Clover.

in KernelAndKextPatches section, you can now add 


		<key>OcFuzzyMatch</key>
		<true/>
		<key>OcKernelCache</key>
		<string>Auto</string>
		<key>OcQuirks</key>
		<dict>
			<key>AppleCpuPmCfgLock</key>
			<false/>
			<key>AppleXcpmCfgLock</key>
			<false/>
			<key>AppleXcpmExtraMsrs</key>
			<false/>
			<key>AppleXcpmForceBoost</key>
			<false/>
			<key>CustomSMBIOSGuid</key>
			<false/>
			<key>DisableIoMapper</key>
			<true/>
			<key>DisableLinkeditJettison</key>
 			<true/>
			<key>DisableRtcChecksum</key>
			<false/>
			<key>DummyPowerManagement</key>
			<false/>
			<key>ExternalDiskIcons</key>
			<false/>
			<key>IncreasePciBarSize</key>
			<false/>
			<key>LapicKernelPanic</key>
			<false/>
			<key>PanicNoKextDump</key>
			<true/>
			<key>PowerTimeoutKernelPanic</key>
			<true/>
			<key>ThirdPartyDrives</key>
			<false/>
			<key>XhciPortLimit</key>
			<false/>
		</dict>

 

Did I forget to tell that kernel patches doesn't work yet. Sorry if I forgot. I'll do them in few hours.

Hey, OcQuirks is already in config.plist in other place

https://github.com/CloverHackyColor/CloverBootloader/blob/master/CloverPackage/CloverV2/EFI/CLOVER/config-sample.plist#L1088

  • Like 2
Link to comment
Share on other sites

9 minutes ago, Jief_Machak said:

I was hoping you could do it, as this thing already give a lot of work :whistle:

 

What's stuck ? Compilation or boot ? Any debug.log

 


I don't think I have the knowledge to convert a working OC config to a Clover config. But I will still watch.

For the rest, i can build cloverx64.efi. If I rename it and replace the current BOOTx64: this is where it gets stuck on the user interface

Link to comment
Share on other sites

2 hours ago, Joni_78 said:

 

I'm skeptical about the ARM Macs in general. They can use it on low end MacBooks but I just don't understand how they can use ARM on iMac and Mac Pro for example and compete with performance. Well they can but who would buy those :) Also I think they are shooting themself on the leg with this because there is no way they can keep up with AMD and Intel in the end. I'm pretty sure there has been some executive "why can't we use our own processors on all products? Just do it!" attitude in Apple. I don't know it just does not seem to make sense for Mac Pro, maybe they just dropped Intel and are going to use ARM and AMD.

 

I'm also skeptical about the ARM Macs. Dropping Intel forces Apple to drop Final Cut Pro because it is impossible on ARM.

ARM processors more than 100 times slower than normal Intel or AMD processors. It is architectural design. Don't trust gigbench which measure "speed" in inches or something else.

  • Like 1
  • Haha 2
Link to comment
Share on other sites

×
×
  • Create New...