Jump to content

Clover General discussion


ErmaC
30,171 posts in this topic

Recommended Posts

25 minutes ago, MICKHAEL said:

@Jief_Machak is that right? Maybe that's why I'm unable to boot Big Sur beta 9? Using same dsdt/kext/EFI drivers that are booting Big Sur beta 2... Confused

He might test something.
Give him some time He might want to understand the new generation of CPU, it is.

Link to comment
Share on other sites

3 minutes ago, naiclub said:

Is this the latest file?
  I wonder if you make the file only for people who don't want to use modified DSDT?

Yes, 72f4ddd is.

Is it working or not ?

No, I don't do anything only for people who this or that. We're not OpenCore :hysterical:.

  • Haha 4
Link to comment
Share on other sites

20 minutes ago, Jief_Machak said:

Yes, 72f4ddd is.

Is it working or not ?

No, I don't do anything only for people who this or that. We're not OpenCore :hysterical:.

You ask if it works or not.
It can boot everything normally. But it doesn't load the modified DSDT file. It only loads that clover does.

If so Having to rely on clover to be full without expecting dsdt.

Edited by naiclub
  • Confused 1
Link to comment
Share on other sites

Anyone else unable to compile the latest commit?

 

Spoiler

----------------------------------------------------------------------

Ran 280 tests in 1.961s

 

OK

 

Running edk2 build for CloverX64 using the command:

build  -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED --conf=/Users/dan/src/CloverBootloader/Conf -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -p Clover.dsc  -a X64 -b RELEASE -t GCC53 -n 9

 

Build environment: Darwin-19.6.0-x86_64-i386-64bit

Build start time: 19:18:35, Oct.06 2020

 

WORKSPACE        = /Users/dan/src/CloverBootloader

EDK_TOOLS_PATH   = /Users/dan/src/CloverBootloader/BaseTools

CONF_PATH        = /Users/dan/src/CloverBootloader/Conf

 

 

 

Processing meta-data Architecture(s)  = X64

.Build target     = RELEASE

Toolchain        = GCC53

 

Active Platform          = /Users/dan/src/CloverBootloader/Clover.dsc

 

 

build.py...

/Users/dan/src/CloverBootloader/Clover.dsc(291): error 000E: File/directory not found in workspace

/Users/dan/src/CloverBootloader/OpenCorePkg/Library/OcGuardLib/OcGuardLib.inf

 

 

- Failed -

Build end time: 19:18:36, Oct.06 2020

Build total time: 00:00:01

 

dan@Dans-Mac-mini ~ %

 

 

Link to comment
Share on other sites

3 minutes ago, D-an-W said:

Anyone else unable to compile the latest commit?

 

  Hide contents

----------------------------------------------------------------------

Ran 280 tests in 1.961s

 

OK

 

Running edk2 build for CloverX64 using the command:

build  -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED --conf=/Users/dan/src/CloverBootloader/Conf -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -p Clover.dsc  -a X64 -b RELEASE -t GCC53 -n 9

 

Build environment: Darwin-19.6.0-x86_64-i386-64bit

Build start time: 19:18:35, Oct.06 2020

 

WORKSPACE        = /Users/dan/src/CloverBootloader

EDK_TOOLS_PATH   = /Users/dan/src/CloverBootloader/BaseTools

CONF_PATH        = /Users/dan/src/CloverBootloader/Conf

 

 

 

Processing meta-data Architecture(s)  = X64

.Build target     = RELEASE

Toolchain        = GCC53

 

Active Platform          = /Users/dan/src/CloverBootloader/Clover.dsc

 

 

build.py...

/Users/dan/src/CloverBootloader/Clover.dsc(291): error 000E: File/directory not found in workspace

/Users/dan/src/CloverBootloader/OpenCorePkg/Library/OcGuardLib/OcGuardLib.inf

 

 

- Failed -

Build end time: 19:18:36, Oct.06 2020

Build total time: 00:00:01

 

dan@Dans-Mac-mini ~ %

 

 

I tried without success.

Used to do it 3-4 years ago. So I stopped playing my Mac ever since. Just returned to play a few months ago.

Spoiler

1256619186_ScreenShot2563-10-07at01_59_56.png.65e731238122af26800bdb6b5109253c.png

 

Link to comment
Share on other sites

1 minute ago, Jief_Machak said:

Sorry, I don't understand what does that mean.

Well, I want to say that clover must be used to force it to work instead of the modified DSDT. For example, forcing the sound to work and the USB to work.
You're doing well, I just ask for advice.

Link to comment
Share on other sites

6 minutes ago, naiclub said:

Well, I want to say that clover must be used to force it to work instead of the modified DSDT. For example, forcing the sound to work and the USB to work.
You're doing well, I just ask for advice.

what you're saying, in my opinion it's an un logic thing, the Boot Loader Clover or OC don't have to provide for the custom settings of the hardware in which they are used. It is the user who must fine-tune his build with SSDT for USB mapping and SSDT for operation. DSTTs for those who know how to create and manipulate them, are a good thing, but from haswell onwards you can do without them.

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

2 hours ago, Jief_Machak said:

We're not OpenCor

If you stare too long at OpenCore, it will stare back at you

 

1 hour ago, iCanaro said:

DSTTs for those who know how to create and manipulate them, are a good thing, but from haswell onwards you can do without them.

No, they are not, a good SSDT solution is usually objectively superior.

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

5 minutes ago, Download-Fritz said:

No, they are not, a good SSDT solution is usually objectively superior.

I perfectly agree with you, and in fact I only use SSDT made in @gengik84

is that I don't want to open discussions or disputes with DSDT users

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

5 minutes ago, Download-Fritz said:

If you stare too long at OpenCore, it will stare back at you

I knew it : OpenCore is an abyss.

 

6 minutes ago, Download-Fritz said:

No, they are not, a good SSDT solution is usually objectively superior.

Do you realise that when you affirm or contradict without any explanation, you make yourself look as a lecturer ?

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

4 minutes ago, Download-Fritz said:

If you stare too long at OpenCore, it will stare back at you

 

No, they are not, a good SSDT solution is usually objectively superior.

All the things you said are right. Because SSDT is simple Not as complicated as DSDT, the ribarage is very busy for beginners
But it was a high-class option that they could

Link to comment
Share on other sites

14 minutes ago, 5T33Z0 said:

Anybody else having issues with updating and merging the config plist from 5122 to 5123?

 

Yesterday I tried 3 times to manually update my Notebook EFI from 5122 to 5123 which was a major p.i.t.a. and then the system still wouldn't boot. I am pretty much done with clover at this stage.

you have to use a plist editor and not rely on configurators
if you've never used a plist editor like Propertree or others, at first it all seems strange, but then taking it hand, it's much better.

  • Haha 1
Link to comment
Share on other sites

On 8/29/2020 at 8:12 AM, Slice said:

CmpDev called with empty name.

And this ATTENTION... set messages is finite. Ended by


46:477  0:000  ATTENTION : CmpDev called with a  with length() != 4 0
46:478  0:000   - [Rename my XDSM to _DSM]: pattern 5844534D, bin not found / already patched!
46:481  0:003   - [Rename GFX0 to IGPU]:

followed by screen message __String::char32At(size_t i) :i>= length(). 

 

Hi @Slice I hope you are well and safe. This bug seems to still exist in Clover r5122 unfortunately, preventing me to boot Catalina. Can you please have a look? Here are my parameters.

 

In my config.plist I replace a Method in a Device:

                <dict>
                    <key>Comment</key>
                    <string>Rename _STA to XSTA in H_EC</string>
                    <key>Disabled</key>
                    <false/>
                    <key>Find</key>
                    <data>
                    X1NUQQ==
                    </data>
                    <key>Replace</key>
                    <data>
                    WFNUQQ==
                    </data>
                    <key>TgtBridge</key>
                    <data>
                    SF9FQw==
                    </data>
                </dict>

...so I can inject SSDT-EC-USBX.aml and disable (via _STA) the original device H_EC and add a fake EC device needed for Catalina. But in my IORegistryExplorer I see this didn't work. Here is Clover log via Hackintool:

1:472  0:000   - [11]: (Rename _STA to XSTA in H_EC) lenToFind: 4, lenToReplace: 4, Target Bridge: H_ECtptalÉt0
1:472  0:000   - [12]: (Fix NUC BIOS RTC Device) lenToFind: 8, lenToReplace: 8, Target Bridge: 
1:472  0:000    patch disabled at config
...
5:438  0:000   - [Rename XHC_ to XHC1]: disabled
5:438  0:000   - [Rename _STA to XSTA in H_EC]:ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6

...as you said, in endless lines. I was under the impression this was fixed, can you please confirm and assist? Didn't realise since when it's broken i.e. when the code regression happened. Just found out when trying to get Catalina on my perfectly-run Mojave. UPDATE: Seems broken in r5122 as I was able to boot with some USB key with r5119 and it works fine!


Thank you!

Edited by MacKonsti
Link to comment
Share on other sites

32 minutes ago, MacKonsti said:

Here is Clover log via Hackintool:


1:472  0:000   - [11]: (Rename _STA to XSTA in H_EC) lenToFind: 4, lenToReplace: 4, Target Bridge: H_ECtptalÉt0
1:472  0:000   - [12]: (Fix NUC BIOS RTC Device) lenToFind: 8, lenToReplace: 8, Target Bridge: 
1:472  0:000    patch disabled at config
...
5:438  0:000   - [Rename XHC_ to XHC1]: disabled
5:438  0:000   - [Rename _STA to XSTA in H_EC]:ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6
5:438  0:000  ATTENTION : CmpDev called with a H_ECt���ptal�Ét�0 with length() != 4 6

...as you said, in endless lines. I was under the impression this was fixed, can you please confirm and assist? Didn't realise since when it's broken i.e. when the code regression happened. Just found out when trying to get Catalina on my perfectly-run Mojave.

I think I found the bug. Could you try this CloverX64-2020-10-04 00:06:31 +0300-Clover revision: 5123-jief-0710.1.zip. If it's working, I'll commit it.

If it doesn't work, send me your debug.log (please scratch it before to avoid having multiple boot in it).

Edited by Jief_Machak
  • Like 1
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

5 hours ago, Slice said:

Latest commit 72f4ddd9a6 works for me booting BigSur.

 

Agree.  Latest commits, including recent version r5123_8e0f4ad24 have fixed OEM folder/DSDT issue I posted before.  No problem booting to Big Sur Beta9 USB Installer, High Sierra 10.13.6, Catalina 10.15.7, Windows 10 etc :).

 

 

5 hours ago, D-an-W said:

Anyone else unable to compile the latest commit?

 

  Hide contents

----------------------------------------------------------------------

Ran 280 tests in 1.961s

 

OK

 

Running edk2 build for CloverX64 using the command:

build  -D DISABLE_USB_SUPPORT -D NO_GRUB_DRIVERS_EMBEDDED --conf=/Users/dan/src/CloverBootloader/Conf -D USE_BIOS_BLOCKIO -D USE_LOW_EBDA -p Clover.dsc  -a X64 -b RELEASE -t GCC53 -n 9

 

Build environment: Darwin-19.6.0-x86_64-i386-64bit

Build start time: 19:18:35, Oct.06 2020

 

WORKSPACE        = /Users/dan/src/CloverBootloader

EDK_TOOLS_PATH   = /Users/dan/src/CloverBootloader/BaseTools

CONF_PATH        = /Users/dan/src/CloverBootloader/Conf

 

 

 

Processing meta-data Architecture(s)  = X64

.Build target     = RELEASE

Toolchain        = GCC53

 

Active Platform          = /Users/dan/src/CloverBootloader/Clover.dsc

 

 

build.py...

/Users/dan/src/CloverBootloader/Clover.dsc(291): error 000E: File/directory not found in workspace

/Users/dan/src/CloverBootloader/OpenCorePkg/Library/OcGuardLib/OcGuardLib.inf

 

 

- Failed -

Build end time: 19:18:36, Oct.06 2020

Build total time: 00:00:01

 

dan@Dans-Mac-mini ~ %

 

 

First, delete ~/src/opt (from old SourceForge Clover) and any empty ~/src/CloverBootloader/OpenCorePkg folder.

Then clone the forked OpenCorePkg from the CloverHackyColor GIT Hub...

cd ~/src/CloverBootloader

git clone https://github.com/CloverHackyColor/OpenCorePkg.git

Now run ./buildme as before to compile Clover.

 

Edited by fusion71au
Need to delete any empty ~/src/CloverBootloader/OpenCorePkg folder first
  • Like 3
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

1 hour ago, fusion71au said:

 

You need to cd to your CloverBootloader folder, then clone the forked OpenCorePkg from the CloverHackyColor GIT Hub...


cd ~/src/CloverBootloader

git clone https://github.com/CloverHackyColor/OpenCorePkg.git

then run ./buildme as before to compile Clover.

Spoiler

1772012632_ScreenShot2563-10-07at06_11_32.png.8bd3a765a8b37f9f8ed4cf0c49115980.png

 

I did as you stated and that didn't work

It's been like this from 2015 until now.

I built it, why doesn't it show the model name?

Clover_r.pkg.zip

 

Edited by naiclub
Link to comment
Share on other sites

8 hours ago, Jief_Machak said:

@iCanaro Don't test AMD, we didn't do it yet.

Thanks for your effort and contribution of the new Clover which works perfectly in Intel hackintoshs. May we wait for your fix for AMD hackintoshs ASAP ?

Link to comment
Share on other sites

×
×
  • Create New...