x360Glitchip v2 Corona Ready

[bonx]

Hi,
I rarely write posts, but there i can't resist.
I try my best to translate for you a news i just saw.
This is really really pathetic. 

http://www.x360glitchip.com/fr/news/21-x360glitchip-vous-apporte-la-compatibilite-corona
While other teams are just copying and\or making cash with their glitchchip, without improvments, making empty announcements; the x360Glitchip team brings you the world first glitchchip Corona Ready.
As you already knows, corona (new slim motherboard Slim following Trinity) was not glitch compatible Glitch due to hana chip removal, chip used for timing CLK_STBY.
X360Glitchip v2 is the first world glitchchip which does not require anymore this point, and thus becomes Corona Ready.
Naturally, an update of the build.py of the hack Glitch will be needed, working with corona new, CB 13121.
Other v2 features will be soon be presented, because it won't stop here.
Here is a video, of one x360Glitchip v1.4, modified to be Corona Ready, on Trinity.
You can see the absence of the B point (This one is not useful anymore) so no more destroyed track / resistor and a more stable boot and impressive boot times (10s, 15s, 7s and 12s).

[peshkohacka]

Shameless marketing, CLK was never an obstacle. And how can they be certain that their board is Corona ready, when no one actually glitched it yet?

[Tiros]

I call shenanigans on x360glitch chip. Everyone grab a broom 

Having an onboard osc. does nothing at all to change the cpu clock speed on the fly.
The clk is only used for timing the glitch pulse, and thats only a PART of what needs to be done.
Apparently the creators of this device dont even fully understand how the hack works

[Reama]

I call shenanigans on x360glitch chip. Everyone grab a broom 

Having an onboard osc. does nothing at all to change the cpu clock speed on the fly.
The clk is only used for timing the glitch pulse, and thats only a PART of what needs to be done.
Apparently the creators of this device dont even fully understand how the hack works

Nah dude! They called other teams out and said other teams were just trying to make money! They MUST have a working chip!


No but really, I don't understand why they'd even throw an announcement out like this. 

[Blackaddr]

Apparently the creators of this device dont even fully understand how the hack works

Indeed.  In addition, the nonsense these (not just x360Glitchip) developers are spouting about their products improved boot times and such is ridiculous.  Most of them are just copycatting whatever the 'flavour-of-the-day' alternate cap/wire gauge/loop is on the forums, almost none bring any value-add to the table.

There are some big hints about what needs to be done to glitch a Corona on this board, but somehow I doubt these guys even understand the information available to them.  STBY_CLK is used because you need *some* clock at a reasonably fast frequency.  I create my own clock on my FPGA board simply because I can, but as Tiros pointed out, I still need to use either CPU_PLL_BYPASS or change the HANA clock in order to change the CPU's clock.

On the bright side, the useless oscillator is eating into their profits since people will quickly realize paying more for this is stupid.

[rz2k]

another bad thing about ext. osc:

what is possibilites that they invented another source of wiring problems if they trying to sycnhronize onboard osc with console clocks?
otherwise, what is reference point? will it make kids go nuts with 50cm wires again?

when we use stby_clk we clock our cpld with (console stanby clock + wire_lenght_delay).
when we use external osc to clock cpld we must synchronize osc with console clocks, other we will have jitter and wrong timings. am I right?

[peshkohacka]

I think you put the horse before the cart, before starting to worry about jitter, you must have a working solution to slow-down and bring back up the processor, to do this you need the I2C and CPU points, the sync can be easily done if you have the same speed oscillator and sync it by fronts or edges. We're still not sure if the CPU is actually capable of returning to full speed without a freeze or reset (xenon meme?). We still don't know how to tell the new SMC to slow down the CPU (although BlackAddr is working on this).

[rz2k]

yep, I understand that, I was talking about what they actually did right now for trinity.

if you have the same speed oscillator and sync it by fronts or edges.

yes, but synch will be affected by wire lenght, and if you remember, needed time window for glitch is pretty small, so even small desynch by that delay can possibly make all glitching proccess fail. so theres two solutions: use same setup everytime OR make dynamic synchronization, which I dont realize on such small CPLD as xc2c64a.

[Zakwarrior]

Apparently the creators of this device dont even fully understand how the hack works

Indeed.  In addition, the nonsense these (not just x360Glitchip) developers are spouting about their products improved boot times and such is ridiculous.

News version of 360gcProg (v1.3) gives better boots on slims that had problems or wouldn't boot, but it works only for his glitch modchip, what you think about that ?

[APE]

My slim is glitchable as per the info garnered from a NAND dump but hell if it will glitch with a Matrix v1 (yes I did mess with wire length and various capacitor values). I did install it into a Jasper bigblock and it is running Freestyle Dash in front of me as I type this so I know it wasn't a bad chip. Though the glitch times are on the slow side, likely something I can fix by shortening some unnecessarily long testing wires. Chip placement is far less than ideal in front of the heatsinks under the shroud but it was purely for testing purposes. I swear!

Someone did recommend I purchase a x360 chip to try on my picky slim. Like Blackaddr said, it seems the 50cm wire "fix" was incorporated into the various kits with the instructions of "yes it is supposed to be this long, just coil it up and leave it alone". To be fair I've yet to see anyone claim this fix for their own particular chip as their own personal innovation. If only I was further along in my EE degree.

Though I have absolutely no doubt things will improve.

[pc]

Having an onboard osc. does nothing at all to change the cpu clock speed on the fly.

Unless they are replacing the crystal on the motherboard with a clock generated by the CPLD. That should be possible, but I'm not sure how the PLL is going to react when the reference clock suddenly changes. Anyway that doesn't appear to be what they are doing from what I can see from the video.

[peshkohacka]

Having an onboard osc. does nothing at all to change the cpu clock speed on the fly.

Unless they are replacing the crystal on the motherboard with a clock generated by the CPLD. That should be possible, but I'm not sure how the PLL is going to react when the reference clock suddenly changes. Anyway that doesn't appear to be what they are doing from what I can see from the video.

Any why would you want to replace the clock from HANA with unreliable source like a CPLD? You'll see tons of topics like "Help i killed my Corona".

[pc]

Any why would you want to replace the clock from HANA with unreliable source like a CPLD?

Because if you can't bypass the PLL (fat hack) or change the PLL parameters though the i2c-bus (slim hack) replacing the crystal on the motherboard is as far as I can see the only way to slow down the CPU clock. The idea is to implement a frequency divider that conditionally slows down the clock. Again I'm not sure if it would work.

I'm a digital hardware engineer and I have some trouble understanding the physics behind this hack. As far as I can see the idea is that a very short reset pulse will reset some registers and not others (in particular, the program counter). This happens because the CPU has a global asynchronous reset with a really large fan-out, so that the reset signal takes time to propagate through the device. If so I have a hard time understanding why it is really necessary to slow down the clock at all, apart from making the timing easier. Does anybody have any insight?

Again it doesn't seem like they are trying to do the hack without slowing down the CPU either, as they are still connecting to the i2c bus. I really don't know what their plan is.

[peshkohacka]

Instead replacing it you can (if all fails) just switch between the system and the CPLD/FPGA? clock (which would be slowed down to minium), so you can perform the attack and bring it back to system clock if successful, this way you only use the CPLD clock when you attack, of course you'll need to sync it and make sure its in range but it should work. Although im not sure if the system wont just crash when you do that.

[Tiros]

The reason for slowing down the CPU clock is twofold:

1) Easier to hit the timing.
2) The RST signal is not async, and without the slowdown, even the very short pulse we currently use, will hard reset the cpu.

Changing the SMC standby clock (proposed) is not the same as changing the HANA dividor that generates the cpu clk (currently). Changing the standby clock will change the entire dividor chain, not just the cpu clk. Attempting to change only the cpu clk (post hana) is ugly, since its a 100Mhz differential clk.

The reasoning behind all this wire length / cap  nonsense is not delay related. The RST pulse and its effect on the cpu, is more of an analog issue than a digital one. The wire lengths and cap combinations are merely "shaping" the RST pulse per individual cpu.

[peshkohacka]

Yeah after reading the Blackaddr's all-in-one thread on how the glitch works i realized what i said was stupid. I was wondering thoguh what is so special about the x360 processor that allows a short reset pulse to reset one register but keep another? Is it just a bug in system design (given that all versions have it) or is it programmed to do that in order to prevent data-loss?