No matter what I try, I always get the same error. Can’t get your drivers to work.
Without being able to look at your system myself I really don’t know what the issue would be then. You are the only person I know of with this issue and I can’t replicate it myself so don’t have any other suggestions for now.
Let me know how that goes, if it does flash using the DOS tool included with these modded UEFIs I’ll put something custom together. Might try myself later if I can find some time.
I have some newz… Since building my Ryzen 1700 some weeks ago I’ve been running it on my Intel system windows 10 installation. Today I got around to installing Windies 10 on the NVE SSD, installed HWInfo and as soon as I ran it I see the core speeds changing between 3.95ghz and 1.5ghz and a number of steps inbetween. So it looks like the P-states are working or perhaps it was the odd multiplier frequency trick mentioned previously around here. I will change it to even multiplier later and see if the P-states still work… if they do then we know it’s because of your bios mod. Idle CPU temp is now 25c (was 28 - 30c on the old windows installation SSD).
Thats good to know. I don’t know of other boards that have that P-State clocking problem I’d have to test some of the other boards I have. Knowing how extensively Gigabyte are pulling AMDs AGESA code apart I’d be inclined to say its yet another Gigabyte self-inflicted bug (thats not to say it is however), I wouldn’t believe their spiel about "competitors pulling the feature" for a single micro-second either as the contacts I have not only have not mentioned P-States being pulled, they have not said it is even being considered and with all of the boards I have for testing with the latest UEFIs available they all have the P-State overclocking feature so at this time I’d say what Gigabyte are saying is just to try and cover their own lazy arses and the real truth is just that - them being lazy and not being arsed to add P-States despite the rampant requests for it.
Turns out the clock and voltage is locked rigid with EVEN clock multipliers and variable with ODD multipliers. Ryzen power plan keeps the CPU clock locked high, choosing non-ryzen power plan allows the multiplier and voltage to vary according to load.
Let me know how that goes, if it does flash using the DOS tool included with these modded UEFIs I’ll put something custom together. Might try myself later if I can find some time.
I have some newz… Since building my Ryzen 1700 some weeks ago I’ve been running it on my Intel system windows 10 installation. Today I got around to installing Windies 10 on the NVE SSD, installed HWInfo and as soon as I ran it I see the core speeds changing between 3.95ghz and 1.5ghz and a number of steps inbetween. So it looks like the P-states are working or perhaps it was the odd multiplier frequency trick mentioned previously around here. I will change it to even multiplier later and see if the P-states still work… if they do then we know it’s because of your bios mod. Idle CPU temp is now 25c (was 28 - 30c on the old windows installation SSD).
Thats good to know. I don’t know of other boards that have that P-State clocking problem I’d have to test some of the other boards I have. Knowing how extensively Gigabyte are pulling AMDs AGESA code apart I’d be inclined to say its yet another Gigabyte self-inflicted bug (thats not to say it is however), I wouldn’t believe their spiel about "competitors pulling the feature" for a single micro-second either as the contacts I have not only have not mentioned P-States being pulled, they have not said it is even being considered and with all of the boards I have for testing with the latest UEFIs available they all have the P-State overclocking feature so at this time I’d say what Gigabyte are saying is just to try and cover their own lazy arses and the real truth is just that - them being lazy and not being arsed to add P-States despite the rampant requests for it.
Turns out the clock and voltage is locked rigid with EVEN clock multipliers and variable with ODD multipliers. Ryzen power plan keeps the CPU clock locked high, choosing non-ryzen power plan allows the multiplier and voltage to vary according to load.
I’ll bare that in mind for other folks. I only use a high performance power plan but I’m sure there are others using the Ryzen plan encountering issues not realising its the Ryzen plan doing it. In other news I’ve looked at the K7 F7b beta UEFI and see no evidence of Gigabyte doing anything but unlocking the P-State options.
Any odd chance of getting ATA security unlock support added to the bios? I’d actually donate like 25 bucks for that (would do more, but unfortunately, I am pretty darn broke at the moment, heh).
I have tried my hand at it but you seem far more skilled. I do however know how to get around the sig check (with a hex editor) in file so you can q-flash things if you care to PM me.
Ok guys what I’ve been doing is coming along quite well I just have to make a few more changes and do some testing then I’ll release what I’ve been doing which I guess people would call reverse engineering but I just call it modding
I just joined to say thanks for your efforts so far.
I have a AB350 Gaming 3 - to which I flashed your version of F9d. When I enter the BIOS and go to Peripherals -> CPU Configuration, I see lots of the PPC Configuration - which I assume are the slots to pick the Pstates.
If I try to select P0 -> P7 from the top to bottom entries, the selection never changes from P0.
Am I doing something wrong? bug? Missing something simple?
I can’t really comment as I don’t have a Gaming 3 but there has been a lot of chatter in the thread that in order to get P-States to work you need to use an odd multiplier and change the CPU power states in the Windows power plan profiles to have the CPU throttle up and down as it should. Seems like AMD have a few quirks to fix in their AGESA code still to me.
I’m not quite sure what you mean here… The Windows Power Plan Profiles?
I mainly use Linux on this system - however I notice that in the Node Info menu, it says the CPU is 2.2Ghz → 3.4GHz… My CPU is a 1700x - it has build date 1705 if that matters…
Looking at the ZenStates tool, I see:
1 2 3 4 5 6 7 8 9 10 11
# ./zenstates.py -l P0 - Enabled - FID = 88 - DID = 8 - VID = 20 - Ratio = 34.00 - vCore = 1.35000 P1 - Enabled - FID = 78 - DID = 8 - VID = 2C - Ratio = 30.00 - vCore = 1.27500 P2 - Enabled - FID = 84 - DID = C - VID = 68 - Ratio = 22.00 - vCore = 0.90000 P3 - Disabled P4 - Disabled P5 - Disabled P6 - Disabled P7 - Disabled C6 State - Package - Enabled C6 State - Core - Enabled
This seems somewhat strange.
I also note that the AGESA version seems to say 1.0.0.6 - not 1.0.0.6b (if that makes any difference?) that is supposed to be in the stock gigabyte F9d bios...
If I enable the p-states via the software script, I can get it to show:
1 2 3 4 5 6 7 8 9 10 11
# ./zenstates.py -l P0 - Enabled - FID = 94 - DID = 8 - VID = 20 - Ratio = 37.00 - vCore = 1.35000 P1 - Enabled - FID = 88 - DID = 8 - VID = 2C - Ratio = 34.00 - vCore = 1.27500 P2 - Enabled - FID = 78 - DID = 8 - VID = 38 - Ratio = 30.00 - vCore = 1.20000 P3 - Enabled - FID = 70 - DID = 8 - VID = 3A - Ratio = 28.00 - vCore = 1.18750 P4 - Enabled - FID = 68 - DID = 8 - VID = 40 - Ratio = 26.00 - vCore = 1.15000 P5 - Enabled - FID = 60 - DID = 8 - VID = 48 - Ratio = 24.00 - vCore = 1.10000 P6 - Enabled - FID = 58 - DID = 8 - VID = 68 - Ratio = 22.00 - vCore = 0.90000 P7 - Enabled - FID = 48 - DID = 8 - VID = 78 - Ratio = 18.00 - vCore = 0.80000 C6 State - Package - Enabled C6 State - Core - Enabled
I've picked all these values manually - so no idea if they're optimal as yet.... I'm also not quite sure on how to tell if these are actually being used...
On another note, if I boot into Windows 10 and use Ryzen Master, I do see the CPU freq scaling between 2.2 and 3.5GHz - occasionally peaking to 3.9GHz under certain conditions...
Zitat von CRCinAU im Beitrag #116I'm not quite sure what you mean here.... The Windows Power Plan Profiles?
I mainly use Linux on this system - however I notice that in the Node Info menu, it says the CPU is 2.2Ghz -> 3.4GHz... My CPU is a 1700x - it has build date 1705 if that matters...
Looking at the ZenStates tool, I see:
1 2 3 4 5 6 7 8 9 10 11
# ./zenstates.py -l P0 - Enabled - FID = 88 - DID = 8 - VID = 20 - Ratio = 34.00 - vCore = 1.35000 P1 - Enabled - FID = 78 - DID = 8 - VID = 2C - Ratio = 30.00 - vCore = 1.27500 P2 - Enabled - FID = 84 - DID = C - VID = 68 - Ratio = 22.00 - vCore = 0.90000 P3 - Disabled P4 - Disabled P5 - Disabled P6 - Disabled P7 - Disabled C6 State - Package - Enabled C6 State - Core - Enabled
This seems somewhat strange.
I also note that the AGESA version seems to say 1.0.0.6 - not 1.0.0.6b (if that makes any difference?) that is supposed to be in the stock gigabyte F9d bios...
If I enable the p-states via the software script, I can get it to show:
1 2 3 4 5 6 7 8 9 10 11
# ./zenstates.py -l P0 - Enabled - FID = 94 - DID = 8 - VID = 20 - Ratio = 37.00 - vCore = 1.35000 P1 - Enabled - FID = 88 - DID = 8 - VID = 2C - Ratio = 34.00 - vCore = 1.27500 P2 - Enabled - FID = 78 - DID = 8 - VID = 38 - Ratio = 30.00 - vCore = 1.20000 P3 - Enabled - FID = 70 - DID = 8 - VID = 3A - Ratio = 28.00 - vCore = 1.18750 P4 - Enabled - FID = 68 - DID = 8 - VID = 40 - Ratio = 26.00 - vCore = 1.15000 P5 - Enabled - FID = 60 - DID = 8 - VID = 48 - Ratio = 24.00 - vCore = 1.10000 P6 - Enabled - FID = 58 - DID = 8 - VID = 68 - Ratio = 22.00 - vCore = 0.90000 P7 - Enabled - FID = 48 - DID = 8 - VID = 78 - Ratio = 18.00 - vCore = 0.80000 C6 State - Package - Enabled C6 State - Core - Enabled
I've picked all these values manually - so no idea if they're optimal as yet.... I'm also not quite sure on how to tell if these are actually being used...
On another note, if I boot into Windows 10 and use Ryzen Master, I do see the CPU freq scaling between 2.2 and 3.5GHz - occasionally peaking to 3.9GHz under certain conditions...
As everything is working in Windows it would seem that the problem is with Linux. I don't use Linux so you would need to deferre to someone who does to troubleshoot that issue. I noticed what should be AGESA 1.0.0.6b as just 1.0.0.6 as well. Either someone at Gigabyte used the wrong AGESA code base, or someone at AMD forgot to put the "b" at the end. I just assumed the latter rather than the former as the former is a step too incompetent even for Gigabyte.
That depends I don’t know which modded UEFIs are the most popular, boards people don’t seem to be buying I’ll drop mod support for and possibly start doing other UEFIs people request. I’ll see if I can post a poll or something for people to vote on.
