ASUS Intel Beta BIOS Releases and Official Support

[Raja@ASUS]

I remember three things asked, but never got the answer:
1. QPI VTT control
2. HPET deactivation
3. SATA firmwares update

"No" is the answer too, but we never got it.

Hi,

Just need the issues not a diatribe, as I cannot read between the lines nor know the outstanding fix requirement for every single product in the wild. If only half of the information is given I need to ask the rest.

What is

1. QPI VTT control?

You need more granularity? The granularity is dependant on the VID table support of the buck controller so what you have now is likely all that can be given.

As for the other two I will ask - that is all I needed.

-Raja

[Raja@ASUS]

Any info on the new updated P8P67-M Pro BIOS? ftp://ftp.asus.com.tw/pub/ASUS/mb/LG...-ASUS-0713.zip

Fix list should be the same as all other P67 updates today but I will confirm.

-Raja

[zoson]

Hi,

1. QPI VTT control?

You need more granularity? The granularity is dependant on the VID table support of the buck controller so what you have now is likely all that can be given.

As for the other two I will ask - that is all I needed.

-Raja

I believe he meant QPI PLL voltage control. It is currently 'bound' to the CPU PLL control, and we have no reference as to what it set with various CPU PLL settings.

[Raja@ASUS]

I believe he meant QPI PLL voltage control. It is currently 'bound' to the CPU PLL control, and we have no reference as to what it set with various CPU PLL settings.

Where did you learn it was bound to CPU PLL? As the DC requirements of both are different, which means you'd needs a secondary regulator on-board to provide the step-down (would have to be a pretty good LDO with a high side feed of only 1.8V).

-Raja

[donmarkoni]

Just need the issues not a diatribe, as I cannot read between the lines nor know the outstanding fix requirement for every single product in the wild. If only half of the information is given I need to ask the rest.

What is
1. QPI VTT control?

You need more granularity? The granularity is dependant on the VID table support of the buck controller so what you have now is likely all that can be given.

As for the other two I will ask - that is all I needed.

I believe he meant QPI PLL voltage control. It is currently 'bound' to the CPU PLL control, and we have no reference as to what it set with various CPU PLL settings.

Where did you learn it was bound to CPU PLL? As the DC requirements of both are different, which means you'd needs a secondary regulator on-board to provide the step-down (would have to be a pretty good LDO with a high side feed of only 1.8V).

-Raja

First thing first, zoson is right, I meant QPI PLL, I am just very tired, so I made a mistake.

Second, we are making a progress we haven't seen in a long time. You just made some things clearer. Nobody took the time and effort until now to give an explanation.
Everybody thought (as zoson and me of course) that QPI PLL is linked to CPU PLL and you are saying that it is not. Please explain us to what is it linked to, if anything.
I could also assume it just might be fixed to default 1.1V and uncontrollable, but that might be wrong as assumption that it's linked to CPU PLL.
So, you get my point? Any answer is a good answer. If we know how things work, we'll make the best of it.

Third, and back to the beginning of your post... diatribe...
I didn't even knew what that means, as English is not my mother language. When I looked in the dictionary I was very disappointed at first, cause you see my criticism in the wrong way.
Look around and find my posts, then judge if my posts are bitter or ironical or non-constructive.
But, for the sake of good relations and constructive talk, I'll just accept that as your subjective experience of my post, and I'll try to be more careful how my posts sound like.

[Raja@ASUS]

Second, we are making a progress we haven't seen in a long time. You just made some things clearer. Nobody took the time and effort until now to give an explanation.
.

It is either going to be using a fixed regulator or possibly linked to IOH voltage (less likely). Either way, if some kind of control were available you'd have had it by now.

-Raja

[donmarkoni]

Either way, if some kind of control were available you'd have had it by now.

That is the honest answer that will be respected by everyone I think.

As for the other two I will ask - that is all I needed.

And thank you for that.

[zoson]

Raja, I asked asus tech support:

[Problem Description]
Is there any way to directly or indirectly control the voltage of QPI PLL on the Rampage 3
Extreme?

And got this reply:

Dear Valued Customer,

Thank you for contacting ASUS Customer Service.

My name is Stacey and it's my pleasure to help you with your problem.

Please enter BIOS>Extreme Tweaker>CPU PLL Voltage to adjust it.
You could contact with me if you have any other questions.

[pr@$r1g]

There is a similar beta BIOS being tested for the WS boards - same fix list as above. Does not say anything about OC changes.

-Raja

Raja is there any possibility of releasing beta bios's to the public as gigabyte does, it somehow feels good playing with different bios.

Any time soon will it be there.

[Raja@ASUS]

Raja is there any possibility of releasing beta bios's to the public as gigabyte does, it somehow feels good playing with different bios.

Any time soon will it be there.

The BIOSes I posted above are beta.

[Raja@ASUS]

Raja, I asked asus tech support:


And got this reply:

She misunderstood what you were asking for as CPU PLL - so disregard it.

-Raja

[danielkza]

@Raja:

Great seeing we're getting some real help from ASUS, so I'll just be opportunistic and ask a question of my own.

I have a P8P67 PRO paired with a 2500K and 2x2GB of G.Skill ECO DDR3-1600 7-8-7-24 1.35V RAM. Booting with a tRCD of 9 at 1866 and over causes an infinite reboot cycle. 'Your RAM simply cannot handle it' you'd say. The catch is, I can boot without problems with a tRCD of 8 at DDR3-1866 1.65V. I tried upping RAM voltage up to 1.7V and VCCIO up to 1.2V to no avail. The only sensible explanation considering the symptoms is a BIOS bug of some sort. Have I mentioned the RAM does not work at stock settings at my board, but runs perfectly on a friend's Biostar TP67XE and on a P7P55D Deluxe?

And last time I upgraded my BIOS from 1305 to 1502 I had to downgrade due to S3 simply being non functional even at stock settings. Were there any other changes in that area in the 16xx series? I really don't want to have to downgrade again.

EDIT: Just did a couple more tests. DDR3-1600 7-8-7-24 works if I give the RAM some more voltage, but 7-9-7-24 causes a reboot cycle. Weird to say the least.

Thank you for your time.

[Raja@ASUS]

@Raja:

Great seeing we're getting some real help from ASUS, so I'll just be opportunistic and ask a question of my own.

I have a P8P67 PRO paired with a 2500K and 2x2GB of G.Skill ECO DDR3-1600 7-8-7-24 1.35V RAM. Booting with a tRCD of 9 at 1866 and over causes an infinite reboot cycle. 'Your RAM simply cannot handle it' you'd say. The catch is, I can boot without problems with a tRCD of 8 at DDR3-1866 1.65V. I tried upping RAM voltage up to 1.7V and VCCIO up to 1.2V to no avail. The only sensible explanation considering the symptoms is a BIOS bug of some sort. Have I mentioned the RAM does not work at stock settings at my board, but runs perfectly on a friend's Biostar TP67XE and on a P7P55D Deluxe?

And last time I upgraded my BIOS from 1305 to 1502 I had to downgrade due to S3 simply being non functional even at stock settings. Were there any other changes in that area in the 16xx series? I really don't want to have to downgrade again.

EDIT: Just did a couple more tests. DDR3-1600 7-8-7-24 works if I give the RAM some more voltage, but 7-9-7-24 causes a reboot cycle. Weird to say the least.

Thank you for your time.

Hi,

Could be a SPD/sub-timing issue. Fill out a BIOS template showing what all the DRAM timings are going to.

The BIOS fixes are listed on the previous page - if there was anything else to mention it would have been in the list.

-Raja

[danielkza]

Will do that, thanks for the help so far.

BTW I just flashed 1606 and I have the S3 issue as with 1502: with the exact same settings I was using without problems in 1305, sleep fails every single time.

I do like the board, but it is one temperamental beast.

[pr@$r1g]

The BIOSes I posted above are beta.

OK good to know. So do u have anything for P8P67 WS Revolution

[brammers]

Running 1606 here (On a B2 Deluxe). Other than the usual re-entering of settings (as the flash util clears CMOS) nothing abnormal to report, yet.

Still running 4.9G @ 1.4v.

All the usual quirks are still present (annoying intermittent several-second pause during POST etc). If anything changes I'll report back.

J

[Raja@ASUS]

OK good to know. So do u have anything for P8P67 WS Revolution

No, I have posted everything I was sent.

-Raja

[danielkza]

I made some small progress. I found out that a tRCD of nine with a CAS Write Latency of 8 over DDR3-1600 causes the reboot cycles. Chaning tCWL to 9 instead causes a hang with the DRAM LED lit up. The other subtimings don't make any difference at all: I relaxed CAS Write Latency, Write Recovery Time and Read to Pre Time up to 12, and DRAM RTL up to 40, and nothing changed. The funny thing is with a tRCD of 10, CAS Write Latency of 9 and above also causes the hang. Maybe it's my RAM after all?

Here are the subtimings set by the board, with XMP and 2133 9-10-9-28, respectively.

* Primary Timings *
DRAM CAS# Latency:       7
DRAM RAS# to CAS# Delay: 8
DRAM RAS# PRE Time:      7
DRAM RAS# ACT Time:      24
DRAM COMMAND Mode:       2

* Secondary Timings *
DRAM RAS# to RAS# Delay:      5
DRAM REF Cycle Time:          88
DRAM Refresh Interval:        6240
DRAM Write Recovery Time:     10
DRAM READ to PRE Time:        6
DRAM FOUR ACT WIN Time:       24
DRAM WRITE to READ Delay:     6
DRAM CKE Minimum pulse width: 4 
DRAM CAS# Write Latency:      7
DRAM RTL(CHA):                D0: 32, D1: 33
DRAM RTL(CHB):                D0: 32, D1: 34

* Primary Timings *
DRAM CAS# Latency:       9
DRAM RAS# to CAS# Delay: 10
DRAM RAS# PRE Time:      9
DRAM RAS# ACT Time:      28
DRAM COMMAND Mode:       2

* Secondary Timings *
DRAM RAS# to RAS# Delay:      7
DRAM REF Cycle Time:          118
DRAM Refresh Interval:        8139
DRAM Write Recovery Time:     10
DRAM READ to PRE Time:        9
DRAM FOUR ACT WIN Time:       33
DRAM WRITE to READ Delay:     9
DRAM CKE Minimum pulse width: 6 
DRAM CAS# Write Latency:      8
DRAM RTL(CHA):                D0: 32, D1: 39
DRAM RTL(CHB):                D0: 32, D1: 40

[Raja@ASUS]

I made some small progress. I found out that a tRCD of nine with a CAS Write Latency of 8 over DDR3-1600 causes the reboot cycles. Chaning tCWL to 9 instead causes a hang with the DRAM LED lit up. The other subtimings don't make any difference at all: I relaxed CAS Write Latency, Write Recovery Time and Read to Pre Time up to 12, and DRAM RTL up to 40, and nothing changed. The funny thing is with a tRCD of 10, CAS Write Latency of 9 and above also causes the hang. Maybe it's my RAM after all?

Here are the subtimings set by the board, with XMP and 2133 9-10-9-28, respectively.

* Primary Timings *
DRAM CAS# Latency:       7
DRAM RAS# to CAS# Delay: 8
DRAM RAS# PRE Time:      7
DRAM RAS# ACT Time:      24
DRAM COMMAND Mode:       2

* Secondary Timings *
DRAM RAS# to RAS# Delay:      5
DRAM REF Cycle Time:          88
DRAM Refresh Interval:        6240
DRAM Write Recovery Time:     10
DRAM READ to PRE Time:        6
DRAM FOUR ACT WIN Time:       24
DRAM WRITE to READ Delay:     6
DRAM CKE Minimum pulse width: 4 
DRAM CAS# Write Latency:      7
DRAM RTL(CHA):                D0: 32, D1: 33
DRAM RTL(CHB):                D0: 32, D1: 34

* Primary Timings *
DRAM CAS# Latency:       9
DRAM RAS# to CAS# Delay: 10
DRAM RAS# PRE Time:      9
DRAM RAS# ACT Time:      28
DRAM COMMAND Mode:       2

* Secondary Timings *
DRAM RAS# to RAS# Delay:      7
DRAM REF Cycle Time:          118
DRAM Refresh Interval:        8139
DRAM Write Recovery Time:     10
DRAM READ to PRE Time:        9
DRAM FOUR ACT WIN Time:       33
DRAM WRITE to READ Delay:     9
DRAM CKE Minimum pulse width: 6 
DRAM CAS# Write Latency:      8
DRAM RTL(CHA):                D0: 32, D1: 39
DRAM RTL(CHB):                D0: 32, D1: 40

What slots are you using??

At DDR3-2133 you'd definitely need a tWR of 12. Can you get the DRAM 100% stable at any frequency timing combo? What's it like at DDR3-1333 with 7-8-7-20 2N timings (super slack I know)? Just want to see where it's stable and where it falls over.

Also, can you list your third set of timings please?

-Raja

[danielkza]

I'm using slots A2 and B2 as recommended in the manual for 2 DIMMs.

Surprisingly the 9-10-9-28 setting I just posted is stable for 12h Prime Blend, even with a (automatic) tWR of 10. I tried setting the tWR to 12 at tRCD 9 again, and it doesn't change much: with CAS Write Latency of 8 or less I get a reboot cycle, of 9 or more hang at DRAM LED. I'll try 1333 7-8-7-20 latter and post my results.

BTW, it's great to get support from people that really know their stuff, and in my favorite forum. ASUS just got a couple more points in my book.

Here are the automatically set third timings for XMP 1600 7-8-7-24-2N and 2133 9-10-9-28, respectively.

* Third timings *
tWRDR(DD): 1
tRWDR(DD): 3
tRWSR:     3
tRR(DD):   3
tRR(DR):   1
tRRSR:     4
tWW(DD):   3
tWW(DR):   3
tWWSR:     4

* Third timings *
tWRDR(DD): 1
tRWDR(DD): 4
tRWSR:     4
tRR(DD):   3
tRR(DR):   1
tRRSR:     4
tWW(DD):   3
tWW(DR):   3
tWWSR:     4

[Raja@ASUS]

Thanks, looks like you need to keep a one clock spacing between CAS and tRCD - I think there is an SPD~BIOS issue when you set tRCD and CAS two clocks apart (so it seems). How does the same ram overclock in the Biostar board, do you have any CAS~tRCD spacing POST issues? I think the Eco sticks use Elpida BBSE type variants, which don't like tRCD too tight, although a two clock spacing should be possible.

[danielkza]

With the Biostar board I just enable XMP and it works perfectly at 1.35V (20min Prime95 blend). That was the only stress test I managed to do (since I was doing a build for a friend that doesn't really like to have his computer lying 'naked' on the desk. Some people are just no fun ), but I did get to boot at 2133 8-9-8-28.

And I believe ECOs are (reasonably binned) PSC chips like most G.Skill kits these days. If I had other kits around I'd take the heatspreader out and discover it myself, but my current budget is kind of non-existing.

EDIT: Just tested 1333 7-8-7-20N and it's stable for 1:30h Prime blend at 1.35V, with all subtimings at auto.

[amdsempron_xs]

Hi Raja,

I need your help here.

I have 2600K, P8P67 Pro (BIOS 1502) and Corsair DDR3-1866 7-8-7 Ver2.1 (Elpida Hyper confirmed).

The issue is it can't do DDR3-2133 with both 7-7-7 and 8-8-8 event at 1.75V

This Corsair kit is able to do DDR3-2133 8-8-8 at 1.675V on Gigabyte P67A-UD7.

I'm pretty this is the BIOS issue.

Do you have a beta BIOS for this issue already?

Thanks.

[Raja@ASUS]

Hi Raja,

I need your help here.

I have 2600K, P8P67 Pro (BIOS 1502) and Corsair DDR3-1866 7-8-7 Ver2.1 (Elpida Hyper confirmed).

The issue is it can't do DDR3-2133 with both 7-7-7 and 8-8-8 event at 1.75V

This Corsair kit is able to do DDR3-2133 8-8-8 at 1.675V on Gigabyte P67A-UD7.

I'm pretty this is the BIOS issue.

Do you have a beta BIOS for this issue already?

Thanks.

It's not BIOS per se. Some kits do better on some boards than others depending upon the PCB used. Here's my Corsair DDR3-2200 8-8-8-24 Rev kit 2.1 doing 8-8-8-20 (1485 or 1407):

http://imageshack.us/m/860/6121/mive32m5734.jpg at 1.67V or so on the MIVE


There is no BIOS fix for Hyper kits that don't work well.

-Raja

[amdsempron_xs]

It's not BIOS per se. Some kits do better on some boards than others depending upon the PCB used. Here's my Corsair DDR3-2200 8-8-8-24 Rev kit 2.1 doing 8-8-8-20 (1485 or 1407):

_http://imageshack.us/m/860/6121/mive32m5734.jpg at 1.67V or so on the MIVE


There is no BIOS fix for Hyper kits that don't work well.

-Raja

Did searching around, no hope

I'll return that kit and get a BBSE kit.

Thanks for your reply.