Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mobile ryzen 3500U and 1600AF #11

Open
markkundinger opened this issue May 29, 2020 · 5 comments
Open

mobile ryzen 3500U and 1600AF #11

markkundinger opened this issue May 29, 2020 · 5 comments

Comments

@markkundinger
Copy link

Hi! This seems really cool, I'm a noob and don't exactly know what I"m doing, but am enthusiastic and wanted to include dumps for my 1600AF (msi tomahawk b450) and my mobile ryzen 3500u (Motile M142) laptop.

The desktop 1600AF can run zenstates 0.80-beta3. I haven't really messed around the tweaks yet (i'm overclocked in BIOS, which seems to normally disable p-states... would be interesting to see if zenstates works betteR).

However, the desktop 1600AF when running 2.0.0_debug_20200529 gives error "Error getting SMU Version. Default SMU addresses are not responding to commands.".

I'm attaching the json from the SMU debug tool. Let me know if there's other info or testing you want.

will follow up with another post with dump from my laptop.

SMUDebug_26512676.3656378.json.zip

@irusanov
Copy link
Owner

irusanov commented May 31, 2020

Thanks for the dump. I think something has changed for the 1000 series, since I'm now testing 1800X and most of the things that worked before are not working with the newest bioses.

Could you run the 2.0.0 app after a fresh boot without running the Debug tool?

The SMU debug tool scanning mechanism locks the SMU of the CPU - that's why it does not respond to commands anymore and you need a reboot. It does the same on my 1800X.

@markkundinger
Copy link
Author

okay the new beta seems to work on the 1600AF? (which remember is basically a zen+ 2600).
1600AF37xOC
1600AFbaseline
1600AFinfo

the only thing is that when I do an overclock with this, the board's voltage won't drop any more. It always stays at the elevated level. I've noticed that also with bios overclocking and with Ryzen master though. so maybe no big deal.

@markkundinger
Copy link
Author

okay here is the baseline info from my cheap motile laptop with a 3500U. from the 2.0 debug version and from the SMU tool.

SMUDebug_26517449.9029509.json.zip
3500u baseline
3500U info

@markkundinger
Copy link
Author

my initial tests with the 3500U showed the following:

  • the display of the voltage for "manual overclock" seems to actually be the voltage for the lowest P2 state

  • I didn't seem to be able to actually change the voltage of P1 or P2. I was on battery so didn't get a chance to max out yet with P0 or manual overclock.

i don't know of any other tool that can under/overvolting a mobile ryzen, so it might be impossible?

@irusanov
Copy link
Owner

irusanov commented Jun 3, 2020

Thanks for the test.

  • The manual OC fields are initialized with the the values detected at the given moment the app is started. If the CPU is not in OC mode, then it is normal to display the current frequency/voltage.
  • Unfortunately this seems to be the case. There's a chance you can manipulate P2 state, but this also needs to be combined with the Windows power plan. P1 seems to be completely ignored.
    P0 only works if you change the DID parameter, but this also puts the CPU in OC mode.

It seems the days when you could make custom P-States are long gone. Those P-State, Turbo Boost and other MSR are common between all AMD64 CPUs, but they don't seem to serve the same purpose with the new CPUs.

I would probably need to hide the Manual OC controls based on the detected CPU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants