Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

arsradu
arsradu
Posted
Posted

You Telling Me do manually and now you said thats not relate you and me have differante compilling' I am using ClovergrowerPro

And before the change thats working good for me

You know what I said that 3280 compiling good no issue

Édit

My l'ast Question is for Slice

 

Don't get me wrong, man. I'm just trying to help.

 

I'll let Slice reply to your post. I'm really curious to know what he has to say about this.

 

And sorry if I upset you in any way.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Result is the same when its work'

3280 compiling good and now you are commit some change and thats not working now

 

How do I Fix this this is my simple question

As I see you have a problem with BaseTools compiling after update EDK2?

I avoid follow EDK2 changes because they are not careful supporting OSX. I prefer to stay with last working EDK2 and with once compiled BaseTools.

My tools dated 05.09.2014 and they works fine as you see my compilations.

 

Next question, am I going to change something for new EDK2 and ElCapitan? Not now. It is huge work and I am alone now.

Fixed with r3282.

Wow! I am not alone!

  • Like 1
Link to comment
Share on other sites
Pene
Pene
Posted
Posted

Wow! I am not alone!

 

;) Unfortunately, time is something we have less and less... But I recently installed El Capitan, so I came to check what's going on.

 

 

Next question, am I going to change something for new EDK2 and ElCapitan? Not now. It is huge work and I am alone now.

 

Change what? I wasn't really following lately.

I compiled with latest EDK2 (with only two patches, MdePkg/Include/Base.h & BaseTools/Scripts/gcc4.9-ld-script) on El Capitan and didn't see any special problems.

 

P.S. I see with r3283 you added objc to --enable-languages= for gcc.

Not sure why objc is needed, but for objc support to compile also on Xcode 7.x we need the patch I added to r3285.

Or if objc is not needed, then the patch can be removed also.

  • Like 3
Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

SystemProductName needs to be replaced with the actual name of your motherboard/system (according to what Clover sees in DMI, you can see it in debug.log/bdmesg).

Working great Yosemite and El Capo  Thanks for this  B)

 

Edit

r3284

 

- Our FSI_SIMPLE_FILE_SYSTEM_PROTOCOL installed on handle: D0F36418

6:585  0:002  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\OEM\Z87X-UD5H\kexts\Other

6:586  0:001    Extra kext: EFI\CLOVER\OEM\Z87X-UD5H\kexts\Other\FakeSMC.kext

6:591  0:005  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\OEM\Z87X-UD5H\kexts\10.10

6:592  0:001    Extra kext: EFI\CLOVER\OEM\Z87X-UD5H\kexts\10.10\FakeSMC.kext

6:597  0:004  Removed efi-boot-device-data variable: Not Found

6:597  0:000  Custom boot screen not used because entry has unset use graphics

6:597  0:000  Closing log

 

logout

 

[Opération terminée]

Link to comment
Share on other sites
Pene
Pene
Posted
Posted

Welcome Pene ho are you?

I'm fine, thanks :) Yourself?

 

Working great Yosemite and El Capo  Thanks for this  B)

 

Edit

r3284

 

- Our FSI_SIMPLE_FILE_SYSTEM_PROTOCOL installed on handle: D0F36418[/size]

6:585  0:002  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\OEM\Z87X-UD5H\kexts\Other

6:586  0:001    Extra kext: EFI\CLOVER\OEM\Z87X-UD5H\kexts\Other\FakeSMC.kext

6:591  0:005  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\OEM\Z87X-UD5H\kexts\10.10

6:592  0:001    Extra kext: EFI\CLOVER\OEM\Z87X-UD5H\kexts\10.10\FakeSMC.kext

6:597  0:004  Removed efi-boot-device-data variable: Not Found

6:597  0:000  Custom boot screen not used because entry has unset use graphics

6:597  0:000  Closing log

 

logout

 

[Opération terminée]

Yes, I see r2381 changed "Other" dir to always load first, and then specific versions directories.

So basically "Other" is now more like "Common". Confusing name, if that's the intended behaviour.

  • Like 4
Link to comment
Share on other sites
TheRacerMaster
TheRacerMaster
Posted
Posted

I'm fine, thanks :) Yourself?

 

Yes, I see r2381 changed "Other" dir to always load first, and then specific versions directories.

So basically "Other" is now more like "Common". Confusing name, if that's the intended behaviour.

 

Yes, that was the intended behavior. I agree, it should probably be renamed or something.

Link to comment
Share on other sites
LockDown
LockDown
Posted
Posted (edited)

I am not using CGP. My way

#!/bin/bash

./ebuild.sh --ia32
./ebuild.sh -mc -D DISABLE_USB_SUPPORT
./ebuild.sh 
cd CloverPackage
./makepkg
./makeiso
cd ..
echo "done!"

 

How/where to insert these flags:

ENABLE_SECURE_BOOT='0'
ONLY_SATA0_PATCH='0'
USE_APPLE_HFSPLUS_DRIVER='1'
VBIOS_PATCH_IN_CLOVEREFI='0'
Edited by ellaosx
Link to comment
Share on other sites
LockDown
LockDown
Posted
Posted

IIRC you add them as arguments when running ebuild.sh. For example, ./ebuild.sh -D USE_APPLE_HFSPLUS_DRIVER would accomplish the same thing as enabling the Apple HFS driver option in CloverGrowerPro.

would i put everything in all ./ebuild.sh as:

#!/bin/bash

./ebuild.sh --ia32
./ebuild.sh -mc -D DISABLE_USB_SUPPORT -D USE_APPLE_HFSPLUS_DRIVER
./ebuild.sh -D USE_APPLE_HFSPLUS_DRIVER
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

would i put everything in all ./ebuild.sh as:

#!/bin/bash

./ebuild.sh --ia32
./ebuild.sh -mc -D DISABLE_USB_SUPPORT -D USE_APPLE_HFSPLUS_DRIVER
./ebuild.sh -D USE_APPLE_HFSPLUS_DRIVER

Correct.

 

 

Yes, I see r2381 changed "Other" dir to always load first, and then specific versions directories.

So basically "Other" is now more like "Common". Confusing name, if that's the intended behaviour.

 

We can introduce "Common" folder for this purpose and leave "Other" folder to have old behavior.

 

 

;) Unfortunately, time is something we have less and less... But I recently installed El Capitan, so I came to check what's going on.

 

 

 

Change what? I wasn't really following lately.

I compiled with latest EDK2 (with only two patches, MdePkg/Include/Base.h & BaseTools/Scripts/gcc4.9-ld-script) on El Capitan and didn't see any special problems.

I have a problem with compiling VariableDxe from new EDK2 so I just comment out this line from Clover.dsc.

It will be better to resolve the issue.

P.S. I see with r3283 you added objc to --enable-languages= for gcc.

Not sure why objc is needed, but for objc support to compile also on Xcode 7.x we need the patch I added to r3285.

Or if objc is not needed, then the patch can be removed also.

I am going to use this gcc49 for other purpose so why I added objc.

Can we use it to compile Clover.prefPane for example? To be not dependent on new Apple's Xcode inventions.

This is also questionable patch

 BaseTools/Scripts/gcc4.9-ld-script

  • Like 1
Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

@Slice, if you guys decide to use a Common folder for kexts, is there really any reason to keep the old format with individual folders for each OS X version anymore? I mean...if we get to OS X 10.50, will we have from 10.6 to 10.50 in Clover/kexts? Isn't that a bit too much? :))

So why don't we think this in advance and think about a solution on a long term? Like using a single folder (Common, as you said), for kexts.

 

From your experience, are there any incompatibilities between newer kexts and older OS? Cause, from my experience, I was able to use my 10.11 kexts with 10.10 with no problem.

Link to comment
Share on other sites
sebinouse
sebinouse
Posted
Posted 

10.6
...
10.11
Common
Other

This is the best solution for me.

Kext are often different from one version to another (I've been playing with hack since 10.5).

But it's like options in config.plist : it is there, you can use it if you wish. Maybe it is not necessary to create each folder during installation though.

  • Like 1
Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Kext are often different from one version to another (I've been playing with hack since 10.5).

But it's like options in config.plist : it is there, you can use it if you wish. Maybe it is not necessary to create each folder during installation though.

This is a good idea!

 

How about, on each installation, we check which OS versions are actually present on that machine and add needed folders according to that?

And if you remove one OS from one installation to another, then update the kexts folder accordingly, since those files will become residual files if there is no OS to use them anymore.

 

I mean...you would probably not have 20 OS X versions on a single PC. But you might have 2-3. Well, for this case, we can create only the folders needed for those versions.

 

And, something I don't understand, if Other and Common will have the same behavior,, just different names, then why keep them both? Older versions will have older behavior (and older folder structure), newer versions will use the newer one (which seems really similar to the old one to me, but anyway). But maybe I got this wrong... The only problem I see with this is downgrading to older Clover versions, which probably don't have this "upgrade kexts folder" feature. For that case, I assume that user will have them both, until he upgrades to a newer version again.

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Sorry for the noob question, but what is the "Other" folder? i know what "Common" is though

 

I'm pretty sure it's the same thing. It's just a matter of naming it in a less confusing way.

 

It's been used before to store kexts for access from multiple OS versions. It was a common place to store kexts when you're booting multiple versions of OS X. The problem was that, if you wanted to use it, you had to remove all the other folders in the /kext/ folder. Otherwise, Clover would look for the kexts to load under the corresponding folder (for example /10.11/ for El Capitan). If you didn't have any kexts in there, you couldn't boot, cause it wouldn't look in other places (such as the /Other/ folder).

 

Now it's looking into /Other/ first. Then into /10.11/. And you can keep all your folders in place.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Old behavior:

Check /kexts/OS_VERSION folder. If OS_VERSION is unknown that is often being with installer then choose /kexts/Other.

 

Very old behavior:

Check /kexts/Common folder. If not found then check OS_VERSION.

 

Until now Clover can inject kexts only from one folder. Either or.

 

Rev 3281 behavior:

Check Other and then check also OS_VERSION. Inject both.

 

Really all my kexts works in all systems from 10.6 up to 10.11 so this is not my problem. Common folder will be enough for me.

I also have working 10.5.8 but I need no kext injection from Clover folder. All my kexts are already in kernelcache. And in SLE.

  • Like 3
Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Old behavior:

Check /kexts/OS_VERSION folder. If OS_VERSION is unknown that is often being with installer then choose /kexts/Other.

 

Very old behavior:

Check /kexts/Common folder. If not found then check OS_VERSION.

 

Until now Clover can inject kexts only from one folder. Either or.

 

Rev 3281 behavior:

Check Other and then check also OS_VERSION. Inject both.

 

Really all my kexts works in all systems from 10.6 up to 10.11 so this is not my problem. Common folder will be enough for me.

I also have working 10.5.8 but I need no kext injection from Clover folder. All my kexts are already in kernelcache. And in SLE.

 

Now it's clearer. Thank you.

 

I'll let you decide if you think it would be a nice feature to create only the necessary folders upon Clover installation, and then update accordingly. Or...not. :) It's up to you.

 

And, Slice, in this community, you're never alone. :)

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

Old behavior:

Check /kexts/OS_VERSION folder. If OS_VERSION is unknown that is often being with installer then choose /kexts/Other.

 

Very old behavior:

Check /kexts/Common folder. If not found then check OS_VERSION.

 

Until now Clover can inject kexts only from one folder. Either or.

 

Rev 3281 behavior:

Check Other and then check also OS_VERSION. Inject both.

 

Really all my kexts works in all systems from 10.6 up to 10.11 so this is not my problem. Common folder will be enough for me.

I also have working 10.5.8 but I need no kext injection from Clover folder. All my kexts are already in kernelcache. And in SLE.

do you change in the Installer  the  both  default config.plist on OEM ?

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...