Jump to content

syscl

Coders
  • Content Count

    290
  • Joined

  • Last visited

  • Days Won

    9

Reputation Activity

  1. Like
    syscl reacted to tluck in Clover Problems and Solutions   
    @syscl -
     
    the new scripts are working to write to nvram.plist root of ESP!
    well in fact it writes nvram to all 3 of my disks in the root dir of ESP.  and one of my disks which does not even have EFI/CLOVER its an .apdisk
     
    perhaps should check to see if .apdisk is present (i.e. no OS or EFI/CLOVER etc) 
     
    looks good though
  2. Like
    syscl got a reaction from Slice in Clover Problems and Solutions   
    Hi all, finally settled down and figured out why we cannot save/dump the nvram.plist to ESP. Let me explain then show my fix.
     
    First I noticed the following piece of message from the rc.shutdown.log(my version of 80.save_nvram_plist.local)
    Found EFI disk0s1 Mount filesystem msdos kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/msdosfs.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/msdosfs.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled. /System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled. mount_msdos: msdos filesystem is not available mount_hfs: Invalid argument kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/exfat.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/exfat.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/exfat.kext - (libkern/kext) function disabled. /System/Library/Extensions/exfat.kext failed to load - (libkern/kext) function disabled. mount_exfat: exfat filesystem is not available >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local r-- 1 root wheel 2190 Jan 2 13:52 /Volumes/EFI01/nvram.plist The problem is: at the shutdown stage, copious amount of system services will be closed, we are again in a very limited situation: we cannot use diskutil or mount at this stage to mount even a single ESP. 
     
    And now we can explain why r3974's 80.save_nvram_plist.local partly work:
    msdosfs.kext and exfat.kext aren't loaded every time we boot macOS If we by chance mount the ESP(Fat32 or exFat), then system will load msdosfs.kext and exFat.kext, that's why we will see the script partly works Another problem is that Jrs and Taylan's 80.save_nvram_plist.local has copious amount of redundant code, unclear logic, thus I rewrite all of the 80.save_nvram_plist.local myself. Pairing with the touched version of 20.mount_ESP.local(force load msdosfs.kext and exfat.kext during startup), now nvram can be saved in EFI/ as expected.
     
    Compared to Jrs and Taylan's script, my version of 80.save_nvram_plist.local has the following advantages
    clean steps and logic remove redundant operations(we should operate fast at the shutdown stage) dump nvram.plist to all the EFI partitions if possible, and yes, ensure uniqueness of each mounted EFI use EmuVariablePresent to judge if we need to dump NVRAM if mount ESP failed(very possible disk0s1 damage) then dump NVRAM to / (just in case) @Sherlock's version only dump the NVRAM to /, but doesn't really solve the problem. My version of the script not only fix the nvram dump issue but also consider EFI cannot mount case ...  
    How to use my 80.save_nvram_plist.local?
    place 20.mount_ESP.local to /etc/rc.boot.d place 80.save_nvram_plist.local to /etc/rc.shutdown.d Reboot to see change. 
     
    Here's the result after using my version 80.save_nvram_plist.local
    Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Try the following attachment @gujiangjiang @tluck @Sherlock @Slice 
    syscl_save_nvram.zip
     
    I have successfully tested on XPS 13 9350 Skylake.
     
    Best wishes,
    syscl
  3. Like
    syscl got a reaction from Slice in Clover Problems and Solutions   
    Hi all, finally settled down and figured out why we cannot save/dump the nvram.plist to ESP. Let me explain then show my fix.
     
    First I noticed the following piece of message from the rc.shutdown.log(my version of 80.save_nvram_plist.local)
    Found EFI disk0s1 Mount filesystem msdos kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/msdosfs.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/msdosfs.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled. /System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled. mount_msdos: msdos filesystem is not available mount_hfs: Invalid argument kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/exfat.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/exfat.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/exfat.kext - (libkern/kext) function disabled. /System/Library/Extensions/exfat.kext failed to load - (libkern/kext) function disabled. mount_exfat: exfat filesystem is not available >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local r-- 1 root wheel 2190 Jan 2 13:52 /Volumes/EFI01/nvram.plist The problem is: at the shutdown stage, copious amount of system services will be closed, we are again in a very limited situation: we cannot use diskutil or mount at this stage to mount even a single ESP. 
     
    And now we can explain why r3974's 80.save_nvram_plist.local partly work:
    msdosfs.kext and exfat.kext aren't loaded every time we boot macOS If we by chance mount the ESP(Fat32 or exFat), then system will load msdosfs.kext and exFat.kext, that's why we will see the script partly works Another problem is that Jrs and Taylan's 80.save_nvram_plist.local has copious amount of redundant code, unclear logic, thus I rewrite all of the 80.save_nvram_plist.local myself. Pairing with the touched version of 20.mount_ESP.local(force load msdosfs.kext and exfat.kext during startup), now nvram can be saved in EFI/ as expected.
     
    Compared to Jrs and Taylan's script, my version of 80.save_nvram_plist.local has the following advantages
    clean steps and logic remove redundant operations(we should operate fast at the shutdown stage) dump nvram.plist to all the EFI partitions if possible, and yes, ensure uniqueness of each mounted EFI use EmuVariablePresent to judge if we need to dump NVRAM if mount ESP failed(very possible disk0s1 damage) then dump NVRAM to / (just in case) @Sherlock's version only dump the NVRAM to /, but doesn't really solve the problem. My version of the script not only fix the nvram dump issue but also consider EFI cannot mount case ...  
    How to use my 80.save_nvram_plist.local?
    place 20.mount_ESP.local to /etc/rc.boot.d place 80.save_nvram_plist.local to /etc/rc.shutdown.d Reboot to see change. 
     
    Here's the result after using my version 80.save_nvram_plist.local
    Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Try the following attachment @gujiangjiang @tluck @Sherlock @Slice 
    syscl_save_nvram.zip
     
    I have successfully tested on XPS 13 9350 Skylake.
     
    Best wishes,
    syscl
  4. Like
    syscl got a reaction from Slice in Clover Problems and Solutions   
    Hi all, finally settled down and figured out why we cannot save/dump the nvram.plist to ESP. Let me explain then show my fix.
     
    First I noticed the following piece of message from the rc.shutdown.log(my version of 80.save_nvram_plist.local)
    Found EFI disk0s1 Mount filesystem msdos kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/msdosfs.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/msdosfs.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled. /System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled. mount_msdos: msdos filesystem is not available mount_hfs: Invalid argument kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/exfat.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/exfat.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/exfat.kext - (libkern/kext) function disabled. /System/Library/Extensions/exfat.kext failed to load - (libkern/kext) function disabled. mount_exfat: exfat filesystem is not available >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local r-- 1 root wheel 2190 Jan 2 13:52 /Volumes/EFI01/nvram.plist The problem is: at the shutdown stage, copious amount of system services will be closed, we are again in a very limited situation: we cannot use diskutil or mount at this stage to mount even a single ESP. 
     
    And now we can explain why r3974's 80.save_nvram_plist.local partly work:
    msdosfs.kext and exfat.kext aren't loaded every time we boot macOS If we by chance mount the ESP(Fat32 or exFat), then system will load msdosfs.kext and exFat.kext, that's why we will see the script partly works Another problem is that Jrs and Taylan's 80.save_nvram_plist.local has copious amount of redundant code, unclear logic, thus I rewrite all of the 80.save_nvram_plist.local myself. Pairing with the touched version of 20.mount_ESP.local(force load msdosfs.kext and exfat.kext during startup), now nvram can be saved in EFI/ as expected.
     
    Compared to Jrs and Taylan's script, my version of 80.save_nvram_plist.local has the following advantages
    clean steps and logic remove redundant operations(we should operate fast at the shutdown stage) dump nvram.plist to all the EFI partitions if possible, and yes, ensure uniqueness of each mounted EFI use EmuVariablePresent to judge if we need to dump NVRAM if mount ESP failed(very possible disk0s1 damage) then dump NVRAM to / (just in case) @Sherlock's version only dump the NVRAM to /, but doesn't really solve the problem. My version of the script not only fix the nvram dump issue but also consider EFI cannot mount case ...  
    How to use my 80.save_nvram_plist.local?
    place 20.mount_ESP.local to /etc/rc.boot.d place 80.save_nvram_plist.local to /etc/rc.shutdown.d Reboot to see change. 
     
    Here's the result after using my version 80.save_nvram_plist.local
    Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Try the following attachment @gujiangjiang @tluck @Sherlock @Slice 
    syscl_save_nvram.zip
     
    I have successfully tested on XPS 13 9350 Skylake.
     
    Best wishes,
    syscl
  5. Like
    syscl got a reaction from Sherlocks in Clover Problems and Solutions   
    Give me 1 sec...
     
    syscl
    I double check your script and the latest one with the following step:
    - Remove nvram.plist on / and EFI/
    - Remove /etc/rc.shutdown.d/*
    - Reboot
    - Copy your 80.save_nvram_plist.local under /etc/rc.shutdown.d/
    - Ensure there's no nvram.plist in / and EFI/ in my case, there's no new nvram.plist being genreated 
    - Reboot
    - Set brightness to minimal(almost invisible) 
    - Reboot 
    - Lowest brightness are loaded during boot
    - Reboot again to ensure
    - Lowest brightness is loaded again
    - There's only /nvram.plist being generated
    - Set brightness to maximum then reboot
    - Highest brightness is loaded during boot
    - Reboot again to ensue
    - Highest brightness is loaded again
     
    Then, I remove your script, remove /nvram.plist
    - Reboot(brightness set to default automatically by IntelBacklight)
    - Install official r3974's 80.save_nvram_plist.local 
    - Reboot
    - Set brightness to lowest
    - Reboot
    - Lowest brightness is loaded correctly
    - Reboot again to ensure
    - Lowest brightness
    - Set brightness to maximum
    - Reboot
    - Max brightness is loaded and /nvram.plist occurs but there's no nvram.plist in EFI/ 
    - Reboot
    - Max brightness still no nvram.plist in EFI/ this time
     
    A brief conclusion, both work as expect. But, the r3974's script behaves somewhat weird: 
    - First time I installed it, nvram.plist will be in both / and EFI/
    - Second time when I removed Sherlock's script then install r3974's script, there's no nvram.plist being generated in EFI/
     
    I have to see what's wrong with the latest script.
     
    syscl
  6. Like
    syscl got a reaction from tluck in [GUIDE] Fix Skylake HDMI/DP Output   
    Well it's been a while I search to fix the issue below

    Note, there's no HDMI / DisplayPort Output in the screenshot above, even though you correct the port 0105, port 0204, port 0306 in AppleIntelSKLGraphicsFramebuffer.kext correctly.
     
     
    The problem lies in the AppleHDA(assume you are familiar with the basic concept to patch the AppleHDA and you already have a working AppleHDA), then what we have to do is the following
    Uncompress the layoutXXX.xml.zlib Open layoutXXX.xml you just uncompress Add PublishHDMI_DP as a Boolean type in Root/PathMapRef, value is True, like the below picture
    Save and compress the file back to layoutXXX.xml.zlib Copy to the place resource/ under your dummyHDA Reboot to see change  
    As a proof, please see the screenshot below

     
    Note: if you cite my work, please don't forget to add credit to syscl/me, since it took me time to figure out the solution. Thus your credit will make me feel my work do help others! Thank you!
     
    ​Good luck,
    syscl
  7. Like
    syscl got a reaction from Sherlocks in Clover Problems and Solutions   
    Give me 1 sec...
     
    syscl
    I double check your script and the latest one with the following step:
    - Remove nvram.plist on / and EFI/
    - Remove /etc/rc.shutdown.d/*
    - Reboot
    - Copy your 80.save_nvram_plist.local under /etc/rc.shutdown.d/
    - Ensure there's no nvram.plist in / and EFI/ in my case, there's no new nvram.plist being genreated 
    - Reboot
    - Set brightness to minimal(almost invisible) 
    - Reboot 
    - Lowest brightness are loaded during boot
    - Reboot again to ensure
    - Lowest brightness is loaded again
    - There's only /nvram.plist being generated
    - Set brightness to maximum then reboot
    - Highest brightness is loaded during boot
    - Reboot again to ensue
    - Highest brightness is loaded again
     
    Then, I remove your script, remove /nvram.plist
    - Reboot(brightness set to default automatically by IntelBacklight)
    - Install official r3974's 80.save_nvram_plist.local 
    - Reboot
    - Set brightness to lowest
    - Reboot
    - Lowest brightness is loaded correctly
    - Reboot again to ensure
    - Lowest brightness
    - Set brightness to maximum
    - Reboot
    - Max brightness is loaded and /nvram.plist occurs but there's no nvram.plist in EFI/ 
    - Reboot
    - Max brightness still no nvram.plist in EFI/ this time
     
    A brief conclusion, both work as expect. But, the r3974's script behaves somewhat weird: 
    - First time I installed it, nvram.plist will be in both / and EFI/
    - Second time when I removed Sherlock's script then install r3974's script, there's no nvram.plist being generated in EFI/
     
    I have to see what's wrong with the latest script.
     
    syscl
  8. Like
    syscl got a reaction from wmchris in [GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation   
    It's sad to see such a good thread being banned in tony. But the luckiest thing I saw is you pick up all this again and startup again!
     
    Thanks for your dedication and we all can make XPS Skylake better than ever!
     
    All the best,
    syscl
  9. Like
    syscl got a reaction from wmchris in [GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation   
    It's sad to see such a good thread being banned in tony. But the luckiest thing I saw is you pick up all this again and startup again!
     
    Thanks for your dedication and we all can make XPS Skylake better than ever!
     
    All the best,
    syscl
  10. Like
    syscl got a reaction from gujiangjiang in Clover Problems and Solutions   
    Another NVRAM related bug posted by @gujiangjiang is that once we use EmuVariableUefi-64.efi, the default Boot Volume = Last Boot Volume has no effect. 
     
    Do you encounter this?
     
    syscl
  11. Like
    syscl reacted to Download-Fritz in Clover Problems and Solutions   
    That is a known bug, but after ExitBS will still work. Just overwrite the function, call the original and then save ProductName to NV
  12. Like
    syscl got a reaction from gujiangjiang in Clover Problems and Solutions   
    Thanks @Download-Fritz, is there some functions can write ProductName after ExitBS? I noticed that macOS failed to write to NV after aptiofix2drv/aptiofixdrv return. It's not the aptiofix2drv's bug, it's more like macOS failed to write information to NV on Skylake model. 
     
    Thanks in advance,
    syscl
  13. Like
    syscl reacted to Download-Fritz in Clover Problems and Solutions   
    Check ProductName after ExitBS, so write to NV once it returned...
  14. Like
    syscl got a reaction from gujiangjiang in Clover Problems and Solutions   
    @Slice, 
     
    I added this piece of code at the OnExitBootService()
    SMBIOS_TABLE_ENTRY_POINT *gBSMBIOS; // get bios smbios table EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID*)&gBSMBIOS); egSaveFile(NULL, L"EFI\\CLOVER\\misc\\exitsmbios.bin", (UINT8*)(UINTN)gBSMBIOS, gBSMBIOS->TableLength); And exitsmbios.bin is the same as smbios.bin, name is correct. Thus I added print in DataHubCpu.c 
    if (!EFI_ERROR(Status)) { ProductName = AllocateZeroPool(64); AsciiStrToUnicodeStr(gSettings.ProductName, ProductName); DBG("DataHubCpu: ProductName: %a\n", gSettings.ProductName); ... LogDataHub(&gEfiMiscSubClassGuid, L"Model", ProductName, (UINT32)StrSize(ProductName)); DBG("DataHubCpu: ProductName from efi misc: %s\n", ProductName); ... Still correct productName. Here's the boot.log and smbios.bin
    bootlog_and_smbios.zip
     
    So, OnBootExitService() and DataHubDxe indicates during Clover's progress, SMBIOSStructureType1 table hasn't been touched. I double the issue is when macOS access the SMBIOSStructureType1 table then trigger some firmware's limitation or bugs. Is it possible to emulate SMBIOS as legacy Clover? Or as I said, once OnBootExitService() return, allocate a new buffer and remap SMBIOS Table Type1 to bypass the problem SMBIOS?
     
    Wait for your reply,
    syscl
     
  15. Like
    syscl got a reaction from gujiangjiang in Clover Problems and Solutions   
    @Slice, thanks for the clarification. So, we can later on repatched the SMBIOSStructureType1 buffer to correct this bug? Or can we create a new buffer with the protected property for the product name in SMBIOS_TABLE_TYPE1?
  16. Like
    syscl got a reaction from nms in Clover Problems and Solutions   
    @Slice, I just added 
    SMBIOS_TABLE_ENTRY_POINT *gBSMBIOS; // get bios smbios table EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID*)&gBSMBIOS); egSaveFile(NULL, L"EFI\\CLOVER\\misc\\efismbios.bin", (UINT8*)(UINTN)gBSMBIOS, SmbiosEpsNew->TableLength); at the end of smbios.c and compare smbios.bin and efismbios.bin which are the same. I double my operation is incorrect. 
     
    I just find the definition of InstallConfigurationTable(EFI_GUID* Guid, VOID* Table), but cannot find how this function works. I noticed there's InstallConfigurationTable.c, but what I found in that file is this
    if (Table != NULL) { // // If Table is not NULL, then this is a modify operation. // Modify the table enty and return. // ConfigurationTable[Index].VendorTable = Table; return EFI_SUCCESS; } It just make the ConfigurationTable with the &Guid points to the patched SmbiosEpsNew right? I am not sure, but I want to figure out this issue. Please shine some light on this, thanks.
     
    Thanks in advance,
    syscl
  17. Like
    syscl got a reaction from nms in Clover Problems and Solutions   
    @Slice, I just added 
    SMBIOS_TABLE_ENTRY_POINT *gBSMBIOS; // get bios smbios table EfiGetSystemConfigurationTable(&gEfiSmbiosTableGuid, (VOID*)&gBSMBIOS); egSaveFile(NULL, L"EFI\\CLOVER\\misc\\efismbios.bin", (UINT8*)(UINTN)gBSMBIOS, SmbiosEpsNew->TableLength); at the end of smbios.c and compare smbios.bin and efismbios.bin which are the same. I double my operation is incorrect. 
     
    I just find the definition of InstallConfigurationTable(EFI_GUID* Guid, VOID* Table), but cannot find how this function works. I noticed there's InstallConfigurationTable.c, but what I found in that file is this
    if (Table != NULL) { // // If Table is not NULL, then this is a modify operation. // Modify the table enty and return. // ConfigurationTable[Index].VendorTable = Table; return EFI_SUCCESS; } It just make the ConfigurationTable with the &Guid points to the patched SmbiosEpsNew right? I am not sure, but I want to figure out this issue. Please shine some light on this, thanks.
     
    Thanks in advance,
    syscl
  18. Like
    syscl reacted to Slice in Clover Problems and Solutions   
    I think we can add print to screen some strings from smbios at the OnExitBootService()
  19. Like
    syscl got a reaction from gujiangjiang in Clover Problems and Solutions   
    @Slice
    Here you go~
     
    smbios.bin.zip
     
    syscl
  20. Like
    syscl got a reaction from genzai in Clover Problems and Solutions   
    Well, I've built a new kernel extension FakeSMBIOS to spoof the SMBIOS for macOS during startup. 
     
    Here's the source code of FakeSMBIOS https://github.com/syscl/FakeSMBIOS
     
    I know there's still long way to go(still some bugs), but by spoofing the SMBIOS, some bugs fixed, one of the example is the Boot Camp Assistant

     
    Wish there will be more testers and better solution
     
    Here's the prebuilt kext. FakeSMBIOS can be placed Clover to inject..
    FakeSMBIOS.kext.zip
     
    credit also Voodoo project
     
     
    syscl
  21. Like
    syscl got a reaction from genzai in Clover Problems and Solutions   
    Well, I've built a new kernel extension FakeSMBIOS to spoof the SMBIOS for macOS during startup. 
     
    Here's the source code of FakeSMBIOS https://github.com/syscl/FakeSMBIOS
     
    I know there's still long way to go(still some bugs), but by spoofing the SMBIOS, some bugs fixed, one of the example is the Boot Camp Assistant

     
    Wish there will be more testers and better solution
     
    Here's the prebuilt kext. FakeSMBIOS can be placed Clover to inject..
    FakeSMBIOS.kext.zip
     
    credit also Voodoo project
     
     
    syscl
  22. Like
    syscl reacted to Slice in Clover Problems and Solutions   
    Yes, this is the information!

  23. Like
    syscl reacted to gujiangjiang in Clover Problems and Solutions   
    Hello Slice.
     
    Here are the full DarwinDumper report and with out BIOS and HTML.
     
    Thanks for your hard work.
    DarwinDumper_3.0.2_18.12_20.06.52_MacBookPro1_AMI_X64_3961_Sierra_16C67_gujiangjiang.zip
  24. Like
    syscl reacted to gujiangjiang in Cloud Clover Editor (CCE) [Clover, Ozmosis, Chameleon, OpenCore]   
    First,i know you mean.
     
    I want to say SMC Rev is nothing with our hackintosh but it can make our hackintosh looks more comfortable,aren't they?just like you dress beautiful clothes.
     
    But the BootROM is related to our hackintosh because if BootROM is not updated,the macOS will download the firmware automaticly to "EFI/Apple/Firmware" and will also download if you delete it.so the BootROM is needed for our hackintosh and the smc rev can make our hackintosh more like a native macOS and more comfortable,so i suggest to update it.
     
    So,please stop it.
     
    Thanks.
  25. Like
    syscl reacted to gujiangjiang in Clover Problems and Solutions   
    Hello,slice,here is my SMBIOS.txt by DarwinDumper.
    Handle 0x0001, DMI type 1, 27 bytes 0000: 01 1b 01 00 01 02 05 04 44 45 4c 4c 31 00 10 36 0010: 80 44 b7 c0 4f 52 37 32 06 03 06 System Information Manufacturer: Apple Inc. Product Name: MacBookPro1 Version: 1.0 Serial Number: C02SHAAUGTDY UUID: 44454C4C-3100-1036-8044-B7C04F523732 Wake-up Type: Power Switch SKU Number: Mac-A5C67F7 Family: MacBook Pro Handle 0x0002, DMI type 2, 16 bytes 0000: 02 10 02 00 01 02 03 04 00 09 05 03 00 0a 00 00 0010: Base Board Information Manufacturer: Apple Inc. Product Name: Mac-A5C67F76ED83108C Version: MacBookPro13,3 Serial Number: C02SHAAUGTDYD2F59 Asset Tag: Not Specified Features: Board is a hosting board Board is replaceable Location In Chassis: Part Component Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 My laptop is XPS 15 9550 by DELL
    SMBIOS.txt
×