• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

GB 5970 OC Bios issues

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
Hello Baggzlash, I am back again with an ongoing RBE issue (for me at least).

I have 2 5870's, and now a 5970 (all Gigabyte).
When I tried modding the 5870's the overclocking aspects were fine, but if I touched the Fan settings there would be issues. The cards would overheat and lock up if they did not get into Windows soon enough. eg If you stop at the M/B BIOS, or even if it would just take too long to make it into Windows - to probably the point where the ATI driver is loaded.
Marginal on every full reboot... 2 out of 4 times it would be too slow and lock up.
Once overheated you have to power off for about 1 minute at least, so the next try might get through in time!
But as long as you did make it into Windows, all was totally fine and the new fan mappings work great and exactly as expected. (So I just use SLEEP always to keep away from the startup problem).

So that was one weird spin off from editing with RBE.

On the 5970, if I take an original Core1 BIOS (slave) and even just save it back out with no changes, it loses a few of the 'info' lines. eg the 'blah blah Slave blah blah'.
Someone else posted some issues (same thing) about AtiFlash showing missing info in the new BIOS flashed. And this causes the driver to not work in Windows - Device Manager will show the 2nd (slave) "video card" (GPU) failed to start. You can never get it to work. Go back to the original BIOS and it all works fine again.

This occurs on any BIOS (GB, Sapp, XFX, ASUS). Flash back to an original Slave BIOS, of any type, and it works again.
So RBE must be messing somethng up in that Slave BIOS file.
But the MASTER BIOS is totally fine. I can mix an edited Master with an Original Slave and it is fine.

Boo hoo... this is messing up my need to alter the mem voltage (for both GPU's).
Any ideas?
Thanks.
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
I will post a few later tonight when I get home. (I am using RBE V1.25 of course)

Last night I actually finally (the first time for the 5970) got to edit a 5970 BIOS that does everything I set in it - though it still has the blank info - but it runs. All others with the blank info could not be used. This was based off the latest Sapphire BIOS (V126), even though all others tried were V126 based (XFX various, GB) too.

All types, if untouched by my editing here, work fine. Even ones from other people posting OC etc ones. But if I just load and save it - it gets blank info and then does not work. The Master side seems ok though.
I even flashed a double Master last week, by mistake, and that worked fine as far as I could tell, LOL. But I was a bit worried about what it might be doing, so I promptly flashed it back to original Master/Slave.
 

BAGZZlash

RBE Author
Joined
Mar 9, 2008
Messages
587 (0.10/day)
Dude, please post the original BIOSes. How am I supposed to test with the pre-edited ones?
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
There is also another odd quirk....

Core1 starts at 157/300 at the desktop, then something trips it to go to 735/1010 and stay there - according to GPU-Z (probably some desktop use triggers a higher clock mode).
But 735/1010 is not in the BIOS table. And I can't find it in any Ati profile. Core0 never goes to that speed.
But that 735/1010 speed is the Sapphire BIOS default and I have run that when I first got it.

Is it really running at that? Or could it be some reporting error (GPU-Z?).
Note the VDDCA is 0.9A for Core1, and Core0 running at 400/1150 is using 2.6A, so that seems too low for Core1 if it is really running at 735/1010.

I also just noted that the VDDCA for Core1 does not change at all when it goes from 157/300 to 735/1010, so that again suggests it never is really going to the higher speed that GPU-Z indicates.
Though MSI AB also shows the speed increase in its charts. Which I guess they both read it from the same source, via the driver or BIOS? Making it seems the ATI part of the chain is the possible error part.

 
Last edited:

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
Further info on the desktop clocks....

I changed Clock 1 to 400/1150
00 875/1150
01 400/1150
02 550/1150
03 400/900 (left it as it came)
04 400/1150

Cleared ATI profiles.
When you boot up the desktop is 400/1150. After some point it will be tripped to 735/1010
If I run MSI Kombuster, just to the inital control screen, the clock goes to 400/1150 and will stay there. After closing MSI-K it will eventually go back to 735/1010 again.

Weird that the first boot into Windows did go to 400/1150 and not 735/1010 which seems to be where it goes always after that while.
And I still have no idea where the 735/1010 is even coming from! I can't find it anywhere.
 

BAGZZlash

RBE Author
Joined
Mar 9, 2008
Messages
587 (0.10/day)
Okay, here's what I did: I took the two unchanged slave BIOSes you posted.

First, I opened them in RBE and immediately saved them back without changes. Afterwards, I loaded the so-produced "mod"-file into a hex editor as well as the unchanged original. Then I used the hex editor's binary compare feature which reported that both files were identical.

Second, i loaded the originals into RBE again and changed some clock setting. Again, I compared the so-produced files to the original ones. There were three bytes changed: Two for the clock settings and one for the checksum levelling algorithm.

After all, I did not find any evidence that could explain any information loss in the BIOSes themselves. Could you post screenshots of these information losses?
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
I will take a pic sometime later and post it - it is at the Atiflash DOS screen (boot from USB).
I saw someone else in the forums here posted the same issue (they posted pics of the DOS screen).
Basically two fields, where Atiflash says Old, then New, and the names/info of the version or vendor or something, are blank.
If you had a 'good' complete BIOS the New portion shows info there, but if it was an edited one it is blank.

If you flash a 'good' (original?) one after the prior one had the blank info, then Old is blank and the New is complete - showing that Atiflash had read the current (edited) BIOS from the card at that time and saw those areas as blank. eg out of the BIOS ROM, not the new file that does have it now. So that pretty mch proves a BIOS with blank fields is actually saved to the BIOS ROM (from that flash time before)
.
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
This is a pic of the DOS flashing screen, going from having the original BIOS to an edited Sapphire version. Note how the "New Product Name" and "New BIOS Version" go to blank fields. But viewed in RBE they show the information still.
Only the Core1 BIOS part does this.

If I edit ANY Core1 BIOS it ends up with the blank fields. Even if I just load it into RBE and save it with no changes.

 

BAGZZlash

RBE Author
Joined
Mar 9, 2008
Messages
587 (0.10/day)
Hum, hard to tell. It sure does not come from the BIOS directly. As I wrote before, there are no unwanted changes in the file. Convince yourself of it by using a Hexeditor. So I just don't know what causes this.
When you flash such a BIOS anyway and reflash the original BIOS afterwards, does ATIFlash still display these lines (but just the other way around)?
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
Yes. Re-flash an original BIOS (any type - Ati, MSI, Spahhire etc) and they show there is the correct info there, but edit any and flash those and they have blank for the Slave (Core1).
It is only an issue with Core1 BIOSes. Thus not seen in 5870's - single cards. Only Dual GPU.

There must be SOMETHING different. Even if just one byte. Or maybe how Atiflash toakes a *.rom versus *.bin (most originals are bin - whatever that difference is).
Yeah, I just checked... every original I have is a BIN. But RBE always saves out a ROM. Even though Atiflash does not care what filename or extension you rename anything to.

Is there a difference in the ROM and BIN format? Header or something? And Atiflash being fussy about that aspect, so even though content of the actual BIOS data is totally fine, the format of the file (ROM) is messing with Atiflash.
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
FOUND something.....

I decided to do a string of step by step BIOS flashing tests.

The info 'disappears' if you edit the Mode 1 Mem Clock - by an amount 'too much' higher (higher than what?) - if the Mode 1 GPU 3D clock is too low.
eg The usual default GPU 2 clock is 157MHz and the mem clock 1000. If you go to mem clock 1100, but leave GPU at 157, that info stuff disappears for the flashing!
Move the GPU clock higher, say 400MHz, and the next flash the info will work again!

It is only in the Mode 1 pair... others have 'closer' values (like Mode 3 at 400, 1100 anyway), so you won't really strike it in any other Mode except Mode 1.

So is this a bug that RBE 'inserts' if those relative values are used?
It would seem possible that some padding is not being done right for the very 'low'' GPU value of 157, and if the mem clock is high enough to tie in with that string of values they produce? I have no idea what sizes the data are etc, or how dynamic, so I can't check.

To test:
Do one BIOS for Mode 1 157/1000 and edit it to 400/1100, and see what might go astray in it.

There might even be more to it than this, but I expect it will just be the one specific situation of being these two values and something relative between them.
 
Last edited:

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
My hex checking:

Changing just Mode 2 mem clock to 1110, with GPU Mode at 157 - comparing against a 'working info' Mode 2 mem clock 1010 (Sapphire original):

Core 0 BIOS:
There are only 5 byte changes made.

b841,2,3 go from 30,75,00 to 88,8a,01

f295,6 go from 31,ff to 00, c2

Should two areas change? It looks ok to me in logical terms.


Core 1 BIOS:
Again, 5 bytes are changed.

0007 goes from 00 to 01 <---- this looks to be the culprit?? It is near the info areas.

7063,4,5 go from 30.75.00 to 88,8a,01 <--- same changes as the Core0 BIOS

a9af goes from FF to 90 <---- this looks possibly dubious as it is not far into a large ladding area of FF's, so the lone 90 looks astray in there.
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
http://www.mediafire.com/file/3egg8v47477zaz6/Sapphire V126 Edits.rar

The Rar holds enough test points to check things. It has a few tests from T7 to T11
Each T version keep the prior item that was changed.

T1 changed only the Mode 0 GPU volts. (up to 1.1625)
T2 Upped the Mode 0 GPU clock to 900. (up from 725)
T3 upped the Mode 0 mem volt only (to 1.15)
T4 uppped the Mode 0 mem clock to 1110 and it lost the fields info at that point.

So as I came up through the edits, test 4 failed... then I 'side-stepped' to a working T7 (back to the default Sapphire mem clocks), which I branched out to four further tests. T8, T9,10 & 11.
T7 was T3, but had upped ALL mem volts to 1.15 (and worked)

T8 & T9 failed, whilst T10 & 11 were fine.
T8 raised mem clocks for Mode 1 & 3 to 1010 (so then all clocks were 1010 - mode 1 had been 300, and mode 3 had been 900. Note mode 1 had been initially 'closer' to the 157 GPU clock (157/300.. upped to 157,1010)
T9 only increased the Mode 1 mem clock to 1110 - whilst not touching the Mode 1 GPU clock (or anything else)".
T10 was to only increase the Mode 3 mem clock to 1110 - passed.
T11 was to raise both Mode 1 and 3 mem clocks to 1110, but also to increase the Mode 1 clock from 157 to 400.. which then made it work too.
So it seems that keeping the GPU clock "within some range, or ratio" of the mem clock is what keeps it all working fine (ie having the info fields).

Hex comparing T7 to T9 is useful. (listed in the prior post)
And then probably T7 to T11, and T9 to T11 (for cross references of what is possibly going on).
 
Last edited:

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
The change of byte 0007 going from 00 to 01, which occured in the failed T9 BIOS, also occured in the WORKING T11 BIOS. So that change is actually not an issue.

Then the a9af change from FF to 90 in the failed T9, is also changed in the working T11, but to 45 this time. So that suggest that a9af change is also not the real issue. DOH.

Or rather, they are obviously valid to change, but have they been changed to valid values?
The 0007 going from 00 to 01 in both cases would seem to be acceptable (not guaranteed though).
The a9af going from one being 90 (but not working) to 45 (working), cannot be worked out just by the number values.... so it ends up being the most likely location tied into the issue.
Possibly... lol

Anyway, hopefully you know what is what with some more accuray, to work it out.
 
Last edited:

BAGZZlash

RBE Author
Joined
Mar 9, 2008
Messages
587 (0.10/day)
Is there a difference in the ROM and BIN format?
In short: No.
Long version: No, there isn't, it's just a naming thing.

My hex checking:

Changing just Mode 2 mem clock to 1110, with GPU Mode at 157 - comparing against a 'working info' Mode 2 mem clock 1010 (Sapphire original):

Core 0 BIOS:
There are only 5 byte changes made.

b841,2,3 go from 30,75,00 to 88,8a,01

f295,6 go from 31,ff to 00, c2

Should two areas change? It looks ok to me in logical terms.


Core 1 BIOS:
Again, 5 bytes are changed.

0007 goes from 00 to 01 <---- this looks to be the culprit?? It is near the info areas.

7063,4,5 go from 30.75.00 to 88,8a,01 <--- same changes as the Core0 BIOS

a9af goes from FF to 90 <---- this looks possibly dubious as it is not far into a large ladding area of FF's, so the lone 90 looks astray in there.

Jep, got similar results. The FF's around the end area of the BIOS are for levelling the checksum up, the 00's at the starting area are for levelling down. Completly well-established algorithm, nothing wrong with it.
The changes in the middle area (usually around 0x700 to 0xB00) are for the actual clock settings. As you have seen for yourself in the hexeditor, the BIOS info strings are nowhere near that area.
So still, I have no clue what causes this, sorry... :eek:
 

PeterV

New Member
Joined
Jun 28, 2010
Messages
23 (0.00/day)
Can you tell me how the GPU voltage register table ties in with the individual clocks per Mode?
The table has only 4 values, but you could have a card with 5 or 6 modes.
I have read that whatever you put into the mode voltage, it checks the table for the closest match voltage and will use that. Is that exactly right?

How come some BIOSes have the Mode 0 voltage as --
What voltage will it pick then? It seems to end up at the 0x18 value.

So maybe the exact manner voltages are applied is not quite so simple as "grabs the closest one from the table to what the Mode had listed as requested?
Or maybe -- means use the max value in the table?

So far I haven't seen a posted (orig or edited) BIOS that has more than 4 different voltages in the Modes. eg even if 6 modes, still only 4 different voltages in total.
Do you know what happens if 5 different ones are listed? I would guess it still just grabs whatever is closest in the table of 4. Or maybe it would just go ga-ga in some manner?

All I know in the end is that many end results fail, for the many tested clock and voltages used. Whereas you would think that all combinations would work, as long as the GPU/mem voltage was adequate for the speed. I mean setting realistic clocks and voltages.... but they can fail just from things like 400/1100 with 1.0v/1.15v set for that mode. Whilst 500/1100 could work. (not work as in Windows bluescreen at about the desktop - probably when it gets to loading ATI CCC it seems to me).
Which makes it seems there is some form of interaction of voltages and clocks, based on who knows what (ratio, multiplications, additions etc), and thus those certain combinations don't work.

A working BIOS (ignoring the blank Core1 info, which doesn't seem to bother it anyway) can become a bluescreen BIOS by just changing one clock (eg that 400MHz to be 300MHz etc). But can work if the clock is set to something else. (eg 400 set to 550).
So something a bit more involved is going on then those values being just pure 'programmable items'.

Then the fan area.....
That is even more unpredictable as to what the fans will really finally do after editing it.
It looks straightforward, but never seems to work out as per the curve suggests should happen.
 
Top