Jump to content

apianti

Developers
  • Content Count

    1,227
  • Joined

  • Last visited

  • Days Won

    28

Everything posted by apianti

  1. Disable both xcpm patches. Try to boot, if you can't, enable only the boot strap patch. Then if still not booting, only the other patch. EDIT: You also probably need to drop some of your original tables, they may conflict.
  2. Are these the only messages? Those messages mean your SSDT is incorrect. If I had to guess, you should decompile the SSDT, and you will have CP00 through CP07, you should change CP04 through CP07 to CP08 to CP0B.
  3. apianti

    ApfsDriverLoader and multiple APFS containers

    Okay, this is what I thought but it doesn't solve the issue of if you can't boot and don't already have things in place to do such a thing... I have no interest in TDM really either (although it gets asked about a lot) but I'm still surprised one of you hasn't reversed the TDM module(s).
  4. No, don't do that with the AppleIntelCPUPowerManagement.kext. Basically you are all using the same solutions but incorrectly. I have given you the two and only cases that will give you working power management. Whoever posted that pick with the W-2150b, you don't need all those patches is the problem. And you need an SSDT.
  5. apianti

    Clover General discussion

    Clover wiki has been migrated back to sourceforge to try to keep it as up to date as possible, and is now live. Please use this wiki as official from now on. https://sourceforge.net/p/cloverefiboot/wiki/Home/ EDIT: You may comment fixes and suggestions to a page, but they are subject to moderation by admin (basically slice and I) unless you are a team member (but ultimately still manually moderated if necessary). EDIT2: Forgot to give a huge shout out to @arsradu for migrating and updating the wiki. Thanks!
  6. apianti

    ApfsDriverLoader and multiple APFS containers

    Oh, that's cool. How would this be implemented? Like you mean the recovery disk image would need to be on an accessible volume? Or that the image will be downloaded? Also, completely unrelated but I'm surprised one of you hasn't attempted to determine the protocol for target disk mode.
  7. No, I am pretty sure those are all part of the issue, as it should be making difference choices for those CPUs compared to the other Skylake CPUs. There is already an issue open for the cpu-type suggestion, I'm guessing what you have is correct if it says the correct CPU for you in about this mac. It looks like that other message is also incorrect. I think that SSDT should work.
  8. apianti

    ApfsDriverLoader and multiple APFS containers

    Yes, but if something happens to the disk and it is corrupted or the user does make a mistake. If the user did this on a mac, they can enter internet recovery from firmware. This is not the case without apple firmware.
  9. I can't figure out a place to actually open an issue for the AppleSupportPkg so I am posting here hoping @vit9696, @Download-Fritz, @savvas, @vandroiy2012, or @TheRacerMaster with see this and resolve an issue. There appears to be a mistake in the connection of the apfs.efi loaded from an APFS container and which driver's binding will actually be used to connect. I would point you to this call: https://github.com/acidanthera/AppleSupportPkg/blob/master/Platform/ApfsDriverLoader/ApfsDriverLoader.c#L195 The second parameter is passed as NULL, so this attempts to use every installed EFI_DRIVER_BINDING_PROTOCOL interface. When you have multiple APFS containers, which this driver will then load multiple apfs.efi drivers, which driver binding is used to connect the controller? Shouldn't this be supplied in the call? Otherwise, this does not seem to ensure connection with the driver that was loaded from that container and the controller handle for the container but whichever apfs.efi's EFI_DRIVER_BINDING_PROTOCOL gets the first chance at connecting. Instead, there should be an enumeration of all EFI_DRIVER_BINDING_PROTOCOL interfaces, and every one that has EFI_DRIVER_BINDING_PROTOCOL->ImageHandle the same as the driver's image handle, the binding's handle should be put in a NULL terminated list and passed as the second parameter. Also, is there a way to maybe cause a fallback for APFS containers that either have no apfs.efi embedded or the driver fails check? Like determining which is the latest and after connecting each controller it was connected to, go through and use that driver to connect any controllers that failed? Or embedding the latest apfs.efi in the driver itself that is used when the driver fails being loaded from the APFS container? EDIT: The binding's handle should go in the list not the image's.
  10. Look at the script readme and change the parameters you need. And let him know in your issue, with all these outcomes as well. To get the output from all the commands you can use: command | tee -a file.txt
  11. apianti

    ApfsDriverLoader and multiple APFS containers

    Cool, thanks @vit9696. As to the fallback, although an obvious edge case that he caused, I just had a user with an issue here that was caused by this, he had to revert to using apfs.efi directly instead:
  12. Oh, when I posted my reply the middle of my post was cut out, so there was like a sentence and a half missing. I was just listing the reason I edited the post. You need these two things to generate the SSDT and freqency vectors: https://github.com/Piker-Alpha/ssdtPRGen.sh https://github.com/Piker-Alpha/freqVectorsEdit.sh
  13. apianti

    Clover General discussion

    Yeah, just compare the two binary tables together in a hex editor and that will give you the patch, just make sure that you search the original table with the source patch to make sure it doesn't repeat or you need to add some more of the data from around the source.
  14. Yeah, there may be, you'll have to look at how the bootstrap patch works in order to understand it and which model to choose. I have no idea which models are which, someone needs to disassemble the kernel, find the table, and determine which would be the best for those cpus. And that is expected since it should be using XCPM instead, the problem in that case is you have full throttle? You need freqency vector information in the model board-id plist that one script modifies. EDIT: Part of my response was missing...? EDIT2: Typos, lol.
  15. Yeah, no problem. I wanted to get down to the lower level as much as possible without having the actual hardware. I think either way of patching I suggested will work, so whichever you find easier is probably the better choice and that's probably fakecpuid + patch _xcpm_pkg_scope_msrs. I think you guys are having a misnomer about non-native processor, regardless of whether or not you have the exact same hardware in a mac (this is entirely possible to achieve for some mac models, I have this for iMac12,2), you still need patches because even if the problem is panic/crash (or even unsupported hardware) the cause is always software and the only thing that can be done is to patch it. The main thing is that apple firmware and actually UEFI compliant firmware for PCs are just different and apple expects that certain things will always be, because that's how they made it... I think it's actually firmware issues and OS software issues, I don't think the CPU really plays much of a role other than having an id that seems to cause an issue for the OS. Since the bootstrap patch worked for you guys I would think that the probably is strictly related to either xcpm bootstrap jump is wrong for that id like it was for the original cpu it was made for, it may be possible to find a correct bootstrap patch to have it corrected. Or the only other cause really is the state of the devices, which is set by the firmware.
  16. Nah, I think he's incorrect. The reason being that the W-2135 is only 6(12) cores, where the W-2140b and W-2145 are 8(16), and the W-2150b and W-2155 are 10(20). However, I would expect that the W-2145/W-2155 would be better than the W-2140b/W-2150b respectively or why not name the cpu the same (or to even differentiate that it was mac-only with just the b)? So the higher clock speed for the W-2145 and W-2155 makes sense, they have similar turbo freqencies (also with the W-2135 but it has less cores, specifically the third number multiplied by 2 is the core count). Comparing the W-2170b and W-2175, or the W-2191b and W-2195, they are the exact same it appears (though I have a feeling they are not because again why would they make two different versions of the same chip with just a different identifier?). The models then all get slower as the identifier increases as the TDP stays the same (140W) but the core counts increase, meaning there is less power for each core. The thing to note is that all of the mac-only models were announced in june of 2017 when they introduced the imacpro, but weren't released until the imacpros actually came out in december. The other models were announced and released all on the same day in august 2017. This is actually probably a misleading thing though, as most likely the mac-only models were engineered first, much sooner than june and shipped to apple because they then needed to build the imacpro, which needed to be ready by june (because that's when they announced and showed it) but weren't actually released until december. So I think they had the chips already at that point in june, putting the manufacture date at the very beginning of 2017 or end of 2016. Why does intel then wait until august 2017 to announce the consumer available w series, only as the series is released? They probably weren't engineered until early-mid 2017. I would think that the mac-only models are actually probably the specs apple wanted and the others are what intel thought consumers would buy at specific price points after having engineered the models for apple, not wanting to waste a process as they could sell more commercially than to apple alone (not to mention they probably get more money from consumers than from apple per cpu). You can also look that they did not release any W-216X or W-218X cpus (which would be 12 and 16 cores and no other models in the W series have those core counts). Why also name the one randomly W-2191b when the other mac-only models end in 0? Maybe they intended to release those models but ended up changing their minds and there would have been a W-2190 which would be slower than the W-2191b (or maybe they still may release them). After reading what he says in his post, he even appears to state a better reason than heat for the difference, they actually are different and have integrated graphics. Then he states the integrated graphics are disabled by the OS, more implication here on my part, but I imagine this is what is causing the issues. On a mac, the integrated graphics are initialized by the firmware but then disabled by the OS, this is perfectly acceptable. On non macs, the integrated graphics are not initialized but then the OS tries to disable the integrated graphics, this is an issue, especially when there is no integrated graphics (not using a mac-only model). The firmware for C422 probably doesn't even attempt to initialized integrated graphics because well it doesn't actually support integrated graphics (https://ark.intel.com/content/www/us/en/ark/products/126691/intel-c422-chipset.html). This is an interesting read (https://www.pcgamer.com/heres-what-you-need-to-know-about-kaby-lake-x/), maybe the mac-only models are actually re-purposed skylake cores with integrated graphics as well that can't actually work because of the C422 chipset not supporting integrated graphics. I wonder if the other models are actually a different process then or not... Lots of information here, and some speculation..... I think you have discovered you have two ways to configure to get working system and power management with the w series, fakecpuid + patch _xcpm_pkg_scope_msrs, or bootstrap patch + frequency vectors. EDIT: Oops, I meant skylake for the w series, not kaby lake, lol.
  17. Ok so I see from your log you are using ApfsDriverLoader, which seems that there is no embedded Apfs.efi driver in the APFS container on the USB disk which means that this is caused by an issue with that driver specifically implied by point three: ApfsDriverLoader Open source apfs.efi loader based on reverse-engineered Apple's ApfsJumpStart driver. It chain loads the apfs.efi driver that is already embedded in the APFS container from this container. Loads apfs.efi from APFS container located on the block device. Apfs driver verbose logging suppressed. Version system: connects each apfs.efi to the device from which it was retrieved. Embedded signature verification of chainloaded apfs.efi driver, what prevents possible implant injection. Therefore please replace ApfsDriverLoader with /usr/standalone/i386/apfs.efi from either the installer or your current system volume. EDIT: I think that you have to mount the base image from the installer, unsure. If they are different OS versions, use the one from the installer.
  18. Actually, there is something wrong with the disk. It is not actually being used as APFS, otherwise you would have entries like these: 2:595 0:004 - [06]: Volume: PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0)\HD(2,GPT,F4185928-69E8-451B-BBAA-944E0F891E29,0x64028,0xEE18260) 2:603 0:007 Result of bootcode detection: bootable unknown (legacy) 2:606 0:003 - [07]: Volume: PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0)\HD(2,GPT,F4185928-69E8-451B-BBAA-944E0F891E29,0x64028,0xEE18260)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,F5074605EE67754F9CC4A5345DF1B3E5) 2:615 0:008 hiding this volume 2:618 0:003 - [08]: Volume: PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0)\HD(2,GPT,F4185928-69E8-451B-BBAA-944E0F891E29,0x64028,0xEE18260)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,716C107335260F3B857082F63F730E86) 2:625 0:006 - [09]: Volume: PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0)\HD(2,GPT,F4185928-69E8-451B-BBAA-944E0F891E29,0x64028,0xEE18260)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,C5809751584BBF4AB74D713E1EC04A4A) 2:634 0:008 hiding this volume 2:637 0:003 - [10]: Volume: PciRoot(0x0)\Pci(0x1F,0x2)\Sata(0x0,0xFFFF,0x0)\HD(2,GPT,F4185928-69E8-451B-BBAA-944E0F891E29,0x64028,0xEE18260)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,3BF72D2BDC8B4341A12BE15CE3606967) Notice the vendor media extension on the end of the device path for the volumes? That's where the information is accessible, the other from above is just seen as a raw partition because it's never scanned: 2:957 0:005 === [ ScanLoader ] ======================================== 3:096 0:139 - [01]: 'EFI' 3:105 0:008 AddLoaderEntry for Volume Name=EFI 3:108 0:003 skipped because entry is hidden 3:112 0:003 - [05]: 'EFI' 3:121 0:009 AddLoaderEntry for Volume Name=EFI 3:124 0:003 skipped because entry is hidden 3:128 0:003 - [07]: 'Preboot', hidden 3:134 0:006 - [08]: 'ToshibaQ128' 3:199 0:064 AddLoaderEntry for Volume Name=ToshibaQ128 3:214 0:014 Check if volume Is Hibernated: 3:217 0:003 Check sleep image 'by signature': 3:239 0:021 read prefs \Library\Preferences\com.apple.PowerManagement.plist status=Success 3:242 0:003 using default sleep image name = \private\var\vm\sleepimage 3:259 0:017 sleepimage not found -> Not Found 3:262 0:003 hibernated: no - sign 3:270 0:007 - [09]: 'Recovery', hidden 3:276 0:006 - [10]: 'VM' Notice it skips 0, 2, 3, 4, and 6? Those are all the volumes that do not have a file system procotol so they cannot be searched. 2 is your APFS container, it should then have at least two volumes with vendor media extensions, the installer and the Preboot. This means that APFS is not loaded for that disk. Are you using Apfs.efi or ApfsDriverLoader.efi? Also see here about install and Preboot, https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/entry_scan/loader.c#l1162, otherwise, https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/entry_scan/loader.c#l1093. EDIT: I forgot to answer about the Preboot, I wanted to see if it would detect boot.efi from the preboot, which would also start the installer/system. Then I realized that the problem is with the disk and APFS when I saw what I posted from your log again. I was actually in the middle of class, posting from my phone so I didn't have a bunch of time to look at what was happening. But as soon as I got home, I saw immediately that I am an idiot.
  19. Thanks @Slice, wouldn't have done anything without you doing so much though...
  20. apianti

    Clover General discussion

    No, the bootstrap patch is not a fakeid unless you are using a patch for a different cpu. As far as I know the boot strap patch was designed for one of the other previous unsupported cpus and it probably wasn't modified since for other cpus since. Not possible, there's patches that happen without you knowing and they must. Adding more isn't a big thing really....
  21. Yes the difference is the firmware. EDIT: I realize that you CAN buy those CPUs outside the supply chain, but I was trying to say that they are most likely not similar enough for the firmware to know what to do with extra stuff I'm assuming is there or why did they have special mac-only models made when it would have been cheaper to source already made CPUs?
  22. apianti

    Clover General discussion

    I was just speculating because that's what _xcpm_pkg_scope_msrs does, and you guys are getting it working by changing the id and skipping the call to that function. It's possible to not setup a device correctly from the firmware if it's not known that it needs setup in a certain way. I'm sorry, I meant the bootstrap patch, not the other. You posted that you used the bootstrap patch and then were able to boot but had full throttle, you had the correct situation then and you just need frequency vectors for your cpu to get pm.
  23. You are not being serious right? You already answered yourself.... ......? There's no need to antagonize him for asking a question about something you personally wouldn't do. It would be fine to joke if you were helping or adding to the conversation but you're just looking like a jerk here, man.
  24. apianti

    Clover General discussion

    Can you not with your original id and the patch for scope_msrs? Did you not post two different pics in the other topic, one with pm and one without? I thought the difference was you just didn't use fakeid. What exactly happens when you boot with your original id and the patch?
  25. Yeah that's the one. I don't understand what you mean, you can't get the mac-only model for purchase as a regular customer and imacpros only have those models....
×