Roy Jones, it is in the Lilu log. This your log is ok. Please update to the latest build (https://dortania.github.io/bui…strictEvents&viewall=true), this one should fully resolve the need for a boot argument.
Beiträge von vit9696
-
-
Roy Jones non-DEBUG RestrictEvents. Nothing to see. Update to latest master (b9cbe5c12b6bcd330615dcb29954691fb471f336).
ralf. fixed (https://github.com/acidanthera…30615dcb29954691fb471f336). Please confirm.
-
Shaneee, Roy Jones please file a bug in https://github.com/acidanthera/bugtracker/issues. Make sure to use the latest versions (we had a release today). Include hardware info & a DEBUG log by using DEBUG Lilu and RestrictEvents with -liludbgall liludump=60 boot arguments. The debug log will be put to /var/log/Lilu_x.x.x.txt file 60 seconds after booting. Thanks.
-
You do not need to specify revcpu=1 on AMD. It is enabled by default. Enjoy =)
UPD: That may have been broken before https://github.com/acidanthera…398856e55e72dffe0e0d84c5c.
-
I would say we will need to rename VerifyMsrE2 to something like MsrE2Ctl and make it accept arguments like -check (and do what VerifyMsrE2 currently does) and -unlock/-lock (and perform your tool logic). Without the arguments it can possibly have some interactive mode.
A good start will be a PR of this change to OpenCorePkg. Then we could review and bring the changes to the project codestyle and such. For the arguments you can use GetArguments function from Library/OcMiscLib.h.
Thanks a lot!
-
-
Falcon SMC firmware loading is available on X4000~X6000, but it might actually be unused in some(?) drivers. It is very easy to check by adding an OC patch _TF_PhwSIslands_UploadFirmware → 0F 0B for AMDRadeonX****HWLibs.kext. If the firmware is used, the system will not boot. Otherwise it will crash very early. Probably worth checking to be sure, which cards it affects.
-
EDIT: Habe nochmal auf Basis meiner historischen Daten nachgeprüft und nein, "ATY,EFIVersion" war damals nicht by default vorhanden, war aber wohl noch nicht nötig um die SMU Firmware zu laden. D.h. die SMU Firmware wurde immer geladen, auch ohne entsprechendes Property.
Sehen wir uns nun mal die Entdeckung der WEG Entwickler an:
Sieht für mich ganz danach aus als hinge der Bug mit der Lüftersteuerung mit der SMU Firmware zusammen und Apple hat diesen nie behoben. Stattdessen hat Apple einfach das Laden der SMU Firmware für alle PC Karten deaktiviert, was leider in bestimmten Workloads für eine deutlich geringere Leistung sorgt.
vit9696 Do you understand what I wrote here or do I need to translate it? In case you understand, what do you think about my assumption?
Edit: Neue Version 1.2 im Startpost veröffentlicht. Vega 56, 64 und Frontier Support wegen o.g. Gründe gestrichen.
Yeah, I think that makes very good sense to me, sorry for a slow reply. Not sure if it is a bug, could just be some unimplemented feature, but very plausible.
Other than that, I noticed that RadeonBoost gives HBM2 memory bandwidth boost, right? Could you tell us which exact parameter causes the boost? We might be able to track down the reasons behind it. Currently in our view we there are only two relevant parameters:
— PP_WorkLoadPolicyMask
— ATY,EFIVersion / Force_Load_FalconSMUFW
But it will be nice to confirm that we miss nothing. Thanks.
-
vit9696 Very interesting, but how do you explain the better Photoshop performance (pugetbench)? https://forums.macrumors.com/t…st=28377684#post-28377684
Yup, I had the same thought. In specific areas however, there definitely are performance improvements. Some games (Dirt4, Borderlands 3) run notably smoother with my RadeonBoost kext at least on the Radeon VII and also Photoshop seems to benefit as demonstrated on Macrumors.
Edit: Neue Version 1.1 im Startpost. AGPM Injector ist nun direkt in RadeonBoost integriert. matpro64 Check if your Vega64 fans run normal now.
Well, like I said, the two parameters work, others do not as they just seem to be blindly copy-pasted. For Polaris only the policy applies, as it has no SMU. We can retest with this benchmark, but are you sure you have any difference with just the two parameters specified and RadeonBoost?
-
We believe Geekbench fakes its scores. Real world tests like Final Cut or rendering tests (like BaseMark) give more expected results.
-
Thanks for the hint. Actually most of the kext is irrelevant but two parameters. We explored and properly documented them in WEG: https://github.com/acidanthera…55bee00c543630e3a509b4a84
-
— delete VirtualSMC.efi
— AppleSmcIo NO
— AuthRestart YES
-
DSM2 sorry for jumping in, but could you please do clarify why this kind of secrecy is involved in the matter? Is it just that you need some time/will to do a proper write-up for the problem? Or perhaps it is quite a bit complicated and more thought is needed to make it useable by everyone? I believe that we could work it out together =)
Just, I mean, if neither of these, the situation is awkward at least. If you look around, the development community is not hiding their research from others for obvious reasons. Avarice of this kind sounds like a disgrace for everyone involved in macOS community development, including Download-Fritz and myself. Obviously I did not want to offend you in case I misunderstood something.
-
Wichtig zu erwähnen wäre noch das es sich ausschließlich um einen UEFI Bootlaoder handelt -> Legacy Boards mit UEFI support funktioniert damit nicht!
Beispiel hierfür ist das Board MS7728V2 das in meinem Microstar (Medien PC) verbaut ist...
Gruß Mocca55
BIOS booting works with DuetPkg. For now you could grab a compatible Duet on applelife:
-
Hello,
I just took out all calls but calls to the 3 variable handling routines.
I‘ll check, which routines crash, during the day and will post in the evening.I used AppleEFIRuntime only since 10.13, so I can‘t comment on any changes over time. Haven‘t got any older systems installed to be able to check.
PS.
Why do you think any routine would work ?
I'd expect them to be in the same block of memory, so if you have to proxy one, you would have to proxy them all,
If one worked it would be by coincidence and that might turn on you at some point.
The point is that UEFI does not allow you to use global variables in runtime services. Yet AMI does it @_@.
So the point of fixing variable functions is to fix a bug in one of the AMI modules.
While it is terrible that bugs exist in their other modules too, adding preliminary hacks is a bad practice.Looking forward for the function list.
-
Nach einem Neustart bzw. im laufenden Betrieb. Nach einem Wake habe ich nicht getestet.
Das Interface ist selbstgestrickt, AppleEFIRuntime Header Datei aus dem Disassembling soweit Reverse Engineered, dass sie die Funktionen, die mich interessieren enthalten und dann ein Kext mit UserClient geschrieben um sie von einer App aus aufrufen zu können.
Das sind im Wesentlichen die EFI Runtime Services Aufrufe von Get/Set/Next Variable , Get/Set Date, Get/SetWakeup, Reset und GetNextHighMonotonicCount.
Im Moment ruft die App verschiedene dieser Funktionen auf, ich werde sie im Laufe des Tages auf die "Variable-Funktionen" beschränken, wenn das gehen sollte genügt mir das - nicht perfekt, aber ausreichend.P.S.
Hab's noch schnell ausprobiert. Wenn man sich auf die Variablen Funktionen beschränkt funktioniert's.Hallo,
Could you make a list of the functions that crash and the ones that work fine?
It may be acceptable to proxy more functions in AptioFix if necessary.
So far I had to use ResetSystem, and it worked fine for me, but others may indeed crash.By the way, do you know whether Apple changed AppleEFIRuntime interface across different versions of macOS? I currently call functions directly via gPEEFIRuntimeServices, but it is safer to invoke AppleEFIRuntime. The only reason stopping me from reversing the header is that they may change it at any time.
P.S. Sorry, don't know German, hoping for Google Translate.