I.nfraR.ed Posted September 26, 2019 Share Posted September 26, 2019 (edited) Hello everyone! Long story short, someone developed an app called AsusZenStates, originally meant to give the user control over P-States on first gen Zen CPUs, with some additional options. It was ASUS motherboards only. However, he doesn't support it anymore and made it open-source. I've made an own fork and now trying to support it for all Ryzen generations and for all motherboard vendors. Since Zen2 launch things have changed significantly in the way some things are controlled through the SMU and MSRs. The lack of meaningful public documentation from AMD side makes it really difficult, especially for a person like me. I'm a front-end developer and don't have much experience with C#, let alone bios development for desktop, although I've had some personal projects for android kernels and co. So I'm trying to do my best, but all I've done so far is mostly reverse-engineered. I still haven't figured out how to control PBO limits (perhaps scalar doesn't work with all motherboards either), so some of the controls are currently disabled. "SMU Power Limits" is also blocked by AMD (the command to disable the feature gets blocked), so this control is disabled as well. Additionally most of the things are SMU/AGESA version and CPU gen dependant, so there might be some logic errors in the code regarding this. I've quickly made a small website, which fetches currently released version. If someone is willing to help with the development and testing, please let me know. Download the app and test it (VID control only works if you use Auto or Offset mode for voltage, but that's to be expected). I will later write a little more info about different CPU generations and features available. Unfortunately I only have access to Ryzen 5 3600 and Ryzen 7 1800X with Crosshair VI Hero (X370) and Asrock B350 K4 (B350). In order to test other combinations I would need to burn more money and buy a Zen+ CPU and next gen motherboards. There are also differences between different vendors. Download: https://zenstates.protonrom.com/ Source: https://github.com/irusanov/ZenStates Current version: 0.8.0-beta3 PS: Also, if someone needs the source of the simple "website", feel free to request it. It's IE-friendly, uses bootstrap for the layout and I've setup a nodejs project for it to automate the build process with sass to css compilation, js transpiling and optimizations. Edited August 22, 2020 by I.nfraR.ed 5 1 Quote Link to comment Share on other sites More sharing options...
TerraRaptor Posted September 26, 2019 Share Posted September 26, 2019 Great one! Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 7, 2020 Author Share Posted January 7, 2020 (edited) Not being able to get all the missing bits needed to fix the ZenStates app for all supported CPUs I've developed a debug tool to help me test them easier. It started as an internal tool, but grew up and is now available to the public, hoping that it will help me understand things better. TL;DR - Skip to How Can You Help Semi-technical Info Ryzen uses the so-called SMN Mailboxes. As I understand it is a bit of an extension of the standard PCI communication protocol. Basically using special registers/ports for index/data and a set of custom commands for communicating with the SMU (System Management Unit). There are 2 types of commands - "read" which doesn't require a parameter and "write" which sets certain parameter by sending a value to the SMU with the corresponding command. ZenStates and SMUDebugTool use OpenLibSys and WinRing driver for the PCI read/write operations and wraps the SMU read/write around them. There are 3 addresses (+ a pair of standard PCI index/data ports): - MSG Address: Where the Command ID is sent to - RSP Address: Holds the status of the function execution - ARG Address (+5 more, but only one is used): Read the result of a function or where you send the parameter value if the command is of type "write" The workflow for sending a command is as follows: The RSP register is first reset (set to 0), the argument is written to the ARG address and at last the command ID is sent to the MSG address. To check for successful execution you poll the RSP address until a status is returned (0x1 for success, but there are other status coded). If succeeded, you can now read back the ARG address which holds the result. Problem The biggest problem is there's no public documentation for this. Different generations have different addresses and/or commands. SMU version, socket type and CPUID also matter. Throw an ES CPU in the mix and things get even uglier. What I see is AMD kind of unified the 3rd generation and they are more similar than different, but older gens are all over the place. The other problem is to find which commands (IDs) are supported and what their function is. More about the tool It's all manual. The tool detects CPUID and based on that preloads a set of addresses that I *think* would work. It has 3 tabs for now - SMU, PCI and Info. Will add MSR later. 1. SMU Used to test the workflow described above. [Reset] button loads the default set (detected on startup). Scan attempts to find usable mailboxes, which then can be tested with the textboxes on the left and [Send] button. 0x1 command is "Test Message", 0x2 is "Get SMU version". Both are perfectly safe and are the only ones that are always the same for all generations. On the sample screenshot I've first clicked on [Scan] button and then sent 0x6E which for Matisse is returning the maximum (fused) boost frequency. 2. PCI This is no more than a wrapper using the standard PCI write/read. The PCI register is read with [Read] button and the value then displayed in the second field. [Write] button obviously does the opposite - writes the value/config back to the register. On the screenshot I've read the PROCHOT status. This (PCI read/write) can be used on all systems, not just on Ryzen. MSR will be cross-platform as well. 3. Info Displays a basic system info. I'm most interested in the [Export] button. It generates a JSON file, containing the displayed information and also runs the SMU scanner to add the addresses. The file is saved in the same directory where the tool is. A report from my system looks like this: { "CpuId": "870F10", "CpuName": "AMD Ryzen 9 3900X 12-Core Processor", "MbVendor": "ASUSTeK COMPUTER INC.", "MbName": "CROSSHAIR VI HERO", "BiosVersion": "7704", "SmuVersion": "46.54.00", "Mailboxes": [ { "MsgAddress": "0x03B10524", "RspAddress": "0x03B10570", "ArgAddress": "0x03B10A40" }, { "MsgAddress": "0x03B10528", "RspAddress": "0x03B10574", "ArgAddress": "0x03B10A60" }, { "MsgAddress": "0x03B10530", "RspAddress": "0x03B1057C", "ArgAddress": "0x03B109C4" } ] } How Can You Help - Download the app from my github: https://github.com/irusanov/SMUDebugTool/releases - Extract and run it (might need elevated privileges - "Run as admin" if you get WinRing initialization error) - Click the [Export] button in Info tab and share the output here (or where deemed appropriate) Although it seems to be running without issues, I have one report that the scan feature causes BSOD on one Epyc ES, so be aware there's such possibility. As always, I'm not responsible for any induced damage, you run it entirely on your own risk ? It seems ZenStates is not that interesting to the community, but I'd be glad if more people participate, so I can collect more data for different systems and CPU generations. Thanks in advance! Edited January 7, 2020 by I.nfraR.ed 1 Quote Link to comment Share on other sites More sharing options...
cbjaust Posted January 7, 2020 Share Posted January 7, 2020 (edited) The community is probably mostly unaware of Zenstates. I downloaded your application the other day after seeing you mention it in the discord. I will get around to querying my 3600X soon and 1800X later. Hopefully it will provide useful data. Edit: output added. SMUDebug_26306422.5744059.json Edited January 7, 2020 by cbjaust 1 Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 7, 2020 Author Share Posted January 7, 2020 Thanks, we have the 3rd gen Ryzen (desktop) pretty much confirmed. At least with what everyone is running (newer AGESA). It's a safe bet that noone will run really old bios with old AGESA for these anymore. Quote Link to comment Share on other sites More sharing options...
Splave Posted January 7, 2020 Share Posted January 7, 2020 does this have potential on thread ripper? Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 7, 2020 Author Share Posted January 7, 2020 (edited) The goal is to support as many as possible. Castle Peak share the same CPUID as Matisse, so it should use Matisse's settings and be detected as such. Currently Matisse, Castle Peak and Rome are set to use the same addresses (in the Debug Tool). Colfax (TR2) is using the same addresses ad Pinnacle Ridge and Whitehaven (TR) - Summit Ridge. PS: I'd be glad if you can run a quick report on one of the 39x0 Threadrippers. Won't find many people using them yet, but want to confirm the addresses. Edited January 8, 2020 by I.nfraR.ed 1 Quote Link to comment Share on other sites More sharing options...
Splave Posted January 8, 2020 Share Posted January 8, 2020 Will do tonight Quote Link to comment Share on other sites More sharing options...
3urner Posted January 8, 2020 Share Posted January 8, 2020 Really nice work! I'm currently only able to program in Java and a little bit c++ I don't have much knowledge about such programming you need to do. But I can try to help you if there's something. At least I can test your software on a 3950X and maximus impact. Quote Link to comment Share on other sites More sharing options...
KaRtA Posted January 9, 2020 Share Posted January 9, 2020 Do you need same cpus on different boards, or just different cpus. I have a 2700x in the Impact 8 currently if that’s of any assistance? 1 Quote Link to comment Share on other sites More sharing options...
Splave Posted January 9, 2020 Share Posted January 9, 2020 (edited) Here you go 3970X on Taichi. Seems to be working perfectly. Im blown away bro.....do you have a donations link? This works when the asrock tool wont even install lol EDIT: found donation link thanks for your work! SMUDebug_63586525.6591326.json Edited January 9, 2020 by Splave 2 Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 9, 2020 Author Share Posted January 9, 2020 (edited) Thanks, Allen! They are designed to work on XP as well, but you'd need to update .NET Framework to 4.0 there. Can't use a lower version though, due to some features only available in .NET 4.0+. Perhaps I could try with statically linked libraries, so you don't need to install anything, but it's a bit new to me... 18 hours ago, KaRtA said: Do you need same cpus on different boards, or just different cpus. I have a 2700x in the Impact 8 currently if that’s of any assistance? At least with Mattise, mb vendor and model doesn't seem to matter. Perhaps a board with older SMU version might give a different result. New version of the debug tool with important bugfixes is up: https://github.com/irusanov/SMUDebugTool/releases/tag/v1.2.1 Quote Fix scan mechanism BSOD on Epyc and SMU lock after several reads on other platforms Extend system info in the report, now including OS version, app version and CPU code name Request elevated privileges when needed Anyone willing to test, please use this version to avoid potential problems, or at least minimize the chances. It might give some false positives for the addresses, but that's much better than BSOD or SMU lock. SMU lock can only be fixed with full power off/on cycle, even reboot from OS did not work for me. When that happens the CPU is stuck at random FID/VID state, but it probably only happens if the CPU is not in OC Mode. I've also found how to detect OC mode reliably. The old method doesn't work with the new SMU versions, thus ZenStates always thinks it is in OC mode. Next ZenStates release will be a big one, but there's a lot of work left. Those reports are definitely helping though. Most of the collected reports so far: https://github.com/irusanov/SMUDebugTool/wiki/SMU-Debug-Reports Pretty much confirming my default sets. Edited January 9, 2020 by I.nfraR.ed 1 Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 21, 2020 Author Share Posted January 21, 2020 (edited) New app, ZenTimings. Verified to work on Zen, Zen+ and Zen2. Was reading wrong values on TRX40 SKUs, hopefully fixed with the 1.0.1 version. It's similar to the old Ryzen Timings Checker by @The Stilt but only includes timings I know how to read. Version 1.0.1 adds elevated privileges prompt (when needed) and a fix for reading timings on Castle Peak. Download: ZenTimings [GoogleDrive] Edited January 21, 2020 by I.nfraR.ed 3 Quote Link to comment Share on other sites More sharing options...
Splave Posted January 21, 2020 Share Posted January 21, 2020 Is it possible to have more core voltage maybe 1.800 and or the ability to uncheck the core voltage so it doesn't apply any and it keeps what's already set. Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 21, 2020 Author Share Posted January 21, 2020 (edited) Second one - yes. First one - probably not, if you've set the maximum offset in bios. There are 3 modes the CPU can operate in: Auto The CPU requests VID according to load, frequency, temperature, programmed VID, programmed (fused) power limits Offset The same as #1, but with a manual offset (either positive or negative), which doesn't mean the CPU always conforms to that - still depends on various conditions Full manual The requested VID is ignored by the motherboard and the VRM is constantly supplying the desired voltage. Changing VID in this case has no effect. I believe you're using the second case and have put the maximum positive offset. The detected VID is probably 1.100V, so the margin you have is: VIDmax - VIDdetected + VIDoffset Maximum VID for AMD is 1.55V (VID = 0). I've checked on my motherboard and maximum positive offset is +450mV. 1.550 - 1.100 + 0.450 = 0.9. So maximum possible voltage should be ~2V (not counting vdroop and LLC). If you set maximum offset from bios, then your starting point should be 1.55V, which will be mapped to the 1.100 VID in ZenStates. Assuming your max is +0.45 though. Maybe this maximum offset is calculated on the base of VIDmax - VIDdetected or it can also depend on motherboard vendor/bios. Don't have that information. One way to override the VID from ZenStates is using manual voltage from bios, but then you need to have a software designed for your motherboard, which can control its VRM IC. Perhaps I didn't fully understand the issue, so correct me if I'm wrong. As for the second thing you asked - yes, I can add a checkbox so it gets ignored when not checked. The idea is to completely rewrite the app, remove the service, remove things that don't work (e.g. Pstates, Enable/Disable SMU features), fix the power limits and add one more option (Disable PROCHOT), which should be useful on cold. Hopefully will be ready with the first version until the end of the month. PS: Btw, if you need to only set multiplier within windows, then I can give you instructions how to use the debug app for this or even strip it and expose just the multiplier thing, shouldn't take too much time. Edit: Maybe it is a good idea to replace the VID values with offsets. A little more calculations would be needed, but it's not a problem. Edited January 21, 2020 by I.nfraR.ed 1 Quote Link to comment Share on other sites More sharing options...
Splave Posted January 23, 2020 Share Posted January 23, 2020 "PS: Btw, if you need to only set multiplier within windows, then I can give you instructions how to use the debug app for this or even strip it and expose just the multiplier thing, shouldn't take too much time." This would be great. I can just boot whatever vcore directly then from bios as long as it doesnt try to apply 1.55 then in the program thanks Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted January 25, 2020 Author Share Posted January 25, 2020 (edited) Latest version of the little ZenTimings. No plans for more updates for now, unless I find how to read FCLK, Rtt and ODT values. Should work on all Zen-based SKUs from any generations so far, including server variants. v1.0.3 adds configured DRAM frequency, total capacity and part number (read from first installed DIMM only). Download from my Google Drive -> ZenTimings Edited January 25, 2020 by I.nfraR.ed 4 Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted February 4, 2020 Author Share Posted February 4, 2020 ZenStates for Linux, now with a GUI. I've forked an old repo, updated it and added a GUI. Python-based. https://github.com/irusanov/ZenStates-Linux There's also a new version of the SMUDebugTool, which adds OC frequency (all cores or a chosen single core) controls and MSR read/write/scan. https://github.com/irusanov/SMUDebugTool/releases 2 Quote Link to comment Share on other sites More sharing options...
Crew Strunkenbold Posted February 8, 2020 Crew Share Posted February 8, 2020 On 2/4/2020 at 8:18 PM, I.nfraR.ed said: ZenStates for Linux, now with a GUI. I've forked an old repo, updated it and added a GUI. Python-based. https://github.com/irusanov/ZenStates-Linux There's also a new version of the SMUDebugTool, which adds OC frequency (all cores or a chosen single core) controls and MSR read/write/scan. https://github.com/irusanov/SMUDebugTool/releases Wow, that's very unique someone creates linux tools. Gonna try this out in some weeks once I build my new system. Quote Link to comment Share on other sites More sharing options...
George_o/c Posted February 9, 2020 Share Posted February 9, 2020 Well done man, superb work! Quote Link to comment Share on other sites More sharing options...
Splave Posted February 9, 2020 Share Posted February 9, 2020 64 core working great! I use your tool exclusively. Really improved my benching experience. Can't thank you enough! Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted February 10, 2020 Author Share Posted February 10, 2020 Glad to see it is working! I'm going to update the main app, but no ETA. Quote Link to comment Share on other sites More sharing options...
l0ud_sil3nc3 Posted February 10, 2020 Share Posted February 10, 2020 Also wanted to say thanks Infra, your tool was blessing instead of having to boot 5.8+ every time. Made benching pi smooth sailing on Windows 7 with x570 when no other tool worked. Quote Link to comment Share on other sites More sharing options...
yosarianilives Posted February 10, 2020 Share Posted February 10, 2020 What do you need for testing on Rome? I can see if they still have access to the rome server I benched for CC. Quote Link to comment Share on other sites More sharing options...
I.nfraR.ed Posted March 6, 2020 Author Share Posted March 6, 2020 (edited) Blind testing is not recommended, since it can kill the chip. You can run the SMU scanner from SMUDebug Tool though and save the report. Sorry for the late answer. Added a screenshot button to the ZenTimings app, per popular request. Download: ZenTimings v1.0.4 (Google Drive) Edited March 6, 2020 by I.nfraR.ed 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.