|
plaguereign
|
 |
« on: November 06, 2011, 08:26:04 PM » |
|
Just to give everyone a heads up, The first Opus console was glitched today by DeathLok and tydye81 over at #rgloader on efnet. Timings are very close to the falcon, in fact its about 3 ticks slower than the falcon. build.py picked up the SMC and CB as falcon's as well.    Any questions, post em. Plaguereign aka DeathLok
|
|
|
|
« Last Edit: November 08, 2011, 09:59:01 AM by plaguereign »
|
Logged
|
|
|
|
|
jhonnyp0lak
|
 |
« Reply #1 on: November 06, 2011, 10:22:27 PM » |
|
Great job! Do we need a new .jed file for the chips ?
Also any progress on Xenons ?
|
|
|
|
|
Logged
|
|
|
|
|
plaguereign
|
 |
« Reply #2 on: November 06, 2011, 11:10:18 PM » |
|
Thanks. Yeah. Jed file is floating around. If you need it, Ill post it here. Wasnt sure if we could post outside links. Xenon wont work because the processor crashes when the glitch is attempted (at least that is how it was explained to me). If someone can elaborate, I am sure we would all appreciate it. http://www.multiupload.com/MIBH22V2BU <- the jed file for opus. enjoy
|
|
|
|
|
Logged
|
|
|
|
|
skinnymathew
|
 |
« Reply #3 on: November 07, 2011, 03:29:26 AM » |
|
Cpu PIN AH16: CPU_PLL_BYPASS (Point under the motherboard connected to R7R17) If you leave this point to GND the 1BL clock speed is normal, 66Mhz. If you give 3.3V to this point the clock speed slow down to 520Khz.
The interesting thing is that if during 1BL execution you change the clock on the fly the execution slow down a lot, at 520Khz in particular....lot of seconds between each postcode. In any moment, during slow speed boot you can speed it up giving 66Mhz again. Slowing down the boot in certain moments cause a boot freeze and giving 66Mhz again the boot continue exactly from the freeze point.
I've been able to replicate most of this, except being able to speed up again. If I remove 3.3v at that point it'll just freeze, and even resetting the processor keeps it frozen. However if I then apply 3.3v to that point again it'll continue booting from that point (until it hits a boot freeze). I'm not sure what I could be doing wrong? Btw this is a Xenon board. I think this is where the Xenon CPU lock up became an issue. I've searched and asked questions, but nobody has confirmed what testing has been done to prove it's a general Xenon issue or specific to the setup that Dark_Neo was using. I have everything I need to _try_ to glitch my old Xenon, except a power supply (which is on its way). I'd be happy for someone else to beat me to it, though.
|
|
|
|
|
Logged
|
|
|
|
|
ddxcb
|
 |
« Reply #4 on: November 07, 2011, 04:02:40 AM » |
|
Just to give everyone a heads up, The first Opus console was glitched today by DeathLok and tydye81 over at #rgloader on efnet. Timings are very close to the falcon, in fact its about 3 ticks slower than the falcon. build.py picked up the SMC and CB as falcon's as well.
Any questions, post em.
Plaguereign aka DeathLok
It is typically not a good idea to use another boards, SMC and CB. but as always, did not surprise me.
|
|
|
|
|
Logged
|
I'm a ADD modder, got to mod or be bored xD
|
|
|
|
plaguereign
|
 |
« Reply #5 on: November 07, 2011, 12:01:38 PM » |
|
The other interesting thing is when you put the opus nand dump into nand tools, itll come up as a falcon.From what I understand (may be wrong tho), is that the opus is basically a falcon minus the hdmi. If I am wrong, please correct me. Also, great find with the slowdown on the xenon. I would be interested in trying this myself. Maybe hook up a post logger and see what is going on. We MIGHT be able to get something going with it. Just to give everyone a heads up, The first Opus console was glitched today by DeathLok and tydye81 over at #rgloader on efnet. Timings are very close to the falcon, in fact its about 3 ticks slower than the falcon. build.py picked up the SMC and CB as falcon's as well.
Any questions, post em.
Plaguereign aka DeathLok
It is typically not a good idea to use another boards, SMC and CB. but as always, did not surprise me.
|
|
|
|
|
Logged
|
|
|
|
|
tydye81
|
 |
« Reply #6 on: November 07, 2011, 03:09:56 PM » |
|
Just to give everyone a heads up, The first Opus console was glitched today by DeathLok and tydye81 over at #rgloader on efnet. Timings are very close to the falcon, in fact its about 3 ticks slower than the falcon. build.py picked up the SMC and CB as falcon's as well.
Any questions, post em.
Plaguereign aka DeathLok
It is typically not a good idea to use another boards, SMC and CB. but as always, did not surprise me. The CB is 5771 and the SMC is the same as the Falcon so there is no problem using the files for a falcon -.-
|
|
|
|
|
Logged
|
|
|
|
|
Jcplinux2012
|
 |
« Reply #7 on: November 13, 2011, 12:20:40 PM » |
|
I'm curious as to why this is news? I glitched an Opus a couple weeks ago (before this news) using the falcon files and gliglis build.py, I know from experience with SMC/Jtag modding that there isn't a difference in them save for the lack of an HDMI port on the Opus and the / between the word Falcon and Opus in the information. The bootloaders are the same, and the SMC is the same, also the CPU/GPU are the same, and therefore the timings are the same. We all know each console has a different timing, it is semi specific to each MB revision Zephyr, Falcon/Opus, Jasper ,Trinity , but each console has a so called 'sweet spot', if there was a change made to the Jed file where it is '3 ticks' off, then it is a new timing for all Falcon/Opus motherboards, not specific to the Opus itself.
I wouldn't say anything if I hadn't seen this exact story as front page news at 2 different sites .... Should I have gotten a big pat on the back if I posted that I glitched an HDMIless falcon?
|
|
|
|
|
Logged
|
|
|
|
|
skinnymathew
|
 |
« Reply #8 on: November 13, 2011, 06:24:00 PM » |
|
I'm curious as to why this is news?
news Noun: Newly received or noteworthy information, esp. about recent or important events. I guess the important part of the definition is "newly received" information. The people in the water next to the Titanic knew it had sunk before it was on the front page, but it was still news for everyone else. Should I have gotten a big pat on the back if I posted that I glitched an HDMIless falcon?
Yes. Sorry about that.
|
|
|
|
|
Logged
|
|
|
|
|
tydye81
|
 |
« Reply #9 on: November 18, 2011, 07:12:31 PM » |
|
I'm curious as to why this is news? I glitched an Opus a couple weeks ago (before this news) using the falcon files and gliglis build.py, I know from experience with SMC/Jtag modding that there isn't a difference in them save for the lack of an HDMI port on the Opus and the / between the word Falcon and Opus in the information. The bootloaders are the same, and the SMC is the same, also the CPU/GPU are the same, and therefore the timings are the same. We all know each console has a different timing, it is semi specific to each MB revision Zephyr, Falcon/Opus, Jasper ,Trinity , but each console has a so called 'sweet spot', if there was a change made to the Jed file where it is '3 ticks' off, then it is a new timing for all Falcon/Opus motherboards, not specific to the Opus itself.
I wouldn't say anything if I hadn't seen this exact story as front page news at 2 different sites .... Should I have gotten a big pat on the back if I posted that I glitched an HDMIless falcon?
Your right, it really wasn't that difficult but the reason that it had to be news was because there are many websites/forums that are posting saying that the glitch hack is incompatible with Opus. Your lucky that the falcon jed files worked for you because most other Opus require different timing values. They are very close to the Falcon's timings, but still different.
|
|
|
|
|
Logged
|
|
|
|
|