Jump to content

Zenith432

Developers
  • Content Count

    927
  • Joined

  • Last visited

  • Days Won

    19

Zenith432 last won the day on October 17

Zenith432 had the most liked content!

1 Follower

About Zenith432

  • Rank
    InsanelyMac Legend

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Zenith432

    Clover problems report & features request

    @Slice: When I boot the Catalina installer from a USB stick, and turn on debug, it sometimes prints the line DBG_RT(Entry, "Kernel not found at 0x%p - skipping patches!", KernelData); found in kernel_patcher.c and skips the kext injection and patching. It's the reason that inject Detect feature was not working for me. It appears to happen at random. I'm using AptioMemoryFix.efi and no slide= parameter in Arguments. Any idea why this is happening? Doesn't seem to happen from sata boot. Edit: Setting slide=0 appears to prevent this - couldn't reproduce it again afterwards.
  2. Zenith432

    Clover problems report & features request

    I found the problem. It's the boot-arg HDMI_2_0_Disable=1. Apple have somehow f**ked this feature-disabling flag up so that when it's used, AppleIntelCFLGraphicsFramebuffer freezes. If I remove it - instead using WhateverGreen or a patch to suppress ComputeLaneCount - AppleIntelCFLGraphicsFramebuffer goes back to work.
  3. Zenith432

    Clover problems report & features request

    Clover auto-injects ig-platform-id 0x3E920000 for device id 0x3e91, and it worked under Mojave which I believe has nearly the same table, and the entry for 0x3E920000 is the same parameters. I don't set ig-platform-id manually in config.plist. I've now installed the system (to a different volume, not over Mojave) so I can have more flexibility rebuilding prelinkedkernel with kextcache. I've tried both with and without WhateverGreen/Lilu and AppleIntelCFLGraphicsFramebuffer freezes. Last time I had a freeze was in ComputeLaneCount, which is also overcome by setting boot-arg HDMI_2_0_Disable=1, but that doesn't work either. It's a new freeze. So now I have Catalina installation, but it onlly boots if I set boot-arg -DisableIOFB to suppress CFL and run IONDRVFramebuffer instead. Of course, the graphics performance is sh*t this way.
  4. Zenith432

    WhatEverGreen Support Topic

    It's a different issue then. I'm using FakeSMC 3.5.2 from HWSensors3 and it works WhateverGreen 1.3.3 + Lilu 1.3.8 , AppleIntelCFLGraphicsFramebuffer for 10.15 freezes. I have now installed the system and all the kexts with kextcache to have more flexibility - and it freezes.
  5. Zenith432

    Clover problems report & features request

    @chris1111: You're right, it's just the Detect feature that is broken. Setting it to true makes the injection. Now I have a bigger problem which is that AppleIntelCFLGraphicsFramebuffer hangs even with current Lilu/WhateverGreen injected. The Device is 0x3e91 (UHD 630). I have to disable the kext with bootarg -DisableIOFB. This means even if I install Catalina I won't have AppleIntelCFLGraphicsFramebuffer working.
  6. Zenith432

    Clover problems report & features request

    kext injection does not work in Catalina I have InjectKexts set to Detect in config.plist Have FakeSMC and several other including Lilu/WhateverGreen in kexts/Other I try to boot Catalina installer (with its shipped prelinkedkernel). When I get to the menus, I open Terminal, then run kextstat (from Mojave volume /usr/sbin), and the injected kexts are not there! All other kexts seem to be ok. I try to boot Mojave Recovery partition (with its shipped prelinkedkernel). Get to menus, open Terminal, run kextstat, and the injected kexts are there! This is a problem because I need WhateverGreen with the shipped prelinkedkernel. PS Clover is release 5096 from github.
  7. Zenith432

    Clover General discussion

    @Slice: There are still problems with Conf/tools_def.txt on github -Wno-unused-but-set-variable was removed from GCC48_X64_CC_FLAGS. It should be added to GCC48_ALL_CC_FLAGS, and removed from RELEASE_GCC48_IA32_CC_FLAGS. -Os -flto should be removed from GCC48_X64_CC_FLAGS. PS: about the crash, I only use GCC-built CloverGUI with UEFI boot, haven't tested legacy Clover in a long time so I don't know if still works.
  8. Zenith432

    Clover General discussion

    @fusion71au: This is not happening on Fedora 30 with gcc 9.2 and binutils 2.31.1. Try a clean build.
  9. Zenith432

    Clover General discussion

    There is somthing wrong with the settings in the github repository In sf.net svn Patches_for_EDK2/Conf/tools_def.txt DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS) -Wno-address -Wno-unused-but-set-variable DEFINE GCC46_X64_CC_FLAGS = DEF(GCC45_X64_CC_FLAGS) -Wno-unused-but-set-variable -mabi=ms So -Wunused-but-set-variable is disabled for all GCC46 and later (including GCC53). In CloverHackyColor tools_def.txt I see this warning disabled for GCC48 ONLY, but not for any other version of GCC RELEASE_GCC48_X64_CC_FLAGS = DEF(GCC48_X64_CC_FLAGS) -Os -Wno-unused-but-set-variable So adding the pragma in the source files to silence the warning should not be necessary. It is tools_def.txt settings for GCC that are not synchronized with sf.net for proper GCC compilation.
  10. Zenith432

    Clover Problems and Solutions

    r5063 was properties-only commit done with svn commit removed svn:executable properties from many source files that are not executable but had them. Changed the svn:mime-type on some files to more accurately reflect their type. If you look at the change on the sf web view of the repository, it doesn't show property changes correctly. To view property changes you have to do 'svn diff' between this revision and its predecessor. When you run 'svn update', if there are any conflicts with your local changes it shows you conflicts when doing 'svn status', and you cannot commit conflicted files again before resolving the conflict. You can commit changed, but unconflicted files. So maybe you committed in r5064 unconflicted files, but still had other conflicted files. r5069 is also properties-only commit to remove svn:eol-style and svn:keywords that were put by accident on new files that I checked in. This was because of some settings I had in my ~/.subversion/config and it turns out git-svn calls svn commands that use defaults from ~/.subversion/config.
  11. Zenith432

    Clover Problems and Solutions

    Are these UDK2018 and EDK2 folders both on same account with same ~/.subversion?? If you can commit from one and not the other then the Clover/.svn folder under EDK2 must have local corruption. It's the only possiblity.
  12. Zenith432

    Clover Problems and Solutions

    FWIW, I commit using svn+ssh:// protocol, and I use private key, not username+password. To use private key, login to sourceforge account on the web, goto account settings->ssh settings and upload your public key. Put your private key in ~/.ssh/id_rsa. AFAIK, it is possible in sshd to block logging in using username+password and allow private-key login only, but you committed 2 days ago and I doubt that's changed. The commits 5065-5070 were done using git svn dcommit or svn commit. Nothing administrative. They're large, but I checked the repository using sourceforge ssh access, and everything appears to be in order. Try cleaning all the files in ~/.subversion/auth to have them recreated. If all that fails, it's a server-side problem so open a ticket with sourceforge tech-support.
  13. Zenith432

    Clover Problems and Solutions

    This command is run on the local repository, and will count the number of local commits, not the number of commits in the remote repository. There is something called shallow clone in git such that git clone --depth=5 will only clone the newest 5 commits and similarly git pull --depth=5 git fetch --depth=5 In edk2 for instance I usually only keep the commits since the last tag.
  14. Zenith432

    Clover Problems and Solutions

    You can get the 7-character short hash for a git object with git describe --always <commit> or git describe --always (acts on HEAD by default) I suggest you tag each release that you publish binaries for, maybe use date as part of the tag to make it unique. Then git describe --tags gives you the tag name attached to the 7-character hash which you can use to identify the published file. Do man git-describe for other options. Another issue: The files Conf/.cache Conf/BuildEnv.sh Conf/target.txt should not be committed to the respository because they have local paths and build options and are generated by various tools. In edk2 these files are not committed, they're .gitignore-d.
×