I.nfraR.ed

Killing it with one hand!

Judging from the discussion in the rom.by forum, he tweaked the alpha-timings for specific Hynix chips. https://www.rom.by/forum/Moddenye_biosy_dlja_nForce_2?page=3 perhaps something to do with the module next to the BPL, like I reported here: or the BPL itself. You might find something useful by comparing the bioses. I don't have time for this now, but will get back to it some time in the future. There are many parts of the bios that are still unclear to me. I can read and understand Russian most of the time, so if you need something translated (which google translate messed up), I could probably help. Overall they don't seem to have a positive feedback on this Forsage bios. PS: He says that he fixed the timings for the specific RAM IC by reading its datasheet and changing them in the bios (probably in the block I've talked about). PS2: He also talks about a program he wrote BIOS Explorer for nForce2-bioses (BEXplo.7z) which can mod ROMSIP and CPC, but it's for 2Mbit bioses only and can't find a working link.

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

Yes, I thought there's no point in changing the failsafe tables, so I left them untouched. Also tried to leave these values in the other tables, but in fact it didn't matter if I put them all the same or keep the stock values, when using the same table for all straps. What bugged me when I was trying is that some stock bioses have them mixed on some tables, like 0C10 1414. It was DFI, IIRC. Good work decoding that, though!

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

Almost :p But you gave me a great motivation to test again. Great results - all of them.

Very nice. You beat me on almost everything (Pi on DDR2 is so slow compared to DDR3). The Xeon seems to be out of reach on this one though.

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.

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]

That Volterra controller is fully programmable. What do you set voltage with? I've used the VT1165 plugin for RivaTuner in the past. There was a similar thread recently and they suggested VoltageFactory tool: https://community.hwbot.org/topic/193668-gtx-260-ocp-ovp-need/ According to the documentation, when in SVID mode, you should be able to set voltage even above 2V. As for OVP in general, the OVP trip point is usually set as an offset value (in mV) relative to the programmed VID or the nominal voltage. To lift that limit you have to re-programm the VID. On the NCP controllers, usually that's the only way. VID is set with bunch of resistors (or empty pads) each representing a single bit (0 or 1). You can configure them according to the VID table in the documentation of the controller you're working with. Normally, you don't need to touch all of the resistors. Programming a higher VID (nominal/starting voltage) lifts the trip point, although the tolerance you have is still the same if you don't have a way to increase it or disable it completely. After changing VID, you can still use that FB/Sense pin mod to increase output voltage. For example, a common NCP3588 on older cards has a non-adjustable OVP threshold. Edit: I remembered that TechPowerUp's GPU Tool also works with HD4890: https://www.techpowerup.com/download/gputool-community-technology-preview/

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... 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 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.

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.

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.

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!

Bad , bad Leeghoofd! You killed the child in me ?

Great one. This makes me wonder if Ryzen + XP + 3DMark 05/06 will be any good.

I don't want to justify his actions, but this case I feel is mostly "don't kill the messenger" rather than bashing him for lack of a sportsmanship. If it was not him, there would be others. In some way it is better that it popped up so early in the year. Maybe that was his goal, I don't know. Moreover, Alby wrote that this was a known issue, which the staff hoped(?) won't be exploited. This makes things a lot harder for "Magical USB" guys, but maybe we will now see what they are holding as backups, which is a positive thing

Yes, sure. But generally speaking, you need very high CPU frequency to match the score of a DDR3 system. https://hwbot.org/submission/2232551_i.nfrar.ed_superpi___1m_sempron_145_14sec_219ms

Not to be the bad guy, and I could possibly be wrong, so excuse me if so. But, did you buy 9900K, 3900X, 3960X, 3970X, boards for them and many more Xeon CPUs or do you just use your clients' machines before they take them? Or you bin expensive CPUs to fulfill your clients' needs? How is this exactly fair to other Enthusiast or even Extreme overclockers who buy their hardware on retail prices from the stores? Excuse me if my assumptions is wrong, but everyone visiting your profile can come to the same conclusion.

You know that the score will be removed sooner or later, because it is done on Win8 without BenchMate, right? https://hwbot.org/news/9946_application_94_rules/

I don't think he has retired, plus he's still active on forums ?

Sorry for the delay, guys. Had a lot to do at work and was too tired. Haven't turned the s.A system on since last time I wrote in the thread. Have some free time at work now, so I will try to briefly explain about the key-in menu. Let's take an example item. The typical item looks like this (25 bytes): 00 00 00 0B FF FF 1F 00 75 1F 00 01 0B 00 00 1F 00 E1 01 00 00 00 00 00 00 According to the info I've shared earlier, first 2 bytes are status. First byte is visibility, second byte is type/function. To convert an item to key-in, I've found that you need to set the second byte to 0B. According to the info, it should be 0x0100 (or 00 10, because it is little endian order), but it didn't work. 0Bh was mentioned in polygon's PDF and it worked. Next 2 bytes are label index and label group index. In my example we have 00 (first label) in 0B (12th group in _EN_CODE.BIN). We leave it untouched. Next is chipset reg and mask, for a regular custom item, chipset reg (04h,05h) is always FF FF. Some of the stock items have them set to point to the actual chipset register. 06h, 07h is Chipset mask. All the documents say it needs to be the same as CMOS Mask. Haven't tried if it is actually the case. 08h is CMOS reg, 09,0A is the CMOS mask. 0Bh is the index to the first label for the item menu and 0Ch is the label group. In this case we set both to 00. I think they are ignored anyway, but we don't need them 0Dh, 0Eh is itemMin 0Fh, 10h is itemMax If we want to support values from e.g. 1 to 15 (1h to Fh), we change these to 01 00 0F 00. 11h, 12h is position on the screen. The modified item would be 00 0B 00 0B FF FF 1F 00 75 1F 00 00 00 01 00 1F 00 E1 01 00 00 00 00 00 00 Keep in mind I write this from memory without actually trying it atm. Hopefully the offsets are correct, but you can experiment.

It's me again Key-in for the FSB frequency. It is supposed to be in DEC, but it appears to be using something like index or whatever. It's not in HEX either. Will play a bit with it to see if I can make it completely working. Maybe use DFI Ultra-D bios as an example or the "Delay IDE Initial" in NF7 bios. Don't have more time before work though. PS: Unfortunately it appears they have used some sort of mapped values, since 187 entries cover the whole range from 100 to 300 and it skips some of the frequencies. Transforming it into a key-in option still uses that table and it is in fact an index and not a direct value. Don't think I will be able to change that, but at least the technique can be used with other (custom) options, where the value saved in cmos register is the same value used for the actual "timing". For example, tREF would have the same issue as the FSB, but those which don't use a key-value map could be transformed. Not that I see any benefit, except you won't need the menu item labels. You loose the "auto" option, so you either allow the user to input 0 (will be treated as auto in the ISA ROM code) or limit the minimum to 1, which then doesn't allow an "auto" option. Not really user-friendly. Initially I thought that it might be possible to somehow shift it from 0-255 to 100-355, but in theory 255 (as a direct value) should be the maximum possible (FF in the register). Won't happen without additional logic in the bios - basically take the exact value and add 100. Not really usable in ISA option ROM, because it is too late. Has to happen much earlier before POST. Wonder if it will work for AGP frequency though. Guess I will be back to ROMSIP testing, but will share what I did for the key-in method later, so we have it documented.

I've tested some values, but don't have more time today. Got some strange results. AA is faster, but also limits the maximum bootable FSB frequency. Difference in AIDA is negligible. Tests done at 11x220, all manual timings. Maybe need to test more values. Trying to run 1M at 260MHz resulted in a lockup. Haven't tried higher Vdimm though. 270MHz is pretty much the limit on this board with BH-5 DC and haven't managed to overcome it. It's not stable at 270MHz. It would be a lucky run if 1M finishes all loops. Pi 4M AIDA FSB 55 03m 25.415s 3459/3463/3449/65.5 270 MHz 22 03m 24.824s 3460/3462/3451/65.3 270 MHz AA 03m 23.923s 3460/3462/3450/65.3 260 MHz Also tried 00 and it was somewhere between 22 and 55, perhaps it is something like "auto". I've also seen DD, FA and FF in 133/166 stock tables.

My table is based on one of the 200MHz DFI tables. There are several such tables and they differ in this byte only (if we ignore the multiplier table). One strange thing - initial NF7 bios doesn't have this first part of the tables...