Crosshair VII Hero Essential Info Thread

[mindbender33]

@mindbender33

No problem .

@HiVizMan

No chap you did not understand me on this .

Usually I don't need to press the + / - hundred times as then would opt to type the voltage in . I opt to use the + / - when just testing if a step or so is what I need. I only stated both methods as it seemed member was unaware how the UEFI setting is used for input .

I do not usually do CMOSCLR, reason being I use Flashback . I don't use OS / UEFI UEFI update menu . I prefer Flashback as it is being done without system being powered, so let's say you did have flakey profile / hardware your UEFI flash is not going to be affected by it.

Flashback method uses an IC on the motherboard to flash the BIOS chip, it is essentially a hardwired hardware flash tool . As the BIOS chip would have been erased and flashed with new UEFI why would I wish to do CMOSCLR? Only time I usually consider it, is if I was having a real ball ache of time with something and wanted to exhaust all possibilities before investigating something else.

There are other benefits of Flashback which are handy .

i) It can allow you to flash a beta / older UEFI which may be blocked by other methods.
ii) It can allow you to flash unsigned modded UEFI if you wanted to.

I always look to see if a board supports flashback TBH, as value it .

I see I didn't really explain why I cleared the CMOS. I installed new RAM and a new, different video card at the same time. I did not try to boot before clearing the CMOS. Perhaps I should have? Is there a better thing to do?
As for when I mentioned flashing the BIOS, I have only done it once and that was to make sure my board could handle the 2nd gen Ryzen.

I hope this reply doesn't sound "smart ass-y" because it is not intended that way at all. I seriously want to learn and sometimes people take me wrong. Thank you to everyone for the replies and help. I am so glad to find this thread. I am in the process of reading it in its entirety. There are a lot of very smart, helpful people here!

[Dicehunter]

I'm curious to know why the downloads page for drivers for the CH7 keeps disappearing.

[Silent Scone@ROG]

Hi, please find below links for BETA UEFI 1103. Please note this BIOS is for testing only and has yet to be validated.

CH7 1103 - Link

CH7 1103 WIFI - Link


Changes: Agesa 1006

[gupsterg]

Been working well for me .

I had noted the UEFI's with AGESA 1.0.0.6 seem to not any more allow manual tweaks of PBO, this seems is down to AMD AGESA removing the options , this post by The Stilt confirms it.

Another great post is in regard to XMP on AMD boards, link. AGESA 1.0.0.6 also has an option called SPD Read Optimization, this is enabled by default; so full SPD is not read. To me it seems quite a bit of lock out exists on platform, The Stilt shared this info a little while back, link. Looking at it overall I reckon very little of a XMP profile is used, as even when I usually select D.O.C.P some of the timings which exist in profile are not applied, but more like defaults that AMD AGESA is dictating based on RAM density, frequency, etc.

Another thing that has sorta perplexed me on C7H is how ProcODT 48 seems right for 2x8GB SS/SR and 4x8GB SS/SR. Again a share by The Stilt verifies that this is not unusual when compared with experience of X370/X399, link.

Recently another unusual fix has resolved trying to nail POST to POST stability for say 3333MHz C14 1T on 4x8GB. Matching VDDP and CLDO_VDDP allowed no deterioration in stability on 6+ consecutive warm POSTs. Default is 0.900V for VDDP and 950mV for CLDO_VDDP, using 0.915V and 915mV has worked brilliantly for my combined hardware/targetted settings.

All in all pretty happy with C7H. Only a little disappointed that ASUS T-Topology was phased out from it, but reading what The Stilt has stated daisy chain may actually be better due to AMD locking out board makers from tuning aspects. VTTDDR and VDDP both have less granularity for settable voltages on C7H vs C6H, dunno if a biggie, but I prefer all options to be open.

[Dicehunter]

Just curious but why was the latest chipset driver removed from the downloads page ? Did a fresh install of windows and now have to use an older driver.

[gupsterg]

No idea. Personally I'd stick to using the ones off AMD site. I doubt you lost any performance/stability, etc and really don't think the new ones would have given any substantial gains.

X470 wasn't some large jump in chipset IMO, so as it's very very similar to X370 we've probably had very decent drivers for it from the get go. Any of these driver changes have probably been bug fixes which you may or may not be experiencing.

The big change in the chipset will be in the power consumption. Currently the X370 chipset, built on a 55nm manufacturing process using ASMedia IP, runs at a 6.8W TDP (running at full load). For X470, we were told that this is the same process and IP, but the chip will now run at 4.8W peak and 1.9W in an idle mode. This is due to an improved power infrastructure within the chip, and AMD also claims that overall throughput is improved. The chipset firmware is also set to provide better memory OC support and stability.

The other factor in this is StoreMI, on the next page. This new feature technically does not require chipset support, however the free installer will check for the presence of an X470 chipset before providing a free license, otherwise the software will cost $20 and not have AMD branding

Quote source link.

[darkspr1te]

I Was wondering if anyone had looked into what effect bios versions have on your overall system performance.
I ask as I got my board November 2018, odly enough with a 0207 version bios, combined with corsair h100i cooler and
ryzen 2700x cpu. The out of box CB15 results were 1764 and 1827 with o/c as provided by gupsterg in the first few posts
give or take a few mistakes or omissions.
As I got further along the bios timeline my results worsen quite a lot to the point where a
out of box result is around 1690-/+ and a mild overclock will yield upto 1710-/+.
Silicon lottery aside what sort of results do people get for their default goto bios version,
This kind of information seems to be hard to find and often buried in multiple posts of assumptions, misinformation and
re-posts are just the start.
I have also noticed al lost of posts where users say " oh i just got cpu at 1.4 and neg of 0.05 and pe of 2, i get 1950 on CB15",
iám a smart fellow but i've not read up on overclocking terminology of late, I do understand it when i can get a explanation
of the settings effect/proper name,it's another case of too many TLA's.
It would be nice to have bios version, a export of the settings in both cmo format and text
(asus profile, load/save then press F2 for the direct loadable BIOS setting profile and CTRL+F2 for a text file while can help you transfer you settings to the next revision)
, this would give some users a place to at least start , AMD seems to have more menu per mile than i've ever seem intel side
even in hacked bios systems

In Order to help I have downloaded every bios version available for this board and i am flashing via a EEPROM programmer,
this is the only way i can assure myself there is no left over bios residue.
I will also video the Q-Code/video and board for first time boot, this may help users decide if they are having training issues
or it's just this bios is slow (1002 is much faster as base boot than 0507). Some bios do different things at boot too, some will
reboot at the point of loading eufi files, other skip that step but will display "flashing bios" just after a fresh flash via
bios ez-flash. Some bios have quirks, example is V1002 will allow me to apply a 3600Mhz DOCP PE2 profile from first boot but
other bios versions require me to have booted a clean O/c free bios into windows at least once before i apply a O/C of any type.
(Q-Code F9/power off is a sign of this)



Another thing i'am looking at is a simple app to import a text bios export and display only the changes needed from default
aka "optimized defaults" or cmos reset, i would love some info on the bios's cmo file just to read basic info like which version
bios created it but alas info on that file is thin on the ground and i also think different bios versions will almost have
different file format.

any feedback is most welcome, if any export feels it wont yield any worthwhile information the it would be a dead project from the start



Reference Info

02/03/2018 Bios 0207

Initial release

16/03/2018 Bios 0401
19/04/2018 Bios 0509

Update AGESA 1.0.0.2a

18/05/2018 Bios 0601

1. Update SMU Firmware to version 43.18.0
2. Update RAID driver to version 9.2.0.41.
3. Update Asus Grid notification behavior

22/06/2018 Bios 0702

Update Agesa Code to 1.0.0.2c.
Update compatibility protocol for 3rd party hardware monitoring software.
Fixed miscellaneous issues with fan calibration/options.
Improve memory compatibility.

24/07/2018 Bios 0804

1. Improve system stability
2. Improve Secure Erase function on NVMe devices
3. Update LPPT firmware

02/11/2018 Bios 1002
30/11/2018 Bios 1103

1. Update AMD AGESA version to 1.0.0.6
2. Improve system stability

04/01/2018 Bios 1201

darkspr1te

[gupsterg]

Each UEFI contains CPU microcode, SMU & IMC firmware and embedded controller firmware (ie Super IO chip, RGB control chip, Keybot, etc).

When a new UEFI is flashed, system POST and you see the usual enter UEFI settings menu message, after entering/changing settings/saving or not saving and exiting for that very first time you will experience a re-POST on next POST of system. I believe at that time CPU firmware is checked/applied as needed.

When a new UEFI is flashed and on POST you see the message do not turn off PC blah blah blah, at that time Super IO firmware will be updating. When it is the RGB firmware it does have that within in text, IIRC stated LED Firmware.

You can see on the mobo page details of firmware related to mobo, link.

You can see CPU microcode changes within the CPU menu on Advanced page, link.

Some OS software (like HWINFO) can also show AGESA/CPU/SMU firmware info, link 1, link 2.

I have used 3 differing 2700X, using the CPO_Test that The Stilt shared with C7H thread on OCN I gained some insight into best/worse core VCORE usage, link. The clock is set as such on system as the test expires after x date.

The CPUs with tight variance (ie 1805 SUS & 1835 PGS) need higher VID/VCORE for manual OC than loose variance (1825 SUS). Under stock operation 1805 SUS had lowest average all cores boost, 1835 PGS was only about ~25MHz away from best, which was 1825 SUS.

So differing CPUs may exhibit differing MHz. Next I noted how CPU 1835 PGS reacted to Precision Boost Overdrive being enabled (PE: Default PBO: Enabled). It had a lower average all cores boost and voltage on AGESA 1.0.0.2C UEFI than AGESA 1.0.0.6. The latter had enhanced clocks with greater voltage. Only way AGESA 1.0.0.2C UEFI would match it was if I applied scalar adjustment to allow greater voltage. So some CPUs may react differently to AGESA 1.0.0.6 UEFI, others may not, as 1825 SUS behaves the same regardless.

[cah4e3]

CH7+Aura terminal+Claymore+Pugio+Fusion 700 - if you connect all @aura sync, LAGS ARE GONE!
10x - you finally fixed it =)

[darkspr1te]

Hi All,
For those that want to play with the ROG_EXT connector I have released a working proof of concept to connect to the ROG_EXT using any dev board, no you dont need the silly adapter from Elmor labs, thats snake oil . Any device that can read i2c will work.

See my github Darkspr1te's ROG EYE

Readme.md has the pinouts known so far, there's more too come that i've not made public yet, thats so users don''t blow up their cpu like i already did once.

We already know there's reset/power available via the connector but i've not implemented that yet due to isolation concerns, USB passthrough is not supported, thats just a HUB on the USB lines anyway and not the purpose of this project.

Switching OC profiles is also not implemented yet, again due to user damage concerns. However by the time the project reaches V1 it will be there.

If there is demand i might even throw together a PCB design so users can hide the lcd anywhere and display/control their boards.

This code also support Intel boards as of current patch.





Happy Overclock Watching


darkspr1te