But lets say that we get a working solution that by using hardware JTAG-programmers, you can unlock a cpu. Then what? Would we all build those devies or would we send our cpu:s across the world to be unlocked?
Would AMD try to shoot us all?
Printable View
But lets say that we get a working solution that by using hardware JTAG-programmers, you can unlock a cpu. Then what? Would we all build those devies or would we send our cpu:s across the world to be unlocked?
Would AMD try to shoot us all?
Hey there Warship!
Looks like u've got kinda nice ideas.
But some say that it's impossible to tamper with the registers.
Maybe in a little while we see cpu flashing tools written by warship who worships warships!
Go on. Any other ideas?
BTW no pin mod possible with venice?
I that case AMD tries to hang us. Then we will become Extreme Overclockers.
Mehran: Well, as I see it there are 2 possible ways AMD could have made it "impossible" to change the values.
1. They fried the JTAG-port before they shipped the CPU.
2. They have specced some registers as read-onyl, which would mean that they won't let us tamper with some registers individually, HOWEVER, in that case, I think there's a big chance we'll be able to flash ALL registers at the same time, instead of just fiddling with MAX_MULTI on it's own.
So my hope now stands to Tin-EOF, so we can see wether the JTAG-interface on the cpus is in order or not.
You won't be able to flash the CPU in a mainboard where the CPU is operating as the main CPU.Quote:
Originally Posted by Mehran
As for the actual procedure, the main problem is fiding out which register contains the setting you want to change.
That is probably most easily done by diffing a complete register dump from a 3200+ and a 3000+ which should be almost identical except for the max multiplier, and other sections that you should be able to identify by their memory contents in a hexdump.
I don't think AMD has an legal basis to prevent anybody from doing so, if you legally bought both CPUs you can do whatever the heck you want with them.
Your right. It's maybe possible to flash all registers.Quote:
Originally Posted by Warship
And about the first one, I don't think thats true. I mean I just don't think thats true. At least some CPUs I think are the same as each other. like in 6800nu and le. They r the same just diffrent in pipelines and speeds.
Or lets say about those duron processors with a disabled cache. U can easily open the fried cache and use it as a regular Athlon XP.
So, u maybe run a 3000 at x10 and use it just as a 3200.
What do u say?
BTW some kinda irrelevant thing! It's just a question and it's not the right place to ask. Does super Pi run faster on Intel machines?
A guy sent me a screenshot of it runnig it on an Intel machine (3.2GHz LGA775 1MB L2) and it finnished 1M calculation within 17 seconds! :eek: AND without overclocking!
I can hardly finish it under 30s even with overclocking.
Why is that?
Yeah u r actually right.Quote:
Originally Posted by Martin Cracauer
But I have a question here.
How does programs like CBI and CPUID change cpu string?
For example from AMD Athlon(tm)...... to ABC team?!
They operate while the CPU is on the board.
This guy smokes a lot :rolleyes:Quote:
Originally Posted by Mehran
Cheating on SuperPI makes baby Jeebus cry. He's a fake lamer, kill it!Quote:
Originally Posted by Mehran
Seriously, though, I think you guys are great. I hope, when I've got enough money, I can unlock my new 3800+ CPU with the excellent guide you most certainly will produce. :)
Goddamnit, are we going to start this discussion all over again?
Warship and others: READ THE TOPIC!
We've been all over this.
1 - Interfacing with the JTAG interface is easy
2 - Without specs provided by AMD you can't do anything with the JTAG interface
3 - The JTAG interface is nothing new, it has been on AMD's as well as Intel's chips for ever
4 - I use JTAG interfaces every day to repair dead PDAs, without the correct values for the shift registers you have no idea what hardware you are talking to inside the chip and no idea what the h*ll you are telling it to do.
5 - I measured the clock line of the JTAG interface shorted to ground, trying to interface with it will prolly kill something
In short: Don't expect the JTAG interface to be any help... Don't speculate it only gives people false hope. Just try to expiriment with the JTAG interface and try sending some data to it, maybe you'll get lucky.
If you read this topic you'll see I've posted JTAG interface schematics + pin specifications for A64 CPUs (939 as well as 754) so you can interface with the CPU for about 5 dollars worth of equipment.
Chances are very very great AMD just had a error in one of the processing machines for certain batches. Allowing some of those CPUs to get unlocked under certain conditions. Be sure the error has been spotted and has since be fixed.
Since we don't know what batch numbers they were (I found only one batch number, you need more to prove anything) you have no way of telling your CPU will become unlocked.
If we are talking about 300 CPUs only 3 or 4 people will notice their CPU being unlocked and will post it here. Since we've already seen 2 it's unlikely there will be more.
I don't say you shouldn't try, but as I've said earlier it isn't helpfull to reply in this topic if you are not trying something out or have thought of something new.
Repeating the same questions and discussions is utterly useless...
Also for people that haven't figured it out:
Changing the CPU name string has absolutely nothing to do with unlocking the CPU. All it is is a string in the flash memory on the CPU. Even if you can change it in the CPU itself it will not change the multiplier.
For people saying thing like "reading the JTAG" etc.
Read up on what JTAG is, it's simply put a debug and testing interface for complex circuits which can also be used to program or command certain parts.
JTAG works by a writing a couple of shift registers into the JTAG part of the circuit. These registers determain what component inside the circuit you are talking to and what you are saying to it.
For example JTAG can be used to talk to the memory controller, on PDAs I often use this function to test dead memory. That way I can disable pieces of the memory or know what chip te replace. If you are talking to the A64 you could be talking to it's memory controller. Since JTAG is slooooow testing 512MB of memory will take forever.
Even if you find the correct component (some piece of flash memory or EEPROM) you will then have to figure out what it's reading and writing commands are. If you've done that you have to figure out what registers control the max MP and then you have to be able to write a new value into it.
This task without AMD's specs is like trying to find one specific grain of sand in the Sahara desert...
Thorry you seem to know what your talking about as far as the jtag but wouldn't the jtag use the same instruction set as the cpu or would it have it's own language? Basic x86 and machine code is pretty well documented isn't it?
question!
how do u "flash registers" ?
form wha ti understand, i need external jtag hardware inerface, right?
what about dual-processor (not dual core) boards? can one cpu be running a prog to jtag the other?
thru assembly lets say
I'm reading the topic for quite a while and a question walks my mind. If we unlock a socket 939 then the rest of them (all s.939 cpus) are unlockable? I mean if we onlock an A64 can we unlock an Opteron 144 as well. Or do the jtags and stuff changes and we would have to start from the begining?
When we unlock the first one, no doubt it will help us with unlocking the other ones very quickly...
(and Kohan...."I helped my Uncle Jack, off his horse" shouldn't have a comma, it's an unnecessary pause, although we use it in speach for the reason you listed ;))
If that's all it takes, who's ready to goto the Sahara with me?! :explode2:Quote:
Originally Posted by Thorry
Nope, I saw it my self. He doesn't know anything about overclocking or that kinda thing.Quote:
Originally Posted by misteroadster
He didn't even know what is SuperPI!
I just wanted to check his CPU's power and that result!!! :slobber:
It's very strange. Believe me. I will put a screen shot of it in a little while.
Don't know what to do. Frankly I'm dissapointed. :(
Guys, JTAG doesn't use any language as such.
I think I've post a big PDF with all the JTAG specs in this thread somewhere. Anyways, it is a IEEE standard so for like 5$ you can get all the specs.
However all you'll be able to do is write values to the shift registers.
You will need to input the correct values in the registers to access the flash/EEPROM inside the CPU, then input the correct values to get it to read or write something.
So it's not like anybody with great expertise has a better chance of finding the magic numbers.
What is true however, once you've done one you can do them all. And anybody can do it at home for 5$.
You sound like a lzy salesman Thorry
I'm still bettin on the decompiling the Cool 'n' Quiet program.
Since it changes the multis in windows, thru software, it may as well unlock 'em
LOL, that's what we call jumping the gun.Quote:
Since it changes the multis in windows, thru software, it may as well unlock 'em
Changing the multiplier of a A64 CPU is easy, it is done by writing the correct values in the CPU's MSR registers. There are a lot of programs (even open source programs) that can change the multiplier of a A64 CPU. AMD has documented the MSR registers of their processors so that's no problem.
By no means is it possible to unlock the multiplier of a A64 by using the MSR registers or any kind of software available to the public today.
FIY the FIDVID MSR controlling voltage and multipliers via software is 0xC001_0042
To be able to write to MSR registers in Windows you need a kernel driver, this is because access to MSR instructions as well as some other instructions is limited to the inner most kernel shell.
ah... I see. Well, Clocker DID have a problem WITH the CnQ AFTER his spu got unlocked.
THerefore, what caused it to unlock corrupted CnQ, or vice versa
KoHaN69: I suggested earlier that a power-surge could have caused the internal registers of the CPU to flip, thus making it look like the CPU wasn't CnQ-enabled, which would make the OS to skip the CnQ-option.
Hi all.
Thorry
plz send me JTAG interface schematics + pin specifications for A64 CPUs (939 as well as 754) to tin@topmods.net. I have no too much time now to look thru all thread. sorry
I want to compare our methods.
ALL
dead mobos and dead 3500+ don't not arrive to me right now. So I wait. When they come I will post here as soon as I can and begin trying jtag with that pieces of silicone. I will try using bsdl from K6-2 , geode and amd flash memory.
I use this cable:
http://www.xilinx.com/support/programr/jtag_cable.pdf
With these pins on 939:
TCK - AG7 - I-IOS JTAG Clock
TMS - AG6 - I-IOS JTAG Mode Select
TRST_L - AF8 - I-IOS JTAG Reset
TDI - AJ9 - I-IOS JTAG Data Input
TDO - AG8 - O-IOS JTAG Data Output
These on 754:
TCK - E17
TMS - E10
TRST_L - B21
TDI - A21
TDO - A22
I found 2 problems stopping me:
- TCK is connected to ground potentially killing any CPU I connect to my interface
- Lack of internal CPU specs, so no idea what to tell it to do
I keep the TMS pin high following the docs to enable the interface.
The DB_REQ_L and DBRDY pins work into this as well, not sure how.
I've not yet connected any CPU to my setup as I'm not sure if this will kill the CPU given the TCK problem.
As for software, there is a lot of open source Linux software for JTAG interfaces available. However without correct specs you have no idea what you are doing increasing the chance of a dead CPU.
Buy a CPU, try it, if it kills the cpu, then RMA it.
Yes it's questionable ethics, but all is fair in love and OC:ing.
I'm not like that, besides it won't help.
If I now go out and buy a cpu and kill it by hooking it up to my JTAG interface I could go and RMA it. But then I'd have an extra CPU which I have no use for.
If I kill it twice I wouldn't be able to RMA it (or at least with great difficulty).
So you see, the end result is at best me ending up with an extra CPU which I have no use for. So it's too much trouble with most probably no result.
I'll just wait for TIN_EOF to test it for me, I've given him some of my ideas about how to safely test this. If his rig doesn't blow up I'll give mine a try.