Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

Slice
Slice
Posted
Posted

@Philip Petev

I can't debug the problem because I always have Xcode installed.

I also didn't use llvm-clang because Xcode one is good enough producing working codes due to work of Zenith432. Tested on Xcode4.4.1, 7.3.1, 8.3.3, 9.0.

If I will change something in  tools_def.txt it will happen only if it doesn't violate my working compilation.

Link to comment
Share on other sites
Philip Petev
Philip Petev
Posted
Posted

@Philip Petev

I can't debug the problem because I always have Xcode installed.

I also didn't use llvm-clang because Xcode one is good enough producing working codes due to work of Zenith432. Tested on Xcode4.4.1, 7.3.1, 8.3.3, 9.0.

If I will change something in  tools_def.txt it will happen only if it doesn't violate my working compilation.

There is no difference between the llvm-clang that comes with the Command line tools and the one, included in Xcode AFAIK.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Just guessing:

 

(1) You have "-v" NVRAM "boot-args".

(2) Switch off "-v" from GUI.

(3) Boot.efi will read your NVRAM "boot-args" with "-v" (still), but Clover already switching to graphic mode. So resulting in black screen.

No. AFAIK Clover destroys NVRAM "boot-args" before boot.efi starts.

There is no difference between the llvm-clang that comes with the Command line tools and the one, included in Xcode AFAIK.

llvm-clang assumed is custom compiled from llvm sources.

Xcode has "clang".

Link to comment
Share on other sites
Philip Petev
Philip Petev
Posted
Posted
llvm-clang assumed is custom compiled from llvm sources.

Xcode has "clang".

Well, according to this, the Command line Tools are basically Xcode without the GUI. Both the compiler tools (clang etc.) and the macOS SDK are included. Xcode is actually a frontend for those tools and I really doubt someone would take the time and effort to compile two different sets of such tools.

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

 

@Slice: how about using the XCLANG compiler profile? It's present in tools_def.txt as a profile for building edk2 for OS X/macOS. AFAIK, clang/llvm can be found in two places:

1. /usr/bin

2. /Library/Developer/CommandLineTools/usr/bin

The second path requires the Xcode command line tools to be installed with xcode-select --install, but think about it, that's more than enough for the ordinary user and no 7GB Xcode download would be needed. I wonder why nobody has seen that part of that file yet, except maybe Micky1979, that's his idea.

cvad as seen this since long time, Clover Builder.app tools do not need Xcodes

Edit***

Not sure ??

Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited) 
# clang and llvm can be anywhere, just set the env var

DEFINE LLVM_BIN = ENV(LLVM_PREFIX)/
DEFINE CLANG_BIN = ENV(CLANG_PREFIX)/

good, just tested with success! I have clang in /usr/bin/, also I have the command line tools and exporting those paths made working binaries.

Initially I receive a "bad nasm" message, so I just exported its path as well. Mine It's a tiny partition with os x installed and no place for Xcode, thanks!

cvad as seen this since long time, Clover Builder.app tools do not need Xcodes

Edit***

Not sure ??

Can't be without making on-the-fly changes to the source so I searched for that app and as expected  needs both xcode and an old version of gcc to be compiled, very different story. I think xcode is needed only to compile obj-c stuff, but the above is really better.

Edited by vector sigma
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

good, just tested with success! I have clang in /usr/bin/, also I have the command line tools and exporting those paths made working binaries.

Initially I receive a "bad nasm" message, so I just exported its path as well. Mine It's a tiny partition with os x installed and no place for Xcode, thanks!

Can't be without making on-the-fly changes to the source so I searched for that app and as expected  needs both xcode and an old version of gcc to be compiled, very different story. I think xcode is needed only to compile obj-c stuff, but the above is really better.

Be sure you have NASM 2.13.01 else codes will be broken.

For little changes in sources you just use ./ebuild.sh. Big scripts or apps needed for first time compilation.

No. AFAIK Clover destroys NVRAM "boot-args" before boot.efi starts.

 

Oops!

This line is commented out

//    DeleteNvramVariable(L"boot-args", &gEfiAppleBootGuid);

This is a big question.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

Question:

I use older 4222 and see  (using -v) that always uses an boot arg slide=0 is used. But all working.

That slide=0 is not in set as boot arg in config.plist. (And is not  listet in nvram after boot)

Where does this boot arg slide=0 come from? Does Clover add this for boottime and then delete it from nvram?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Question:

I use older 4222 and see  (using -v) that always uses an boot arg slide=0 is used. But all working.

That slide=0 is not in set as boot arg in config.plist. (And is not  listet in nvram after boot)

Where does this boot arg slide=0 come from? Does Clover add this for boottime and then delete it from nvram?

Clover calculates the obligatoriness of this arg and added it. But I am not sure as arg or also in NVRAM.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I just wondered, I thought it was obsolete  :angel:

Since Clover do it automatically.

 

@slice so now clover enables it also if it is not selected by user?

 

also this automatic mandatory injection is possible to override for some parts?

 

I mean automatic choice of a fakecpuid or some kernel patches in case of unsupported CPU?

some kernel patches yes.

fakecpuid no.

Link to comment
Share on other sites
alfaSZ
alfaSZ
Posted
Posted

Thank you for clarification

 

so my cpu needs of 0x40674 fakecpuid

clover detects it and choose right kernel patches after or if this fakecpuid is detected?

 

So it is behave in similar way if ie I have a i7 6950x or a E5 - 2696 v4 (xeon)

 

I am asking because with some clover version I had after login a reboot I ever have had not before with ie clover 4081 release or 4049...whit this I have had a set of kernel fix or only a kext fix like brumbaer 5960x patch which produce a near perfect system (in daily use no reboots @all)

It is difficult to debug because clover changes, system changes (from Sierra to high) and this behavior happens very rarely in my rig

so excluding some automatic patching or to have a old clover release working with High Sierra could help

I would second that - we need a way to disable automatic patching for Broadwell-E, because it is not perfect. If I had the time I would propose fixes for inclusion in the code but right now I can't so am being forced to stick to older versions or build my own suitably modified which is not ideal. It seems there are multiple users who have same need.

 

 

Sent from my iPhone using Tapatalk

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

I would second that - we need a way to disable automatic patching for Broadwell-E, because it is not perfect. If I had the time I would propose fixes for inclusion in the code but right now I can't so am being forced to stick to older versions or build my own suitably modified which is not ideal. It seems there are multiple users who have same need.

 

 

Sent from my iPhone using Tapatalk

		<key>KernelPm</key>
		<false/>

Will it help you?

 

@Sherlocks

Is the any Broadwell patch that can't be switched off from config?

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

 

<key>KernelPm</key>		<false/>
Will it help you?

 

@Sherlocks

Is the any Broadwell patch that can't be switched off from config?

Yes. I mentioned this problem before when auto patch start r4134 over build.

 

Now, we have no choice to disable autopatch. Also user can't debug system problem correctly.

Broadwell and other xcpm patch "not perfect". Consider various facts(bios setting, msr on each motherboard) for stable system. This is not cover all system. Users check each patch for their system. I mentioned this status long time ago to apianti and syscl. But not accept it.

 

At least, need oppertunity to use fakecpuid feature and kernel patch on pure kernel for unsupport cpu's user. But now clover doesnt have.

 

So now fabiosun,alfaSZ reported oppertunity that i mentioned above.

 

My opinion, at least, autopatch disable option.

 

Thanks

 

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

@Sherlocks Grazie! :-)

 

Could it be possible to use a your commits (I think 4081) with high Sierra?

For simple user as I am often it is difficult to explain problem to help coder in they efforts..but ie in this thread:

http://www.insanelymac.com/forum/topic/316516-macos-sierrahigh-sierra-on-broadwell-eep-not-a-guide-but-maybe-a-working-in-progress/page-1

with previous clover without auto patch functionality I can try all that solution..which were fully working for different people

with auto patch simple user do not know which patches are on or less..

The only problem was to find exact new kernel location if OSX kernel changed.

 

Thank you

i prefer to use manual patch for kernel. Now, sorry i can't. Already suggested it before. But not accepted autopatch disable option. I don't have permission above. Reason that i mentioned. Maybe Slice can.

 

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites
alfaSZ
alfaSZ
Posted
Posted

@Slice KernelPM->False is the old style patch for a single MSR that used to not work even under Haswell-E if I recall from memory. So unless the new Broadwell-E patches depend on this flag, which I believe they don't, I doubt it would be of any help. But maybe we can redefine its meaning, and make the new patches dependent on it too!

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

Maybe you missed an old post where apianti said to a my request to ask @sys and@Sherlocks if I find I repost it

in my case was perfect 4081 release with previous OSX but it seems to have problem with High Sierra.I will try again

thank you again

On 4081, you dont have any issue. Because r4081 dosnt have autopatch. Upto 4128, there is no autopatch.

 

나의 LG-F800S 의 Tapatalk에서 보냄

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