Jump to content

Clover General discussion


ErmaC
27,814 posts in this topic

Recommended Posts

1 hour ago, 5T33Z0 said:

I though the whole point of adding HWTaget was to set it to j160 so that updates for macOS Monterey are offerered? Otherwise what's the point of having it, since Clover doesn't support secureboot.

Hello.
I'm sorry if I'm thinking wrong.
As per the following web page.

 

SecureBootModel in OpenCore 0.7.2

 

I think the original problem is in the Trusted Boot.
The reason why it is rushed and the reason why OpenCore set the default to auto is because it will be the norm for all future Macs to have T2 chips. I think it's safe to say that the final OS for Intel models will be a Trusted Boot based on hw.target, which is controlled by T2.

Thank you.

Link to comment
Share on other sites

Hello.
 
The shortest answer is: "Because we're hackers."
 
 
 The easiest way I have done it is to use the Clover Configruator. The values for FirmwareFeatures and FirmwareFeaturesMask are 32 bits, since 5140.1 is not yet supported. You can make them output as your Mac's name, and then do a logical OR with 0x800000000 to make them 64-bit. Simply put, you can add "8" to the hexadecimal number to make the ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMask values respectively.
 And hw.target is to be set as shown in the following web page, as there is a range of OS to boot.
SecureBootModel in OpenCore 0.7.2
Thank you.


So if I am reading right anything after iMac17,1 needs the new hw.target?
And also if I read correctly ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMast is the same as the non extended just with an 8 as the first bit?


Sent from my iPhone using Tapatalk
  • Like 1
Link to comment
Share on other sites

5 hours ago, Matgen84 said:

 

Thanks @MifJpnAlphaPlus for you method.

@Slice Is HWTarget key mandatory for non T2 chip config ! I use Imac19,1 (Corei7 9770K Z390 config):  T2 chip doesn't exist on Intel machines.

I think it is not-needed for non-T2 machines because x86legacy is default value if not set.

32 minutes ago, SavageAUS said:


And also if I read correctly ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMast is the same as the non extended just with an 8 as the first bit?
 

 

Exactly.

  • Thanks 2
Link to comment
Share on other sites

39 minutes ago, SavageAUS said:

 


So if I am reading right anything after iMac17,1 needs the new hw.target?
And also if I read correctly ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMast is the same as the non extended just with an 8 as the first bit?


Sent from my iPhone using Tapatalk

 

Hello.
I'm very sorry, but if anyone is ultimately responsible for many hacks, it is the hackers themselves.
We can't blame anyone for rushing the results or for not having sorted out the issues you mentioned.

First, let's sort out "with an 8 as the first bit". I'm sorry if this is a simple misspelling, but here it is

 

https://en.wikipedia.org/wiki/Binary_number

 

There is no 8 in a bit.
If I had to guess, I'd say it only sets the 35th bit to 1. So, since it doesn't fit in 32 bits, it has to be expressed in 64 bits with "Extended".

 

Next, hw.target. If you have an iMac17,1 and use Big Sur or later OS, you may not need hw.target itself. If you are using Big Sur or later, you may not need hw.target itself. (However, I can't be responsible for this since it's on an iMac 19,2.)

 

First, how not to specify hw.target.
#HWTarget string
The second is to follow the OpenCore Default.
HWTarget String X86LEGACYAP
In addition, and in addition, listen to @Slice.
HWTarget String x86legacyap

If there is something you don't understand, it would be helpful if you could describe how you don't understand it.

I hope you can make it work. I hope you do well, and in future stability.

English is not my first language, so I apologize if I worded it badly. I am sorry.

 

Thank you.

 

Now I will test "x86legacy",now @Slice is saing.(I think this is another way for hackers to cooperate.)

 

Thank you.

 

 

Link to comment
Share on other sites

1 hour ago, MifJpnAlphaPlus said:

Hello.
I'm sorry if I'm thinking wrong.
As per the following web page.

 

SecureBootModel in OpenCore 0.7.2

 

I think the original problem is in the Trusted Boot.
The reason why it is rushed and the reason why OpenCore set the default to auto is because it will be the norm for all future Macs to have T2 chips. I think it's safe to say that the final OS for Intel models will be a Trusted Boot based on hw.target, which is controlled by T2.

Thank you.

 

I was refering to this changelog:

Quote

Rev 5140 commit ec1f8a6a4ab1f0797d7a9e84d1c00b7517539583

Implemented hw.target

 

There is new setting in config.plist->RTVariables

	<key>RtVariables</key>
	<dict>
		<key>HWTarget</key>
		<string>j160</string>

It will be written into NVRAM as variable BridgeOSHardwareModel which will be asked by monterey and needed for software update.

it can be checked by command

% sysctl hw.target
hw.target: j160

 

Link to comment
Share on other sites

13 minutes ago, 5T33Z0 said:

 

I was refering to this changelog:

 

Thank you for your kindness.
I see what you mean.
Monterey Update and Fullinstall are now possible with ExtendedFirmwareFeature, right?
I don't know why, because @Slice told me so too.
I wonder why?
(Sorry if my wording looks bad. I can't translate well.)
Thank you.

 

1 hour ago, Slice said:

I think it is not-needed for non-T2 machines because x86legacy is default value if not set.

Exactly.

Okay, I understand.

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: x86legacy


I have no problems booting Monterey and BigSur so far.
Thank you.

  • Like 1
Link to comment
Share on other sites

6 hours ago, Slice said:

I think it is not-needed for non-T2 machines because x86legacy is default value if not set.

I'm sorry.
I made a mistake.

The correct answer is NULL if there is no T2.
I was also wondering why OpenCore's Default setting is x86legacy when it should be set automatically.
 Originally, OpenCore's default setting should be NULL or Disabled because iMac19,2 does not have T2. So,Mojave could boot.
 I'm sorry @SavageAUS You are correct, our rig, which does not have T2, is
#HWTarget string

or
HWTarget string
I think that is the correct answer.
Will try now.

If String is null, the parser did not allow it.
If there is no T2, the correct answer was to not specify it.
In the same way, in OpenCore, Default is automatically selected, which is supposed to be the safe setting, but I think the safe setting is wrong, it should be Disabled.

Thank you very much.

Edited by MifJpnAlphaPlus
  • Like 2
Link to comment
Share on other sites

3 hours ago, 5T33Z0 said:

 

I was refering to this changelog:

 

 

3 hours ago, MifJpnAlphaPlus said:

Thank you for your kindness.
I see what you mean.
Monterey Update and Fullinstall are now possible with ExtendedFirmwareFeature, right?
I don't know why, because @Slice told me so too.
I wonder why?
(Sorry if my wording looks bad. I can't translate well.)
Thank you.

I've been thinking wrong. I'm sorry.
I think what you mean is that a product name Mac with T2 might have problems with updates and installation, let alone booting.
I think that's why we need to set hw.target.
(I made a mistake because of  SecureBootModel:Default which OpenCore says is a safe setting. Sorry about that.)

Thank you.

Edited by MifJpnAlphaPlus
Link to comment
Share on other sites

See

sergey@iMac2017 % sysctl hw.target
hw.target: j160
sergey@iMac2017 % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel	x86legacyap%00%00%00%00%00
sergey@iMac2017  % 

 

  • Like 2
Link to comment
Share on other sites

Hello.
If it helps, the result in OpenCore is as follows.
When SecureBootModel is set to j160.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: J160AP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel j160ap%00

 

When SecureBootModel is set to x86legacy.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: X86LEGACYAP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel    x86legacyap%00

 

When SecureBootModel is set to Disabled.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target:
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel    x86legacyap%00%00%00%00%00

 

The law seems to be there.
Thanks again.

Translated with www.DeepL.com/Translator (free version)

Edited by MifJpnAlphaPlus
  • Thanks 2
Link to comment
Share on other sites

11 hours ago, MifJpnAlphaPlus said:

Hello.
If it helps, the result in OpenCore is as follows.
When SecureBootModel is set to j160.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: J160AP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel j160ap%00

 

When SecureBootModel is set to x86legacy.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: X86LEGACYAP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel    x86legacyap%00

 

When SecureBootModel is set to Disabled.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target:
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:

11 hours ago, MifJpnAlphaPlus said:

Hello.
If it helps, the result in OpenCore is as follows.
When SecureBootModel is set to j160.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: J160AP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel j160ap%00

 

When SecureBootModel is set to x86legacy.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target: X86LEGACYAP
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel    x86legacyap%00

 

When SecureBootModel is set to Disabled.

 

alpha@pc2-monterey-iMac ~ % sysctl hw.target
hw.target:
alpha@pc2-monterey-iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel
94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel    x86legacyap%00%00%00%00%00

 

The law seems to be there.
Thanks again.

Translated with www.DeepL.com/Translator (free version)

    x86legacyap%00%00%00%00%00

 

The law seems to be there.
Thanks again.

Translated with www.DeepL.com/Translator (free version)

Hello. @Slice

 I have Mojave and Catalina HDD images on my file server (22TB). And I think I can write back to the SSD now and boot.

 It should not boot with x86legacy or Default settings out of the OpenCore methods. (Originally, it should boot because it is an iMac19,2, but this is a mistake in the interpretation of OpenCore's Autogenereted.c.)
 If the hw.target and HardwareModel settings are all there is, please make a configurable commit for it so I can test it. What do you think in this case?

 Furthermore, I can do a full backup of the Monterey b9 now, so it will take some time, but I can try the following.

x86legacy (or Default)-BigSur Monterey can boot.
j137 - iMacPro1,1 (December 2017) Minimum macOS 10.13.2
However, Monterey should not start.
In the following cases, I can confirm that Catalina,Mojave will boot.
j680 - MacBookPro15,1 (July 2018) Minimum macOS 10.13.6
j132 - MacBookPro15,2 (July 2018) Minimum macOS 10.13.6
j174 - Macmini8,1 (October 2018) Minimum macOS 10.14
j140k - MacBookAir8,1 (October 2018) Minimum macOS 10.14.1
j780 - MacBookPro15,3 (May 2019) Minimum macOS 10.14.5
j213 - MacBookPro15,4 (July 2019) Minimum macOS 10.14.5
j140a - MacBookAir8,2 (July 2019) Minimum macOS 10.14.5

 However, it may lock up, so it will take a lot of write back time.

Therefore, I can choose any of them to test. If you need, please specify a few.

 

Thanks very much for your developing.😀

 

I'll start by doing a full backup of my current Monterey (dd-mode) and try j137 using Clover. (And then I'll try them one by one)

Edited by MifJpnAlphaPlus
  • Thanks 3
Link to comment
Share on other sites

On 10/11/2021 at 2:54 AM, Slice said:

But yes, other values also depends on ProductName. So if it is not defined then SMBIOS values will be unreal mixed.

That's why I consider that ProductName MUST be defined otherwise the whole SMBIOS is not valid.

If ProductName is defined, it's easy for dget...() to return a default value.

 

And, if ProductName is NOT defined but we keep other values, they'll get mixed as well. Plus : we have to handle that outside the "setting layer".

 

In short, I'll strongly advise, because it makes a lot of things easier to understand and to program, to agree with this new rule.

 

On 10/11/2021 at 2:54 AM, Slice said:

Anyway it is accessible like we think out some unreal serial numbers and can replace one model to another don't touchings others values.

Not sure what you mean here.

 

To conclude, we have to decide first : is it ok to users to define ProductName if they want to define other values (it is still ok to start without ProductName and then get from the log (or we can display it in the about menu) ?

What do you all think.

  • Like 2
Link to comment
Share on other sites

Hello. 
 I'm sorry, but I don't think I've fully grasped the overall meaning.
 I'm sorry, but no one seems to be writing about it, so I'll just write what I think.


 I think everyone agrees that ProductName is the most important item and should be set.
 I also understand that OpenCore complements the various SMBIOS values.
 However, I myself would prefer to be able to decide the detailed definition of SMBIOS by myself.

 

 The original use of SMBIOS is for Apple's quality control.

 

 I don't really want to discuss it here, because I don't know how the technical terms will be translated into other people's native languages. But I think it's important, so I'll try to make as few mistakes as possible. I apologize if there are any problems. I'm sorry.

 

 The problem here is that it is up to Apple to decide how to use SMBIOS in the first place. At the moment, they are being generous to a certain extent, because they are fighting against hacking. But if they don't allow it, I think the fully automatic setup of SMBIOS means that our freedom (maybe even illegitimate freedom) will become less and less.

 

 I think the best way to create maximum freedom is to keep SMBIOS as detailed as it has always been on a ProductName basis, and for T2 measures, to keep it to detailed OS values.

 

 As for me, my concern is simply the following.
 I just think that OpenCore's decision to use SecureBootModel = Default is strange: if there is no T2, it should be set to x86legacy only if you are using BigSur in a VM.
 You say that the Default setting is automatic. However, in reality, the Default decision is x86legacy and it does not set it to Disabled.
 This means that OpenCore automatically recommends the use of BigSur or higher.

 On the contrary, it is a mistake that OpenCore has fallen into because it has automated SMBIOS in a sweet way.

 

 I like the hacker-like freedom of the hackintosh.

 In terms of copyleft, the FSF has been quite successful. But at the moment, with the flood of languages and libraries/containers, even if you provide the source (on the net) so that people can look at it, every new language that comes out every year is just a tool to make something more efficient. (And I think that repeated over-abstraction and derivation makes it harder to see what's going on.
 Even though everything can be researched and hacked (not cracked) with open and copyleft, there are beginners and gurus alike.
 I think it's inevitable that it's historically difficult to say that it's up to the researcher to look at the source as the FSF says.


This is just my own opinion, so please forgive my silly idea with no ability.

Thanks for reading.

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

On 10/12/2021 at 1:45 PM, MifJpnAlphaPlus said:

Hello. @Slice

 I have Mojave and Catalina HDD images on my file server (22TB). And I think I can write back to the SSD now and boot.

 It should not boot with x86legacy or Default settings out of the OpenCore methods. (Originally, it should boot because it is an iMac19,2, but this is a mistake in the interpretation of OpenCore's Autogenereted.c.)
 If the hw.target and HardwareModel settings are all there is, please make a configurable commit for it so I can test it. What do you think in this case?

 Furthermore, I can do a full backup of the Monterey b9 now, so it will take some time, but I can try the following.

x86legacy (or Default)-BigSur Monterey can boot.
j137 - iMacPro1,1 (December 2017) Minimum macOS 10.13.2
However, Monterey should not start.
In the following cases, I can confirm that Catalina,Mojave will boot.
j680 - MacBookPro15,1 (July 2018) Minimum macOS 10.13.6
j132 - MacBookPro15,2 (July 2018) Minimum macOS 10.13.6
j174 - Macmini8,1 (October 2018) Minimum macOS 10.14
j140k - MacBookAir8,1 (October 2018) Minimum macOS 10.14.1
j780 - MacBookPro15,3 (May 2019) Minimum macOS 10.14.5
j213 - MacBookPro15,4 (July 2019) Minimum macOS 10.14.5
j140a - MacBookAir8,2 (July 2019) Minimum macOS 10.14.5

 However, it may lock up, so it will take a lot of write back time.

Therefore, I can choose any of them to test. If you need, please specify a few.

 

Thanks very much for your developing.😀

 

I'll start by doing a full backup of my current Monterey (dd-mode) and try j137 using Clover. (And then I'll try them one by one)

Hello.
I'm not sure if this will help you.
I'm not sure if it's useful or not, but I've tried as much as I could.
 My ProdutName is iMac19,2. So, after Cataliana, it was actually working.
 So, I was able to reproduce that BigSur works and Catalina doesn't work by starting x86legacy and Default SecureBootModel.
 On OC074, if the UEFI->ACPI setting is older than BigSur, it will cause an internal critical error and the bootloader itself will stop.
 So, I went back to OC072 and got a log that seems to reset after the T2 process (sorry if I'm wrong), so here it is.
(In addition, j134 alone booted Monterey, so ProdutName may be a precondition.

Thank you very much.

opencore-2021-10-13-144629-catalina-boot.txt.zip

opencore-2021-10-13-145727-catalia-reset.txt.zip

 

Link to comment
Share on other sites

I am going to attempt the beta 10 update when I get home with no changes to config.plist except for adding an 8 infront of my FirmwareFeatures and using that value for the ExtendedFirmwareFeature and it’s mask.
Will post results. Installs will be done on 2 hacks, 1 intel MacBookPro16,4 and 1 AMD iMacPro1,1.


Sent from my iPhone using Tapatalk

  • Like 2
Link to comment
Share on other sites

54 minutes ago, SavageAUS said:

@devs
Is there a way for clover to activate verbose -v mode during updates only? Without being saved to nvram?


Sent from my iPhone using Tapatalk

I had no such task before.I can do this with one extra setting like VerboseAtUpdate but more thinking I will not do this.

If you want verbose then you sit near the computer and then you may press Space on keyboard during Clover GUI time and choose Verbose. It will not interrupt normal process.

  • Like 2
Link to comment
Share on other sites

On 10/12/2021 at 11:55 AM, Jief_Machak said:

To conclude, we have to decide first : is it ok to users to define ProductName if they want to define other values (it is still ok to start without ProductName and then get from the log (or we can display it in the about menu) ?

What do you all think ?.

So, what should I do with this ?

Disable warning ? Keep the warning but not disabling other values ?

Other ?

Link to comment
Share on other sites

I've just seen the commit f014920e145c2c8abc145304ee345d1eb5058fd9 that breaks ccpv.

@everyone So please be aware that, until this is properly fixed, ccpv might gives you warnings that you should not have if you don't define ProductName.

 

@Slice Not sure to understand why you took the time to disable warnings instead of just defining ProductName. I don't think that hiding errors in config.plist is the way to go... And it doesn't feel nice when you cancel my code without talking to me first. I'm opened to reverse some code changes if we don't have the same point of view, but being done that way it feels like OC...

  • Like 3
Link to comment
Share on other sites

I think we should enable any mixture in SMBIOS section. It will work. So user may define ProductName or not. There is no criminal and I see no reason for warning.

Link to comment
Share on other sites

Hi guys,

 

I just tried to update to latest r5141.

 

However, CCPV diplayed this error upon reboot and MacOS didn't load (it was just stuck showing the Apple logo) so I reverted back to r5140 which boots fine.

 

Warning: Ignore memory module with slot >= SlotCount at '/SMBIOS/Memory:642'

 

Unfortunately I don't know how to fix this and I couldn't find anything in Clover-Crate.

 

As you can see my System Profiler says there a three RAM slots available with two slots populated while in reality there are only two slots available (it's an ITX system).

 

In case you're wondering why the ram sticks sit in slot "1" and "2":

if I set the first stick to slot "0" and the second stick to slot "1" which usually is the correct way as slot count starts at "0" I simply cannot boot – not with r5140 or a prior clover version.

 

Did something change with r5141 that enables this now?

 

To what value should I set these problematic values? "SlotCount" is currently set to "2" and this shoukd be fine, no?

 

This is the part of my config.plist starting at line 642:

 

<string>Apple Inc.</string>
        <key>Memory</key>
        <dict>
            <key>Channels</key>
            <integer>2</integer>
            <key>Modules</key>
            <array>
                <dict>
                    <key>Frequency</key>
                    <integer>3200</integer>
                    <key>Part</key>
                    <string>HX432C18FBK2/32</string>
                    <key>Serial</key>
                    <string>0000008145304-T000008</string>
                    <key>Size</key>
                    <integer>16384</integer>
                    <key>Slot</key>
                    <integer>1</integer>
                    <key>Type</key>
                    <string>DDR4</string>
                    <key>Vendor</key>
                    <string>Kingston</string>
                </dict>
                <dict>
                    <key>Frequency</key>
                    <integer>3200</integer>
                    <key>Part</key>
                    <string>HX432C18FBK2/32</string>
                    <key>Serial</key>
                    <string>0000008145304-T000009</string>
                    <key>Size</key>
                    <integer>16384</integer>
                    <key>Slot</key>
                    <integer>2</integer>
                    <key>Type</key>
                    <string>DDR4</string>
                    <key>Vendor</key>
                    <string>Kingston</string>
                </dict>
            </array>
            <key>SlotCount</key>
            <integer>2</integer>
        </dict>

 

Hope you can help me with this and thanks in advance! :)

System Profiler - RAM Slots.png

System Profiler - RAM #2.png

Edited by rramon
Link to comment
Share on other sites

Thanks a lot @Slice

 

That did the magic :)

 

While I'm following  this thread closely, I'm unsure about the following things – maybe cou can clarify about them.

 

Upon examining r5141 config sample I noticed three new entries HWTarget, ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMask.

 

While the function of HWTarget is clear to me, I don't know what values to use for ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMask.

Is there a way to calculate them for noobs like myself?

 

ProductName is set to iMac19,1 for this unit but I have another one which uses iMac18,1.

 

Thank you!

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

×
×
  • Create New...