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

I have such a strange disk

iMac-2:Clover slice$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS MacHD                   270.5 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS HighHD                  118.3 GB   disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
   6:                        EFI NO NAME                 104.9 MB   disk0s6
   7:       Microsoft Basic Data Data                    109.7 GB   disk0s7

Why second EFI? I don't know as well as many other users.

Link to comment
Share on other sites
tluck
tluck
Posted
Posted

I have such a strange disk

iMac-2:Clover slice$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS MacHD                   270.5 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
   4:                  Apple_HFS HighHD                  118.3 GB   disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
   6:                        EFI NO NAME                 104.9 MB   disk0s6
   7:       Microsoft Basic Data Data                    109.7 GB   disk0s7

Why second EFI? I don't know as well as many other users.

 

 

the 2nd EFI was probably made by the windows installer. i have seen this happen before. i cant remember if there was stuff on it... but then i remember manually deleted the 2nd EFI to avoid confusion.

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

I have this EFI NO NAME of windows. it is a Windows Pure UEFI and does not cause any confusion,

it allows me to boot natively on windows with Clover  :) From my Dell Optiplex 790

 

Same in my HP ProBook 6570B

 

captur33.png

 

This is the content 

captur35.png

 

EDIT***

I rename to EFI and boot to Windos 10 nomaly, thats change nothing

captur36.png

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

I have such a strange disk

....

Why second EFI? I don't know as well as many other users.

@Slice: Uhmmmb.., what's strange? :rolleyes: My whole disk is Legacy-GPT converted from MBR w/o erasing. EFI partition is manually created with GParted under Linux (Live) and set as esp there. I then re-formatted it under macOS with "$ newfs_msdos -v EFI -F 32 /dev/rdisk0s1".

 

#EDIT: Oops, my bad.. U mean 2nd EFI (disk0s6), sorry  ^_^ 

ZvJmwno.jpg

Link to comment
Share on other sites
syscl
syscl
Posted
Posted

 

RE: nvram save script and SIP

 

@syscl

here is rewrite of the nvram_save_script (v1.16.6) using diskutil to find the EFI partition on disks vs gpt (which has restrictions when SIP is completely enabled).  The section to find EFI device is based on the RehabMan's parse method from above - but adapted for this script. The point was to check find a disk's EFI partition (not by name) and its associated device name (e.g disk0s1)

 

the key section looks like this now:

for ((i=0; i<${#gDisk[@]}; ++i))
    do
      local gESP=""
      local plist=$( diskutil list -plist "/dev/${gDisk[i]}" 2> /dev/null )
      for ((part=0; 1; part++));
      do
            content=$( /usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:Content" /dev/stdin <<< $plist 2>&1 )
            if [[ "$content" == *"Does Not Exist"* ]];
            then
                break
            fi
            if [[ "$content" == "EFI" ]];
            then
                gESP=$( /usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:DeviceIdentifier" /dev/stdin <<< $plist 2>&1 )
                break
            fi
      done
      gLogTimeStamp=$(date +%Y-%m-%d-%H:%M:%S)
      if [[ $gESP != "" ]];
      then
            printf "${gLogTimeStamp}  ${gDisk[i]}: ESP --"
                     local gMountPoint=$(_mountESP ${gESP})
      ...
      else
            printf "${gLogTimeStamp}  ${gDisk[i]}: ------ Ignored -- No ESP on disk\n"
      fi
    done

Thank you, I have committed to r4269 already. In fact, as of my first version of this script I use diskutil for all mounting, unmount and identified ESP/EFI partition, so actually all this operations can use diskutil(more concise and tidy code). Since we now use LogoutHook so that we don't need to worry about diskutil is unavailable issue. 

 

syscl

  • Like 5
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted
Note: I was going to do each of these as a separate post, but the stupid site wouldn't do that.
So... all in one!
 
--
 
restore "Without caches" option
 
This is still a relatively commonly used option and therefore should be easy to do (eg. without adding -f to Boot/Arguments from Clover Options).
 
Affected files: loader.c

 

---
 
SSDT generation changes:
 
ACPI/SSDT/Generate/APSN
ACPI/SSDT/Generate/APLF
ACPI/SSDT/Generate/PluginType
 
Allow separate control over these object injections in generated PM SSDT.
This is useful when using SSDT.aml generated from ssdtPRgen.sh, but dropping the OEM CPU related SSDTs.  In that case you want to use Generate=true (to generate CStates/PStates, aka _PSS, _CST, etc), but you don't want to generate APSN, APLF as these objects are already in ssdtPRgen.sh generated SSDT.aml.
 
Generate/PluginType is useful for injecting only plugin-type=1 on CPU0.  Used by itself, it can be used to enable native CPU PM on Haswell and later.  This option was already "sort of" in there but required HWP to be used as well.  This change makes it applicable even if not using HWP. 
 
Affected files: Settings.c, Platform.h, StateGenerator.c. AcpiPatcher.c
 
Related commits (this one took me a while to get backward compatibility right):
 
--
 
Minor cleanup: "remove unused identifier kernelXCPMAllowed"
 
 
--
 
Fixing SSDT extracted names: "strip trailing spaces from SSDT OemTableId for origin dump"
 
Recent change was made to place OemTableID as a suffix for extracted SSDTs (eg. "SSDT-7-SaSsdt.aml"), but often you end up with trailing spaces
(eg. "SSDT-7-SaSsdt  .aml").
 
Afffected files: AcpiPatcher.c
 
 
--
 
Adding OemTableId to extracted SSDTs is not always convenient.
Added config.plist/ACPI/SSDT/NoOemTableId option to disable it.
 
Affected files: AcpiPatcher.c, Platform.h, Settings.c
 
 
 
--
 
Changed numbering scheme for dynamic SSDTs (this is for AutoMerge feature below).
By numbering the dynamic ones differently, the number assigned to static SSDTs can be used to find the placement in the XSDT for automatic merge/replacement.
 
New numbering scheme for dynamic SSDTs is:
- For dynamic SSDT pointed by DSDT.aml: SSDT-xDSDT_#-id.aml (# is child reference count)
- For dynamic SSDT pointed by an SSDT: SSDT-x#_#-id.aml (first # is static SSDT reference#, second # is child reference #)
 
Static SSDTs always end up with a contiguous numbering scheme, SSDT-0*.aml through and including SSDT-n*.aml, where n is the number of static SSDTs minus 1.
 
Affected files: AcpiPatcher.c 
 
 
--
 
AutoMerge feature for merging/replacement of SSDTs (or other AMLs) by content in ACPI/patched
 
By setting config.plist/ACPI/AutoMerge=true (default is false to retain old behavior), content in ACPI/patched will attempt to be matched against native bits referred to by the XSDT.  Much like how DSDT.aml placed in ACPI/patched *replaces* native DSDT, you can use this feature to replace SSDTs (or other tables) automatically without using DropTables, or DropOem. More importantly, the relative order of the tables is retained.  It means you can replace only a single table without resorting to DropOem=true and SortedOrder (which implies placing all SSDTs in ACPI/patched). 
 
The matching is based on file name and OemTableID/signature.
 
For SSDTs, the number in the file name is used to find the index in XSDT.  So, a file named SSDT-5.aml in ACPI/patched will replace the 6th SSDT in XSDT (because SSDTs extracted start at SSDT-0.aml).  Additional checking is done with regard to the OEM table ID, to avoid obvious mistakes (eg. placing an SSDT-x.aml that is not a patched SSDT, or mixing up the naming/numbering of the SSDTs in ACPI/patched).
 
With the change to dynamic SSDT extraction file names (above) and this change, it means you can take any SSDT that was extracted, patch it, and place in ACPI/patched, and without making changes to DropOem or DropTables (or using SortedOrder) it will replace the original SSDT with the patched version, retaining SSDT order.  In other words, Clover does the right thing with AutoMerge=true, contrary to what it does by default.
 
This setting also affects how config.plist/ACPI/DSDT/Patches are treated.  Normally, such patches do not apply to SSDTs.  But with AutoMerge=true, such patches are now applied to patched OEM SSDTs in ACPI/patched.  Still, add-on SSDTs (eg. those that didn't match existing tables in XSDT), are not affected by ACPI/DSDT/Patches.  It means that no major surprises happen when you place a patched SSDTs in ACPI/patched.
 
The default of AutoMerge is false, so it is a feature you must explicitly select.
 
Files affected: AcpiPatcher.c, Platform.h, Settings.c, menu.c
 
 
--
 
Add config.plist/ACPI/DSDT/Fixes/FixMutex optioin
 
The ACPI runtime in macOS/OS X does not work correctly with Mutex objects with a non-zero SyncLevel, even when used in a valid scenario.
 
Such Mutex definions must be changed to use SyncLevel 0.
 
The FixMutex feature is an easy way to fix all of them in DSDT.
 
Affected files: FixBiosDsdt.c, Platform.h, Settings.c, menu.c
 
 
Note: That commit calls it "FixMutex_40000000", but a later commit renames the option to "FixMutex".
 
--
 
There are cases in AcpiPatcher.c where a file is loaded using AllocatePool, but freed with FreePages.
Should be FreePool.
 
Also, no need to zero a buffer before loading the file into it (as all bytes in the buffer will be set by file content).
 
Affected files: AcpiPatcher.c, image.c
 
 
--
 
Friendly names for config.plist/ACPI/DSDT/Fixes
 
There is no need to burden the user with the bitmask values for DSDT/Fixes.
Old names are provided for backward compatibility.
Also, made the code table driven.
 
Also, changed (new) names to have consistent capitalization.
 
Affected files: Settings.c
 
My readme describes mappings from old name to new name:
 
--
 
Add with/without injected kexts.  "Cancel hibernate" conditional.
 
Affected files: loader.c
 
 
--
 
Fixed menu navigation regarding space/enter/esc keys
 
Affected files: menu.c
 
 
--
 
Remove hand padding/alignment in Platform.h
 
Easier to maintain.  Let the compiler work for us, not against us.
Also removed unecessary ADDRESS_OF macro (taking the address of a member within instance is not complex)
 
Affected files: Platform.h, menu.c
 
 
--
 
Refactor platformdata.c to use a single array instead of separate arrays
 
Separate arrays leave open the possibility of mistakes...  Single array of struct allows all data for a given SMBIOS model to be seen in one place, and allows easier edits.
 
The new data was generated mostly programatically from original platformdata.c itself.
 
Affected files: Settings.c, platformdata.c
 
 
--
 
malloc/free/realloc implementation in lodepng.c was wrong.
Correct implementation requires storage of the original allocation size for use in realloc.
 
Affected files: loadpng.c
 
 
--
 
Original "embedded" images had hand-coded/hard-coded sizes.  
Not necesary.
The compiler provides sizeof() for this.
Alignment is also possible with __attribute__((__aligned__(8))) 
(no compiler guarantee that one data definition followed by another end up in that order anyway)
 
Affected files: egemb_font.c, scroll_images.c, icns.c, menu.c, libegint.h
 
Related commits:
 
--
 
Add config.plist/ACPI/SSDT/NoDynamicExtract option
 
Dynamic SSDTs confuse users and are amost never needed.  Added an option to config.plist to disable extraction of them via Clover F4 (default is false).
 
Affected files: AcpiPatcher.c, Platform.h, Settings.c
 
  • Like 18
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

@RehabMan

Thanks for your work. I will accept all your changes during next week. Let users decide if it good and useful.

 

Great.

Here's another:

 

--

 

Updated config-sample.plist files for friendly ACPI/DSDT/Fixes names; added commented APLF/APSN/PluginType; AutoMerge=true

 

https://github.com/RehabMan/Clover/commit/f80d52218f0c0aa091fe7557e3e3841961d66905

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

It appears many of my changes were not properly/faithfully applied to the sourceforge sources.

 

seems to be the case.

 

I took your AcpiPatcher.c file (https://raw.githubusercontent.com/RehabMan/Clover/master/rEFIt_UEFI/Platform/AcpiPatcher.c) and removed this section:

if (gSettings.NoDynamicExtract) {

    return;

  }

Dropped into 4286 -  it compiled and runs just fine.

 

Main problem with Slice's version of AcpiPatcher.c is this (it is wrong):

 

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
    EntryCount = XsdtOriginalEntryCount;
    //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Should be (version on my github):

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Contrary to the comments in the sourceforge version of the file, that change is not one I made (I made no changes to the GetAcpiTablesList function).

 

XsdtOriginalEntryCount is used in PatchAllSSDT in order to patch native SSDTs and patched SSDTS that were merged into existing XDST slots with config.plist/ACPI/DSDT/Patches. We want to patch those SSDTs with ACPI/DSDT/Patches, but not those that are pure add-on SSDTs (added to the end of the XDST) table.

XsdtOriginalEntryCount is not even initialized when GetAcpiTablesList is called.

Its calculation is very carefully placed after dropping tables, but before adding tables from ACPI/patched.

 

I don't know why Slice made this change, but it is likely the cause of the recently reported problems.

 

Edit: It appears the required change was also NOT made to PatchAllSSDT. Sourceforge version of PatchAllSSDT reads:

  EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
But should be (my change):

  // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
  EntryCount = XsdtOriginalEntryCount;
  //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
There were also incorrect changes in menu.c, so I would not be surprised if the menus don't work properly when compared to my Clover fork.
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@all

This thread is for code propositions.

Unrelated posts moved to "General discussion".

 

I want to keep this thread as clean as possible for easy development.


 
 
Main problem with Slice's version of AcpiPatcher.c is this (it is wrong):
 

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
    EntryCount = XsdtOriginalEntryCount;
    //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Should be (version on my github):
VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Contrary to the comments in the sourceforge version of the file, that change is not one I made (I made no changes to the GetAcpiTablesList function).

XsdtOriginalEntryCount is used in PatchAllSSDT in order to patch native SSDTs and patched SSDTS that were merged into existing XDST slots with config.plist/ACPI/DSDT/Patches. We want to patch those SSDTs with ACPI/DSDT/Patches, but not those that are pure add-on SSDTs (added to the end of the XDST) table.
XsdtOriginalEntryCount is not even initialized when GetAcpiTablesList is called.
Its calculation is very carefully placed after dropping tables, but before adding tables from ACPI/patched.

I don't know why Slice made this change, but it is likely the cause of the recently reported problems.

Edit: It appears the required change was also NOT made to PatchAllSSDT. Sourceforge version of PatchAllSSDT reads:
  EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
But should be (my change):
  // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
  EntryCount = XsdtOriginalEntryCount;
  //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
There were also incorrect changes in menu.c, so I would not be surprised if the menus don't work properly when compared to my Clover fork.

 

The work is not finished. Seems your partial commits do not lead to the same codes.

I had to copy platformdata.c as a whole file.

 

I not agree with your comment about Mutex().

Making DSDT for my Dell Latitude E6430 I tested an advice to zero them. NO! This did worst.

MacOS know Mutex and able to use it. My best working DSDT contains non-zero Mutexes.

Anyway the feature is optional. Let it be.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

The work is not finished. Seems your partial commits do not lead to the same codes.

Not true. You simply applied the changes to the wrong location. My commit for AutoMerge=true was a single/complete commit.

 

When you are done, I will review your work.

 

I had to copy platformdata.c as a whole file.

That is the best way.

 

I not agree with your comment about Mutex().

Making DSDT for my Dell Latitude E6430 I tested an advice to zero them. NO! This did worst.

MacOS know Mutex and able to use it. My best working DSDT contains non-zero Mutexes.

Anyway the feature is optional. Let it be.

Actually, it is well known that Mutex with non-zero SyncLevel *must* be changed to zero.

You probably have other issues in your ACPI code (such as multibyte EC fields).

If you read by battery patching thread, you will find many examples.

 

If you have Mutex objects with non-zero SyncLevel, it is just that the code is not reachable.

Non-zero SyncLevel does not work on macOS/OS X implementation of ACPI.

BTW, the code you have in Settings.c for friendly ACPI/DSDT/Fixes names is wrong.

 

You have:

        Prop = GetProperty (Dict2, "Fixes");
        if (Prop != NULL) {
          UINTN Index;
 //         DBG ("Fixes will override DSDT fix mask %08x!\n", gSettings.FixDsdt);

          if (Prop->type == kTagTypeDict) {
            gSettings.FixDsdt = 0;
          }
          
          for (Index = 0; Index < sizeof(FixesConfig)/sizeof(FixesConfig[0]); Index++) {
            Prop2 = GetProperty(Prop, FixesConfig[Index].newName);
            if (!Prop2 && FixesConfig[Index].oldName) {
              Prop2 = GetProperty(Prop, FixesConfig[Index].oldName);
            }
            if (IsPropertyTrue(Prop2)) {
              gSettings.FixDsdt |= FixesConfig[Index].bitData;
            }
          }
        }
Should be:

        Prop = GetProperty (Dict2, "Fixes");
        if (Prop != NULL) {
          UINTN Index;
 //         DBG ("Fixes will override DSDT fix mask %08x!\n", gSettings.FixDsdt);

          if (Prop->type == kTagTypeDict) {
            gSettings.FixDsdt = 0;
            for (Index = 0; Index < sizeof(FixesConfig)/sizeof(FixesConfig[0]); Index++) {
              Prop2 = GetProperty(Prop, FixesConfig[Index].newName);
              if (!Prop2 && FixesConfig[Index].oldName) {
                Prop2 = GetProperty(Prop, FixesConfig[Index].oldName);
              }
              if (IsPropertyTrue(Prop2)) {
                gSettings.FixDsdt |= FixesConfig[Index].bitData;
              }
            }
          }
        }
One thing I noticed while merging: I will change my Clover fork Settings.c to clear FixDsdt before processing the entries in config.plist/ACPI/DSDT/Fixes such that it behaves as intended if both are specified.
  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Actually, it is well known that Mutex with non-zero SyncLevel *must* be changed to zero.

You probably have other issues in your ACPI code (such as multibyte EC fields).

If you read by battery patching thread, you will find many examples.

 

If you have Mutex objects with non-zero SyncLevel, it is just that the code is not reachable.

Non-zero SyncLevel does not work on macOS/OS X implementation of ACPI.

I know about multibyte EC fields. It is not my case. It seems Dell knows too

            Method (ECR2, 1, NotSerialized)
            {
                Local0 = ECR1 (Arg0)
                Arg0++
                Local1 = (ECR1 (Arg0) << 0x08)
                Local0 += Local1
                Return (Local0)
            }

About Mutex see

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                Name (BST0, Package (0x04) {})
                ECG6 (One, BST0)
                Return (BST0) // \_SB_.BAT0._BST.BST0 
            }

The method ECG6 read battery status

        Mutex (ECM1, 0x01)
        Method (ECG6, 2, NotSerialized)
        {
            Acquire (ECM1, 0xFFFF)
            Local2 = ECG2 ()
            ECWB (0x03, Arg0)
            Arg1 [Zero] = ECRB (0x10)
            Local0 = ECRW (0x12)
            If (Local0 == Zero)
            {
                Local0++
            }
            ElseIf (Local2 != Zero)
            {
                If (Local0 & 0x8000)
                {
                    Local0 = Ones
                }
            }
            ElseIf (Local0 & 0x8000)
            {
                Local0 = (Zero - Local0)
                Local0 &= 0xFFFF
            }
            Else
            {
                Local0 = Ones
            }

            Arg1 [One] = Local0
            Local0 = ECRW (0x16)
            Arg1 [0x02] = Local0
            Local0 = ECRW (0x14)
            Arg1 [0x03] = Local0
            Release (ECM1)
        }

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

Link to comment
Share on other sites
nms
nms
Posted
Posted

I know about multibyte EC fields. It is not my case. It seems Dell knows too

            Method (ECR2, 1, NotSerialized)
            {
                Local0 = ECR1 (Arg0)
                Arg0++
                Local1 = (ECR1 (Arg0) << 0x08)
                Local0 += Local1
                Return (Local0)
            }

About Mutex see

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                Name (BST0, Package (0x04) {})
                ECG6 (One, BST0)
                Return (BST0) // \_SB_.BAT0._BST.BST0 
            }

The method ECG6 read battery status

        Mutex (ECM1, 0x01)
        Method (ECG6, 2, NotSerialized)
        {
            Acquire (ECM1, 0xFFFF)
            Local2 = ECG2 ()
            ECWB (0x03, Arg0)
            Arg1 [Zero] = ECRB (0x10)
            Local0 = ECRW (0x12)
            If (Local0 == Zero)
            {
                Local0++
            }
            ElseIf (Local2 != Zero)
            {
                If (Local0 & 0x8000)
                {
                    Local0 = Ones
                }
            }
            ElseIf (Local0 & 0x8000)
            {
                Local0 = (Zero - Local0)
                Local0 &= 0xFFFF
            }
            Else
            {
                Local0 = Ones
            }

            Arg1 [One] = Local0
            Local0 = ECRW (0x16)
            Arg1 [0x02] = Local0
            Local0 = ECRW (0x14)
            Arg1 [0x03] = Local0
            Release (ECM1)
        }

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

Changing SyncLevel only in Mutex() is not enough. Acquire() and Release() must be adjusted as well.

Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

I think you have something else going on.

But FixMutex is available for those that need it.

And if you don't need it, like any other Clover fix, simply don't use it.

 

Someone really needs to fix the sourceforge version of AcpiPatcher.c.

The code I see checked into the project is still very wrong (as I fully described previously).

 

Changing SyncLevel only in Mutex() is not enough. Acquire() and Release() must be adjusted as well.

Not true. The Acquire/Release code in Slice's snippet is valid.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

@all

This thread is for code propositions.

Unrelated posts moved to "General discussion".

 

I want to keep this thread as clean as possible for easy development.

 

Is it possible to change permission on a thread/topic to only allow coders, developers and the various forms of moderators/admin? Because I like the idea of discussion threads for random clover talk, clover bug/issue/request reports, and clover development (which is only locked to developers). I think that most users see this as a place to report problems or request feaures, which because of the thread title seems correct. So either we should create a separate developer only thread about development, or rename this thread to development only and create another separate bug/issue/request thread. No?

  • Like 5
Link to comment
Share on other sites
ErmaC
ErmaC
Posted
  • Author
Posted

Is it possible to change permission on a thread/topic to only allow coders, developers and the various forms of moderators/admin? Because I like the idea of discussion threads for random clover talk, clover bug/issue/request reports, and clover development (which is only locked to developers). I think that most users see this as a place to report problems or request feaures, which because of the thread title seems correct. So either we should create a separate developer only thread about development, or rename this thread to development only and create another separate bug/issue/request thread. No?

I will take a look to accomplish this request...

 

Maybe a permanently looked topic or dedicaded subforum.

 

ErmaC

  • Like 6
Link to comment
Share on other sites
RehabMan
RehabMan
Posted
Posted

@Slice

 

Those changes in r4289 commit look like they should fix the ACPI problems (and others), so thanks for correcting the code to better match my original.

 

FYI, I will probably have no chance to test/merge/diff/review/etc until early next week sometime.

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

Some stuff that may interest detail menu:

 

There's not really much you can do but I would like to be able to boot into safe mode (and variant modes) and resume directly from clover, but this requires instead of using \EFI\Microsoft\Boot\bootmgfw.efi using the OS volume's winload.efi or winresume.efi in the System32 folder of the Windows folder. However, apparently both of these folders could be named differently, and you'd have to parse the windows BCD to determine where to actually load those from. Also determining whether to resume or not, no idea how that happens in windows. In fact you can't even skip bootmgfw.efi, I tried to decompile, UefiDumpCalls, and figure out what it was doing to be able to load those but it doesn't appear to really do much and I tried to copy what it did but it did not work.... Also when resuming from firmware, I see a little circle spin for like a second, maybe two, and I get login screen, login, everything is still there. From clover, I get a really long time with spinning circle, then separate completely black screen with spinning circle, then login screen, login, nothing is there. So what is going on that's causing it to fail?

 

There have been many people asking about netboot for not just windows but pretty much every OS. UEFI spec now includes Wifi and supplicant among other stuff, that make it more plausible now. I just have no idea how we would implement it. Since there would be no local installation, the only thing could be that the user would have to create a custom entry, but that would mean modifying that to work remotely....

 
EDIT: Or we could add another tool, disabled by default that you can enable, to netboot. That might be the best approach.
 
I know some people have been asking about patching/dropping tables and injecting others, more than the limited amount we allow now. I'm not sure what purpose this accomplishes in windows, most of those tables were designed and tested only with windows, so I can only imagine that there is a bug in one of the tables or they wish to change p-states/c-states? I'm not sure what else there could be...

 

Some stuff that has to do with windows and clover in general:

 

Some method to be able to choose the boot disk from any OS to just restart to once, like if you have everything set to just start immediately with no interaction or timeout to macOS. The only way I could see this is if we stuck another little plist on a partition just like nvram emulation, and searched, parsed, then removed it. Any script or executable could be made for any OS then to change the startup disk for just the next boot, we could actually probably have it change the default too.

 

There appears to be some sort of issue when chainloading windows through clover, I believe it is related to memory or something because I have issues if not booted directly from my firmware. Which is weird because nothing should be happening, only a few ACPI tables might be injected but I currently am not injecting. Although I was injecting my SLIC back on my old mobo because I had flashed a leaked beta firmware that had no branding and never had a problem always booting through clover. Maybe I just didn't notice and problems I was having, I was blaming on windows. Like this .mkv bug where I couldn't play any .mkv videos in any player until I got windows 10, they just froze and looped a fraction of the beginning. No way to do anything but completely power off, restarting sent into infinite boot loop (that may have been the firmware though, it did that often). I'm not sure what and how much we can actually affect because of the windows boot manager, it seems to want things in an exact way. The UEFI spec was actually written around exactly what microsoft wanted, down to the exact modes and frame buffers the graphics output protocol HAS to support to be UEFI compliant. As well as safe boot, with only microsoft keys in the default key dbs.

 

I'm sure there's more but I can't think of anything off the top of my head. It may be a question to ask users.

  • Like 5
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted
to developers
some part remains for reset nvram.
basic reset nvram features is working.

 

1. consider more reset keys. i just added some keys. 

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/Platform/Nvram.c#l45

https://sourceforge.net/p/cloverefiboot/code/4299/tree/rEFIt_UEFI/Platform/Platform.h#l624

 

2. translation (en/kr were done)

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/refit/menu.c#l1356

 

3. now can remove nvram file for reset on ESP(EFI) partition, but on APFS/HFS+, can't remove. show message "block blah blah"

actually, DeleteFile is work but. still there is nvram file on mac partition(APFS/HFS+). i tested to add nvram.plist as manual.

clover always find nvram.plist when booting on emulvariables. if there is hibernation mode info in nvram.plist on mac partition without nvram file on ESP.

we can face with problem if not support hibernation on user system. link

need to remove nvram.plist on all partition for reset. but now, only works on ESP. i don't have idea to remove nvram.plist on APFS/HFS+. need to improve this part.

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/Platform/Nvram.c#l223

 

thanks in advance.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

To delete a file from HFS+ partition we have to rewrite driver VBoxHFS.efi to be RW driver while it is RO driver for now.

But I think you should not delete this file. You have just not read it.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

No, he wants to delete this file because it contains erroneous information and is not allowing for boot. You can't delete from an HFS+ during boot like Slice said, that's why you should not install directly to a HFS+ volume. You should always install to the ESP, even legacy booting. I think maybe this should be a change made to the installer package. Since installing to an MBR disk requires patching the macOS installer anyway. Plus the problem also lies in why EmuVariable is not allowing for deletion of variables, that's the real solution. Sherlocks method is just work around, as clearing these variables will write out correct nvram.plist next logout.

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

No, he wants to delete this file because it contains erroneous information and is not allowing for boot. You can't delete from an HFS+ during boot like Slice said, that's why you should not install directly to a HFS+ volume. You should always install to the ESP, even legacy booting. I think maybe this should be a change made to the installer package. Since installing to an MBR disk requires patching the macOS installer anyway. Plus the problem also lies in why EmuVariable is not allowing for deletion of variables, that's the real solution. Sherlocks method is just work around, as clearing these variables will write out correct nvram.plist next logout.

Usually nvram.plist is stored into EFI partition where it can be easy deleted.

But there is Lilu+HibernationFixup who can save nvram.plist only on root folder which is HFS+ or even APFS. So Sherlocks method is not compatible with this plugin.

 

I am still not understading what is the reason to reset NVRAM? Can you provide me full report showing the issue? May be we must cure the reason and not the sequence?

 

May be we can create HFS+ RW driver but the problem much harder for APFS.

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

Usually nvram.plist is stored into EFI partition where it can be easy deleted.

But there is Lilu+HibernationFixup who can save nvram.plist only on root folder which is HFS+ or even APFS. So Sherlocks method is not compatible with this plugin.

 

I am still not understading what is the reason to reset NVRAM? Can you provide me full report showing the issue? May be we must cure the reason and not the sequence?

 

May be we can create HFS+ RW driver but the problem much harder for APFS.

i reported this

http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2534000

 

if there is nvram.plist with hibernation info on root which is HFS+/AFPS, happen instant reboot.

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page-768?do=findComment&comment=2532230

here is his log

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2532298

my log.

https://sourceforge.net/p/hibernationfixup/discussion/general/thread/93f601f6/

 

i think that there is not best for nvram.plist with hibernation info in root which is apfs/hfs+. it causes issue on some system. i tested before. just confirm that hibernationfixup works or not

in my case, specially, I can not take any action. it's critical issue until format apfs disk(nvram.plist) from windows. My system always happen instant reboot when enter any osx disk(usb installer/HS/recovery/everything related in mac).

 

So, if nvram has hibernation info on ESP, if user system can't use hibernation mode from test, just press f11, then clover remove nvram.plist. no need to extra behavior.

to avoid instant reboot after shortly shown osxaptiofix message. example in windows, mount ESP, remove nvram.plist to reset.

 

sorry for my bad english.

 

EDIT1.

i dont know MBR case and legacy for hibernation.

I'm considered UEFI+GPT.

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