Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

Slice
Slice
Posted
Posted

Hi Slice Thank you for your answer

Maybe I have expressed bad this problem

 

I need of this reboot patch to have my rig booting fine

With clover 4184 I can delete this Patch in  clover config.plist (it is integrated in clover code I think)

Using clover 4200/4210 I have to put again in kernel patch section lines I have written in previous message

Same OSX (High Sierra GM)

without system hangs in ++++++++++++ initial stage (clover 4200/4210)

I never heard Clover contains such patch. Ask Sherlocks.

On my new computer Dell 6430 XhciDxe is not working while USB3 works natively in ElCapitan. It is Intel chip.

Last time I checked this driver was 2 years ago on different hardware.

Can anybody confirm the XhciDxe.efi is working on a computer now?

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

https://sourceforge.net/p/cloverefiboot/code/4140/tree//rEFIt_UEFI/Platform/kernel_patcher.c

ftom @Syscl clover 4140 release is there a support for broadwell E/EP cpu

I have used only a clover 4184 release which is working 

 

@Syscl and @Sherlocks

Kernel Patches support for Broadwell EP unsupported CPU seems changed after clover release Greater than 4184.

Is it possible to have a latest committ with those Patches?

 

Thank You

Show, please, bdmesg output to see details of your CPU.

In terminal

bdmesg > bdmesg.txt

Link to comment
Share on other sites
jaymonkey
jaymonkey
Posted
Posted

Clover feature/enhancement request ...

 

At the moment it seems that clover only sets/initialises a small sub set of the msr registers ... this for me causes the following issue ...

 

I have 2017 15" HP Spectre X360 laptop ... if i cold boot OSX via clover the default msr register values are ok and osx runs great ... if i reboot and reload OSX all is still fine .... same goes if i reboot run linux then reboot and reload OSX ....  however if i run Windows 10 then reboot and run OSX some of the MSR registers are left at the values Windows 10 sets them to and OSX power management does not work correctly ... it looks like (at least in this case) that the BIOS does not re initialise the msr registers on a warm boot/reboot.

 

Having discussed this issue with rehabman it seems that AHCI code can not write to the MSR registers so its not possible to write a SSDT hotpatch to address the issue ... the solution apparently needs to be done through Clover ...

 

One approach to the solution would be some sort of feature to make and save a 'snapshot' of what ALL the msr register values are and store them as a table . maybe achieved through a F-key like the F4 ACPI dump, then all that is required is a clover option in the CPU section to write/update the MSR registers with the table values during clover initialisation ...

 

An advantage of this approach (in addition to resolving  an issue like i'm seeing)  is that advanced users could fine tune all the MSR values by editing the dumped snapshot table once the syntax is fully documented ...  having a option in the config plist to point to the required msr snapshot/table would allow users to experiment with different MSR tables/values (a bit like how we can set the dsdt file name) ... taking it one step further the table structure could then be supported by clover configurator for those users not wishing to directly edit the file(s) and need a gui/msr editor ....

 

I realise this is a niche request right now but it seems that new HP high-end laptops (Spectre & Elite) have a very limited BIOS with no access to any advanced menus so it may become a more prolific problem in the near future ... also its clear to me that those 'other' msr registers have an effect on the systems power management so this feature would sort of make  clover future prof in terms of msr initialisation.

 

I am happy to supply further debug info and test any beta code if needed ....

 

Cheers

Jay

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

Or write a DXE driver which writes to the Boot Script Table and flash...

I afraid we can't.

Kernel will create own script and it will replace our dxe.

Kernel write an address for wake into FACS and goes to sleep.

ACPI will start the computer in Real Mode with the address from FACS. The address is in the kernel.

We may patch the kernel for it creates other procedure to return from sleep.

 

EDK2 tells about boot script not accounting Hackintosh.

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

I afraid we can't.

Kernel will create own script and it will replace our dxe.

Kernel write an address for wake into FACS and goes to sleep.

ACPI will start the computer in Real Mode with the address from FACS. The address is in the kernel.

We may patch the kernel for it creates other procedure to return from sleep.

 

EDK2 tells about boot script not accounting Hackintosh.

 

Why would 'Hackintosh' be any different? A direct jump to the OS wakeup vector makes no sense at all, macOS has no knowledge about how to initialize the platform. EDK2's S3Resume2Pei retrieves the saved S3 data and prepares the platform for DXE phase, then jumps to the BootScriptExecutorDxe driver, which runs all saved boot script entries (including a possible HWP one), locates FACS and then pass control to the OS wakeup vector, which restores the OS context.

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

Why would 'Hackintosh' be any different? A direct jump to the OS wakeup vector makes no sense at all, macOS has no knowledge about how to initialize the platform. EDK2's S3Resume2Pei retrieves the saved S3 data and prepares the platform for DXE phase, then jumps to the BootScriptExecutorDxe driver, which runs all saved boot script entries (including a possible HWP one), locates FACS and then pass control to the OS wakeup vector, which restores the OS context.

You forgot about the difference RealMode ProtectedMode

EDK2's Resume will work in ProtectedMode while macOS kernel started ab ovo, in RealMode. 

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

OK,

but how did you supposed to catch the value Facs->FirmwareWakingVector

it will be assigned by macOS kernel immediately before sleep while you want to get it at boot time?

*sigh* Current UEFI firmwares support Boot Scripts because that's how the platform inits after S3... I don't want to catch it, the firmware does already, how else would resume ever reach that vector?

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

So we should change firmware? 

Is it possible that it would work like

WakeEvent -> Firmware -> DxeDriver -> FACS -> OS

?

You would need to flash a DXE driver. This DXE driver does not(!) run during wakeup, but during initial boot. It writes the register value to the MSR -and- into the Boot Script table. When the FW S3-resumes, the Boot Scripts get executed, which sets the MSR just as DXE driver would if it would run and the OS boots. It would even work if Clover did that, so long as the firmware does not lock the Boot Scripts on EndOfDxe or ReadyToBoot, though one shouldn't bet on that...

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

You would need to flash a DXE driver. This DXE driver does not(!) run during wakeup, but during initial boot. It writes the register value to the MSR -and- into the Boot Script table. When the FW S3-resumes, the Boot Scripts get executed, which sets the MSR just as DXE driver would if it would run and the OS boots. It would even work if Clover did that, so long as the firmware does not lock the Boot Scripts on EndOfDxe or ReadyToBoot, though one shouldn't bet on that...

So DXE driver should reflash main BIOS?

 

 

I notice a bug during dumping all OEM ACPI tables

7:000  0:003    7. CBFFD718: 'SSDT', 'CpuPm', Rev: 1, Len: 2850
 Found hidden SSDT 4 pcs
7:000  0:000        * C52F1018: 'SSDT', 'CpuPm', Rev: 1, Len: 2850  53 53 44 54 22 0B 00 00 01 5F 50 6D 52 65 66 00 Internal length = 2850 -> SSDT-3x.aml
7:003  0:003        * CF489A98: 'SSDT', 'ApIst', Rev: 1, Len: 771  53 53 44 54 03 03 00 00 01 76 50 6D 52 65 66 00 Internal length = 771 -> SSDT-4x.aml
7:006  0:003        * CF488598: 'SSDT', 'Cpu0Cst', Rev: 1, Len: 1315  53 53 44 54 23 05 00 00 01 BC 50 6D 52 65 66 00 Internal length = 1315 -> SSDT-5x.aml
7:010  0:003        * CF48FC18: 'SSDT', 'ApCst', Rev: 1, Len: 281  53 53 44 54 19 01 00 00 01 EC 50 6D 52 65 66 00 Internal length = 281 -> SSDT-6x.aml
7:013  0:003   -> SSDT-2.aml

Tables SSDT-3x and SSDT-2 are the same.

It happen because of procedure DumpChildSsdt ( ©Dmazar) is recursive.

But I never encounter SSDT double embedded. May be we should make it plain procedure? Someone?

 

EDITED.

It's not a Clover bug. These tables have different memory location and so this is a BIOS bug. We can compare TableID and exclude older one. But it is already dumped.

It's manual job.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Pretty much everything you would need to figure out from Intel specs is easy available, unlike AMD stuff, and since EDK2, more broadly UEFI, are both mainly fueled by intel so is that stuff. I think this document will probably explain exactly what's happening, how S3resume works, and how to change it. Also if you notice it appears S3resume is SMM locked in the DXE phase by design. The actual stuff takes place in PEI, so that's probably entirely a firmware modification. It's hard to look at some parts of the EDK2 and take it realistically that is the way it's being done directly from initialization in a hardware's firmware, Aptio ends up looking very different from EDK2.

  • Like 1
Link to comment
Share on other sites
  • 2 weeks later...
cecekpawon
cecekpawon
Posted
Posted

I have checked my 10.13 installers boot.efi and they shown as 10.12 (created from 10.12 with createinstallmedia), which is bad.
Please try this patch (added dbg infos + comment out (Entry->LoaderType == OSTYPE_OSX_INSTALLER) here).
Temporarily install mandatory kexts in /L/E/ with CSR_ALLOW_UNTRUSTED_KEXTS so you are able to reach the desktop.

 

** In xnu-4570.1.46

#define CSR_ALLOW_UNAPPROVED_KEXTS  (1 << 9)
  • Like 6
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Oh, that's a very fast and deep rabbit hole. MSRs are not the same for all CPUs, in fact some CPUs in the same family/model with different hardware revisions and feature sets have different MSRs. Some models allow you to set some MSRs, while others do not allow you to modify these values. The biggest example is the K models that have unlocked multiplier and turbo MSRs. Some models have power management features that you can change MSRs for while others do not, and others still only allow the value to be written once then it is locked and can only be read until the reset pin has voltage for at least a minimum period of time (a full reset takes place). Also, writing or reading MSRs can cause an exception, so you'd have to be sure what values you could set and which MSRs can be written or you would not be able to boot because clover would just throw exception and crash every time it tries to set that MSR. Have you tried making sure that your firmware doesn't have like "fast boot" enabled? Where it purposefully doesn't initialize this stuff? Because I don't understand why it wouldn't be initializing the power management MSRs every boot... On the other hand, I'm pretty sure that all of those have default values when the CPU itself is initialized. I mean that really just seems like a terrible job at writing firmware......

 

Or write a DXE driver which writes to the Boot Script Table and flash...

 

:blink: Probably SMM locked in DXE phase. You would need to write a PEI driver. Also, man, that's some bricking your mobo territory....

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

 

 

:blink: Probably SMM locked in DXE phase. You would need to write a PEI driver. Also, man, that's some bricking your mobo territory....

Nah, Boot Script Table cannot be written to during PEI and full SMM Foundation is init via a DXE driver. iirc SMM is locked at EndOfDxe
Link to comment
Share on other sites
cecekpawon
cecekpawon
Posted
Posted

This patch looks reasonable. Will it cause side effect?

 

Hope no. From comment:

// Correct OSVersion if it was not found
// This should happen only for 10.7-10.9 OSTYPE_OSX_INSTALLER
// For these cases, take OSVersion from loaded boot.efi image in memory

No need to take OSVersion from loaded boot.efi if we already have valid OSVersion grabbed from plist.

We can apply OSVersion value from loaded boot.efi to all OSTYPE_OSX (not just installer) with no OSVersion as a last attempt.

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

Nah, Boot Script Table cannot be written to during PEI and full SMM Foundation is init via a DXE driver. iirc SMM is locked at EndOfDxe

 

It can only be written during PEI and also is SMM locked before DXE phase. The Boot Script Executor is the first and only module to execute in DXE when resumed.

S3Resume PEIM performs the below-listed major actions:
 Restore all LockBox to its original place.
 Call SMM entry point to restore processor configuration.
 Lock SMM. This must be done to maintain SMM integrity.
 Call Boot Script Executor to restore chipset configuration.
 Signal EndOfPei, to notify other PEIMs.
 Find FACS OS waking vector to resume.
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

That's restoring from SMRAM but I was just showing you that it can only be written in PEI. S3 SMM driver runs in PEI, and DXE must dispatch SMM call to save it. You can see that from the code you just linked, it uses SMM lock box. Look at the code for SMM lock box, the service instance runs in PEI (and obviously SMM).

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

That's restoring from SMRAM but I was just showing you that it can only be written in PEI. S3 SMM driver runs in PEI, and DXE must dispatch SMM call to save it. You can see that from the code you just linked, it uses SMM lock box. Look at the code for SMM lock box, the service instance runs in PEI (and obviously SMM).

 

Well, of course it uses the LockBox...

DXE driver writes a Boot Script -> BootScriptLib saves the data to LockBox -> reset -> PEIM retrieves lock box -> DXE executes Boot Scripts and resumes.

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