windows build

[trotol]

Hot to compile recent 1.3.0.0 win-build?

[irusanov]

You need to checkout the project (or download the source zip), then open the project solution (.sln file) in Visual Studio.
I use the free community 2019 edition, but keep in mind installation "takes forever". You need to install it and configure it for use with C#. After installing the IDE, it is as simple as clicking on Build -> Build Solution.

https://visualstudio.microsoft.com/downloads/

If you need Vermeer support, I still need to fix it (sync with ZenTimings).
If you don't want to go through the whole process to compile it yourself, let me know and I can attach a compiled binary for you. Will update the code today and might even release the 1.3.0 version.

[roman-orekhov]

@irusanov
Can you please make a release with Vermeer support, at least as it is now, w/o sync to ZT?

[irusanov]

@roman-orekhov I can probably sync and release it after work today. I update it for myself, but haven't bothered to upload a new build.

[irusanov]

@roman-orekhov Build is up, contains all the latest changes.
https://github.com/irusanov/SMUDebugTool/releases/tag/v1.3.0-beta
Let me know if something doesn't work as expected.

[PJVol]

@irusanov
Hi, Ivan!
You know what, almost a week I've been searchin for the way to sniff SMN ports used in a Veii/asus tool, and just realized answer was staring at me from the desktop all alone.
Thanks for the usefull monitoring feature. Just about to finish compiling the MP1 command ID list for Vermeer (the better part).

[irusanov]

@PJVol
That feature isn't perfect, since it's only reading the SMU addresses at a given interval in an attempt to detect a change, but the readings might be out of sync, especially when an application is spamming the mailbox several times per second as the Asus (work) tool does. However, it helped me pick some of the commands (e.g. GetDramBaseAddress and TransferTableToSmu) from hwinfo for CPUs I had no info before.

Asus tool only spams the SMU with 0x5 and 0x6 commands when you open the PM monitor. The rest of the commands used in CPU -> AMD can be picked quite easy by trying them one by one. MP1 commands labels also contain the ID, so no need to try anything for them.

I should mention the debug tool wasn't really meant for the public, so use it at your own risk.
The code isn't really good, it's a mess, but the app is still somewhat useful.

[PJVol]

The rest of the commands used in CPU -> AMD can be picked quite easy by trying them one by one. MP1 commands labels also contain the ID, so no need to try anything for them.

Yeah, but understanding the bit fields for some command is not that easy. I figured out arg bit layout for the setting psm margins per core dLDO.
If you interested I've posted my findings here
https://www.overclock.net/threads/official-amd-ryzen-ddr4-24-7-memory-stability-thread.1628751/post-28916314
I've installed VC (it took ~ 5-10 min) and built your 1.3 beta successfully. In general all is fine, except some weird errors at the beginning regarding "embedded" or whatever attributes for the resource files. I had to change filesystem attributes for the whole folder and upgrade project to NET 4.8, since 4.0 is not supported anymore.
And btw inpoutx dll binary was not copied into the bin folder duiring the "make install" for some reason.

[irusanov]

Yeah, but understanding the bit fields for some command is not that easy. I figured out arg bit layout for the setting psm margins per core dLDO.
If you interested I've posted my findings here
https://www.overclock.net/threads/official-amd-ryzen-ddr4-24-7-memory-stability-thread.1628751/post-28916314

Thanks for the info, that would help me, since I'm working on a new ZenStates and want to support these commands.
There's a way to get the cores enabled/disabled map, but I don't understand why it is wrong for the second CCD.
Setting OC frequency to a single core works the same way - you have to specify the physical core index and the CCD index.
Easiest way to get the core map is to read power of each core from the PM table, however, this means I have to define the offset and maximum cores for each table version (in the Core DLL).

And btw inpoutx dll binary was not copied into the bin folder duiring the "make install" for some reason.

Yes, it's not added as a resource. I will have to add the sources and the prebuild binaries. It's a manual copy at the moment.
WinRing is now integrated in the DLL though (which I still need to add the sources, to be entirely compliant).

[PJVol]

There's a way to get the cores enabled/disabled map, but I don't understand why it is wrong for the second CCD

Do you get fused topology data from SMN:: 0x3008(3208)xxxx ? I just checked, the data is correct for my single CCD sample, so i'm curious what exactly is wrong with a 2nd CCD data.
And btw, have you got an idea, what CCA is refered to in the pm_table?

[PJVol]

@irusanov

Ok. I think I now see what may be wrong with the code where you obtaining the fuses data in Zenstates-core. Actually I don't see where you even reading 2nd CCD data.

[irusanov]

@PJVol How so?
Reading the address on my 3900X gives me 0x0000001110001000, where 1 means "disabled" core.
Or if we divide them into CCDs -> [00000011] [10001000]
This means, if I read it right, 15 - 14 - 13 - 12 - 11 - 10 - [9] - [8] - [7] - 6 - 5 - 4 - [3] - 2 - 1 - 0
while power table shows correct data - disabled cores 3, 7, 8, 14

Maybe I should read the same address + 0x200000 for the second CCD which gives me
00000011 01000001 and that seems to be about right (lowest 8 bits).
So it seems I've overlooked this and the rest of the bits are something else.

As for CCA, I don't have a definition. It's something about throttling and temperature related, I think. Don't know what the abbreviation means.

[irusanov]

@PJVol Thanks for the heads up, should be now fixed in core DLL.

[roman-orekhov]

@irusanov
If you disable one of the CCDs in BIOS, what would that higher byte read? Still 0b00000011 for both?

[irusanov]

@irusanov If you disable one of the CCDs in BIOS, what would that higher byte read? Still 0b00000011 for both?

Thought about that and will have to check, it might show the enabled CCDs. Too much work lately on my regular job and don't really have time for other projects :/

PS: Tried and they read the same. It makes sense, since these are fuses after all.