Open GoogleCodeExporter opened 9 years ago
After looking in Llano.cpp, i saw that vcore increment is 0.0125V instead of
0.00625V.
I'll try to create a Richland.cpp based on Llano.cpp by changing some values
(CPUID, etc ...) with the help of "BIOS and Kernel Developer Guide (BKDG) for
AMD Family 15h Models 00h-0Fh Processors".
But i'm not used to C++ :(
Original comment by loic.po...@gmail.com
on 14 Oct 2014 at 10:35
Finally i got it working with the right pstates'vcore by replacing all "0.0125"
by "0.00625" in Interlagos.cpp from the last revision (r184) and compiling for
linux x86_64.
But i assume this wasn't the best way to go.
Now i'm trying to compile it for Windows with MinGW but without success.
Original comment by loic.po...@gmail.com
on 14 Oct 2014 at 3:43
Thanks for your report :-)
I think the best way to move forward is making Interlagos.cpp aware of different
Family15h models (incl. Richland which seems to be in 0x10-0x1F model range).
If/when differences between different Family 15h models are significant enough
we can fork Interlagos.cpp to cover them but until then I think we're fine by
keeping all family 15h stuff in Interlagos.cpp.
I'll prepare universal change which will use 0.0125 mV unit on 00-0Fh and 0.0625
mV on 10-1Fh (will check 20-2F and 30-3Fh, too).
The reason Win32/Win64 stuff isn't included is due to uncertain licensing of
WinRing0; I'll make a tarball and share it if you'd like to play with it.
Original comment by kszy...@gmail.com
on 27 Oct 2014 at 1:45
I'll be glad to, thanks in advance. I'm actualy comparing the different ways to
overclock this A10-5750m ES. And this vcore's issue doesn't help me to make
people consider using TPC instead of Pscheck or AmdMsrTweaker.
Original comment by loic.po...@gmail.com
on 27 Oct 2014 at 9:14
Can you try SVN r189? This should make getting vcore/minvid/maxvid as well as
setting
vcore work fine on your APU.
Once you build it, can you also post output of TurionPowerControl -l for my
reference?
Thank you!
Original comment by kszy...@gmail.com
on 28 Oct 2014 at 3:29
You can find win32 development files in an archive at
http://darkswarm.org/tpc/devel/
Just drop them into tpc dir (less tpc-win32/ component, ofc). Building with
MinGW
should then succeed without a problem (make sure to use appropriate Makefile).
Original comment by kszy...@gmail.com
on 28 Oct 2014 at 4:13
Sweet ! I'm gonna give it a try as soon as i can and send you some feedback.
Say starting from torrow. See you soon ;)
Original comment by loic.po...@gmail.com
on 28 Oct 2014 at 8:38
Sounds good. As there have been few more commits, just go about using the
latest SVN HEAD.
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 12:22
I tried revision 204 from svn.
The vcores displayed are good.
Here's the output of TurionPowerControl -l :
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
Main processor is Family 15h (Bulldozer/Interlagos/Valencia) Processor
Family: 0xf Model: 0x3 Stepping: 0x1
Extended Family: 0x15 Extended Model: 0x13
Package Type: 0x1 BrandId: 0x0
Machine has 1 nodes
Processor has 4 cores
Processor has 8 p-states
Processor has 3 boost states
Power States table:
-- Node: 0 Core 0
core 0 pstate 0 (pb0) - En:1 VID:48 FID:19 DID:0.00 Freq:3500 VCore:1.2500
core 0 pstate 1 (pb1) - En:1 VID:58 FID:16 DID:0.00 Freq:3200 VCore:1.1875
core 0 pstate 2 (pb2) - En:1 VID:72 FID:12 DID:0.00 Freq:2800 VCore:1.1000
core 0 pstate 3 (p0) - En:1 VID:88 FID:9 DID:0.00 Freq:2500 VCore:1.0000
core 0 pstate 4 (p1) - En:1 VID:94 FID:5 DID:0.00 Freq:2100 VCore:0.9625
core 0 pstate 5 (p2) - En:1 VID:106 FID:2 DID:0.00 Freq:1800 VCore:0.8875
core 0 pstate 6 (p3) - En:1 VID:110 FID:12 DID:1.00 Freq:1400 VCore:0.8625
core 0 pstate 7 (p4) - En:0 VID:112 FID:2 DID:1.00 Freq:900 VCore:0.8500
-- Node: 0 Core 1
core 1 pstate 0 (pb0) - En:1 VID:48 FID:19 DID:0.00 Freq:3500 VCore:1.2500
core 1 pstate 1 (pb1) - En:1 VID:58 FID:16 DID:0.00 Freq:3200 VCore:1.1875
core 1 pstate 2 (pb2) - En:1 VID:72 FID:12 DID:0.00 Freq:2800 VCore:1.1000
core 1 pstate 3 (p0) - En:1 VID:88 FID:9 DID:0.00 Freq:2500 VCore:1.0000
core 1 pstate 4 (p1) - En:1 VID:94 FID:5 DID:0.00 Freq:2100 VCore:0.9625
core 1 pstate 5 (p2) - En:1 VID:106 FID:2 DID:0.00 Freq:1800 VCore:0.8875
core 1 pstate 6 (p3) - En:1 VID:110 FID:12 DID:1.00 Freq:1400 VCore:0.8625
core 1 pstate 7 (p4) - En:0 VID:112 FID:2 DID:1.00 Freq:900 VCore:0.8500
-- Node: 0 Core 2
core 2 pstate 0 (pb0) - En:1 VID:48 FID:19 DID:0.00 Freq:3500 VCore:1.2500
core 2 pstate 1 (pb1) - En:1 VID:58 FID:16 DID:0.00 Freq:3200 VCore:1.1875
core 2 pstate 2 (pb2) - En:1 VID:72 FID:12 DID:0.00 Freq:2800 VCore:1.1000
core 2 pstate 3 (p0) - En:1 VID:88 FID:9 DID:0.00 Freq:2500 VCore:1.0000
core 2 pstate 4 (p1) - En:1 VID:94 FID:5 DID:0.00 Freq:2100 VCore:0.9625
core 2 pstate 5 (p2) - En:1 VID:106 FID:2 DID:0.00 Freq:1800 VCore:0.8875
core 2 pstate 6 (p3) - En:1 VID:110 FID:12 DID:1.00 Freq:1400 VCore:0.8625
core 2 pstate 7 (p4) - En:0 VID:112 FID:2 DID:1.00 Freq:900 VCore:0.8500
-- Node: 0 Core 3
core 3 pstate 0 (pb0) - En:1 VID:48 FID:19 DID:0.00 Freq:3500 VCore:1.2500
core 3 pstate 1 (pb1) - En:1 VID:58 FID:16 DID:0.00 Freq:3200 VCore:1.1875
core 3 pstate 2 (pb2) - En:1 VID:72 FID:12 DID:0.00 Freq:2800 VCore:1.1000
core 3 pstate 3 (p0) - En:1 VID:88 FID:9 DID:0.00 Freq:2500 VCore:1.0000
core 3 pstate 4 (p1) - En:1 VID:94 FID:5 DID:0.00 Freq:2100 VCore:0.9625
core 3 pstate 5 (p2) - En:1 VID:106 FID:2 DID:0.00 Freq:1800 VCore:0.8875
core 3 pstate 6 (p3) - En:1 VID:110 FID:12 DID:1.00 Freq:1400 VCore:0.8625
core 3 pstate 7 (p4) - En:0 VID:112 FID:2 DID:1.00 Freq:900 VCore:0.8500
--- Node 0:
Processor Maximum PState: 7
Processor Startup PState: 5
Processor Maximum Operating Frequency: No maximum defined. Unlocked multiplier.
Minimum allowed VID: 247 (0.0063V) - Maximum allowed VID 0 (1.5500V)
Done.
Good Job :D !
Now i'll try the windows version...
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 8:06
Cool :) Happy to hear things are looking better.
Side question, is it you who created
http://portables4gamers.com/forum/topic/24308-tuto-turionpowercontrol-overclock-
dun-apu-amd-a10-engineering-sample-sous-linux/ ?
If so, I have couple of comments/questions for you:
1. HwPstateMaxVal can be changed using tpc -psmax
2. What is the purpose of adjusting PopDownState ?
3. Out of fresh boot (no OC or any other adjustments), can you run:
tpc -psmax 1
followed by:
tpc -CM
for 30+ seconds, then capture the P-state/statistics screen and send it over?
Ideally, I'd like to try to make the procedure less complex and avoid changing
the
clocksource :)
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 9:18
Yes indeed ! I wrote this topic.
1 - I thought -psmax was for boost states only. I didn't know i could set
-psmax 3 to do the same thing.
2 - PopDownPstate as you may know, defines the p-state number whose frequency
will be forced once the TDP limit is exceeded. And it's linked to
HwPstateMaxVal.
It's workaround since you can't increase the TDP Limit.
3 - On my way ... but without any load you won't see any popDown.
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 11:31
Ad 2.
From my reading it's additional condition/procedure for entering CoreC6 so it
may
change how soon compute units enter CC6 which, together with CstateCnt may
change
when boosting to CstateBoost (and beyond) occurs (BKDG 2.5.3.2.3.3).
Ad 3.
Hmm, yes, with no load CUs are very likely to be in CC6.
That said, may I ask for #3 with all-core load, please?
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 12:12
stress.txt : It looks like mprime didn't help have those PopDown while using
-psmax 1.
But APM may be in the way since Boost States are enabled ...
cm_oc_ps3.txt : Here's the result of oc'ing p0 after disabling Boost states but
without the PopDownPstate tricks.
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 12:16
Attachments:
Interesting ... Here's what happen after the 3.6GHz oc if i try the -psmax 3
option.
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 12:24
Attachments:
Cool, thank you :)
tpc -psmax 1 seems to expose a bug in these CPUs that makes CPUs stick with Pb1
and ignore TDP logic (discovered sometime in 2012:
http://hardforum.com/showthread.php?t=1708870).
About cm_oc_ps3.txt (from comment #13) -- do I understand it correctly that your
objective was to have the CPU in ps3 at all times?
About cm_oc_psmax3.txt (from comment #14) -- that's weird. I was expecting
ps3 across the board...
Anyway, I was getting at showing you my sequence of commands (that I use with
family 15h ES chips here, albeit model 1):
# set scaling governor to "performance" or otherwise make sure the machine is
idle
FREQ=3600 # change appropriately
VCORE=1.2500 # change appropriately
tpc -psmax 7 # highest configured HW P-state (900
MHz/0.85V)
sleep 1
tpc -fo 1 # go to SW P-state 1 (HW P-state 4)
tpc -set ps 1 freq $FREQ vcore $VCORE # configure Pb0 with desired parameters
tpc -set ps 0 freq $FREQ vcore $VCORE # configure Pb1 with desired parameters
sleep 1
tpc -fo 0 # go to SW P-state 1 (HW P-state 3 +
boost)
sleep 1
tpc -psmax 1 # force Pb1
The reason I do it this way is to avoid changing P-state 3 (because it changes
TSC
rate). The upside of this sequence is that it's the only thing that's needed (no
need to change the clocksource).
The downside is that CPU is locked to single P-state (Pb1) no matter if the
machine is loaded or not.
I just thought I'd share it with you in case you're interested :-)
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 12:50
From comment #14 : Yes tha'ts weird, it behaves like Pb0, with 2cores in C6.
I known about the TSC issue. Telling the OS to use HPET instead helped, it's an
issue encountered with AmdOverdrive too.
Thank's I'll give your sequence a try, by changing severals times the
frequency, and report as soon as possible.
'Later.
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 1:14
Okaaaaay ! Now i recall why i disabled TurboCore and used ps3 (p0) : APM
reverts the p-state's frequency to default value if set higher.
Here's the output :
--------------------------------------------------------------
Setting APU @ 3800 Mhz with 1.237 V
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
Done.
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
PState set to 1
Done.
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
WARNING: -set is deprecated and will be removed in future versions.
Please consider using standalone versions of your sub-commands.
Consult the documentation for details.
All nodes all cores pstate: 1 -- set frequency to 3800.0000 (actual: 3200)
All nodes all cores pstate: 1 -- set core voltage to 1.2370 (actual: 1.1875V)
*** -set parsing completed
Done.
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
WARNING: -set is deprecated and will be removed in future versions.
Please consider using standalone versions of your sub-commands.
Consult the documentation for details.
All nodes all cores pstate: 0 -- set frequency to 3800.0000 (actual: 3500)
All nodes all cores pstate: 0 -- set core voltage to 1.2370 (actual: 1.2375V)
*** -set parsing completed
Done.
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
PState set to 0
Done.
TurionPowerControl 0.44-rc2+ (trunk-r204)
Turion Power States Optimization and Control - by blackshard
Done.
--------------------------------------------------------------
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 1:36
I see! It's weird that CPU allows any manipulation of ps3 and above but locks
ps0/1/2.
That explains the course of action you chose :) Thank you for your time.
Let me ask you just one more thing -- what is the value of PCI register 18.4
offset 0x15c ?
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 1:52
"setpci -s 00:18.4 15C.l" returns ffffffff.
By the way, i noticed an extra-heating of about 15°C with your sequence while
the APU was idling (about 0% load). The same phenomenum happens when oc'ing
with Pscheck.
Using my way of oc'ing, i don't have this extra heating in idle ...
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 2:21
I see. I'll dig into it a bit.
BTW, did you run setpci as root? ffffffff doesn't seem to fit with the spec at
all (D18F4x15C Core Performance Boost Control) :(
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 2:31
My bad, it returns 8000008d actually under linux. Previous result was from
windows but without admin right.
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 2:54
Strange ... even with admin rights "setpci -s 00:18.4 15C.l" keep returning
ffffffff from Windows ... but i can read 00:18.3 A8 and DC values without any
problem.
Arg ... too much riddles for today.
Thanks anyway for getting rid of the Vcore issue, and keep up the good work ;)
Original comment by loic.po...@gmail.com
on 29 Oct 2014 at 3:37
Thanks :)
Is it 32-bit Windows?
I'm not sure what kind of access method is used by setpci on Windows but
WinRing0 has
issues reading offsets >= 0x100 on 32-bit windows (which unfortunately affects
some
tpc functions on such systems).
Original comment by kszy...@gmail.com
on 29 Oct 2014 at 3:42
That must be the issue as i use 32-bit binaries of pciutils
Original comment by loic.po...@gmail.com
on 30 Oct 2014 at 9:40
I've got side question for you, have you tried changing FID and VID not via
P-states
but using MSRC001_0070 COFVID Control (with PowerNow disabled in the BIOS) ?
I'm wondering if perhaps that isn't the quickest/easiest way to get things done.
TPC doesn't currently support "direct" FID/VID manipulation (via MSRC001_0070)
== one probably would need to use rdmsr/wrmsr (Linux) or RWEverything (or
similar)
on Windows to make changes by hand.
But, if proven, we sure could add "direct" FID/VID manipulation to TPC.
I'll try to run few tests on a CPU that comes with boost P-states unlocked but
I'll
lock them on purpose and then try to see what FID/VID manipulation via
MSRC001_0070
yields.
Original comment by kszy...@gmail.com
on 21 Nov 2014 at 10:26
I made a try, but couldn't access MSRC001_0070 register.
It wasn't listed when looking in the MSR table with RWEverything 64bit on
windows.
And sudo rdmsr MSRC001_0070 returns 0 on linux.
I must be doing something wrong :(
Original comment by loic.po...@gmail.com
on 22 Nov 2014 at 1:50
Ah ! The good syntax was :
sudo rdmsr 0xC0010070
return :
3e017410
Ok, i'll make some test for you
Original comment by loic.po...@gmail.com
on 22 Nov 2014 at 1:54
Cool, just be careful not to drive vcore too high (VID too low)...
You can use --bitfield to ensure only the bits of interest are modified.
Original comment by kszy...@gmail.com
on 22 Nov 2014 at 2:05
Here's my experiments :
$ sudo rdmsr -a 0xC0010070
3e017410
3e017410
3e017410
3e017410
$ sudo wrmsr -a 0xC0010070 3e017411
$ sudo rdmsr -a 0xC0010070
17410
17410
17410
17410
Uhoh ! something messed up ... and FID didn't increased to 11
APM ? Let's see ...
$ sudo ./TurionPowerControl -boostdisable
$ sudo rdmsr -a 0xC0010070
3b009
3b009
3b009
3b009
hmmmmm'kay, it was more or less expected. The leading "3e0" part is still
missing.
$ sudo wrmsr -a 0xC0010070 3e03b00a
$ sudo rdmsr -a 0xC0010070
3b009
3b009
3b009
3b009
Come on ! Don't tell me i broke something ?
$ sudo ./TurionPowerControl -set ps 3 freq 2600
$ sudo rdmsr -a 0xC0010070
3b00a
3b00a
3b00a
3b00a
Ok, seems like TPC is still working.
Original comment by loic.po...@gmail.com
on 22 Nov 2014 at 2:52
The missing part is the NorthBridge's part.
How come, those values get RAZ ?
Original comment by loic.po...@gmail.com
on 22 Nov 2014 at 3:11
Not sure. I should be able to look into this and run tests on my box in about
30 minutes.
Original comment by kszy...@gmail.com
on 22 Nov 2014 at 3:17
Ugh. Seems it will take tad more time. Turns out this CPU is not unlocked like
I previously thought. Will need to find one...
Original comment by kszy...@gmail.com
on 22 Nov 2014 at 5:43
I bought mine really cheap on aliexpress, but the delivery take about two weeks
and the seller doesn't always check the APU before chiping.
Meanwhile, if you need other test i'll be glad to help.
Original comment by loic.po...@gmail.com
on 22 Nov 2014 at 7:59
Original issue reported on code.google.com by
loic.po...@gmail.com
on 9 Oct 2014 at 8:35