Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

SavageAUS
SavageAUS
Posted
Posted
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
Slice
Slice
Posted
Posted
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
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted
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

 

Slice
Slice
Posted
Posted

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
Jief_Machak
Jief_Machak
Posted
Posted
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
SavageAUS
SavageAUS
Posted
Posted

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
Slice
Slice
Posted
Posted
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
Jief_Machak
Jief_Machak
Posted
Posted
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 ?

Jief_Machak
Jief_Machak
Posted
Posted

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
rramon
rramon
Posted
Posted (edited)

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
rramon
rramon
Posted
Posted (edited)

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
Slice
Slice
Posted
Posted
1 hour ago, rramon said:

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!

Default values for ExtendedFirmwareFeatures and ExtendedFirmwareFeaturesMask will be OK.

  • Like 4
  • Thanks 1
Gradou
Gradou
Posted
Posted (edited)

Hello

If the problem is on T2 machines:

1) get updates from Monterey
2) to manage to actually update it

I think the RestrictEvents kext is necessary as well as the activation of the 2 ExtendedFirmware (s) by removing the # and adding 8 to the old firmwares.
HWTarget string is not efficient at getting the update and does not override the RestrictEvents kext.
This is my experience with iMacPro1,1 ... What do you think about ?

Edited by Gradou
  • Like 1
rramon
rramon
Posted
Posted (edited)
9 hours ago, Gradou said:

Hello

If the problem is on T2 machines:

1) get updates from Monterey
2) to manage to actually update it

I think the RestrictEvents kext is necessary as well as the activation of the 2 ExtendedFirmware (s) by removing the # and adding 8 to the old firmwares.
HWTarget string is not efficient at getting the update and does not override the RestrictEvents kext.
This is my experience with iMacPro1,1 ... What do you think about ?


What exactly do you mean with „old firmware“?
The values firmware and firmware features (if I recall correctly) generated for the specific Model, say iMac 19,1 in my case?

And the 8 is added in front of them?

 

Thanks for your explanation

3 hours ago, Matgen84 said:

 

See in the sub-forum Clover explanation: from Terminal

  

% sysctl hw.target

I do not know more.


Does terminal return the correct value for one‘s model even if it has been already set (to j160 in my case) in config.plist?

 

Thanks for your explanation

Edited by rramon
  • Like 2
Gradou
Gradou
Posted
Posted (edited)
4 hours ago, rramon said:


What exactly do you mean with „old firmware“?

The firmwares without Extended (initials)
The values firmware and firmware features (if I recall correctly) generated for the specific Model, say iMac 19,1 in my case?

Yes

And the 8 is added in front of them?

Yes, in front of Extended... for instance : iMac 19,1 : ExtendedFirmwareFeatures : 0x8FD8FF576 and ExtendedFirmwareFeaturesMask : 0x8FFDFFF7F

Thanks for your explanation


Does terminal return the correct value for one‘s model even if it has been already set (to j160 in my case) in config.plist?

No, the better is to try under OpenCore 0.7.4-->Terminal : sysctl hw.target   it returns the good value for your SMBIOS (for instance J137AP for iMacPro1,1)

Thanks for your explanation

 

Edited by Gradou
  • Like 1
 Share
Go to topic listing
×
×
  • Create New...