Reset Glitch Hacked consoles now boot DEV kernel

Works perfectly on my Super Elite Jasper.

 

That is what we call a statistical outlier. It might very well last forever in that state based purely on how you've treated it. Hand it over to someone else and it will be dead in a month.

 

What do these "private" loaders need to do to load a Dev kernel?
Emulated NAND? or more like a custom CB and Dev keys(lb1?).
X360 Dev n00b asking ;-)
Also

True, I have a Xenon myself and worked like a charm till January 2011, Some "friend" asked me to play at a LAN-party and I moved it... RROD at arrival. I traveled by Bus and Metro. New clamps and extra fans on the back fixed it, fully functioning Xenon for 4 month now.

 

There are servers out there where the sysadmin is fearful that shutting them down after years of uptime might kill the HDD. It can happen and I've seen such things. I've had Maxtor (yack) drives have the click of death in a PC at random, very clearly going to be dead soon. Put them into an XBox or a PS2 and they continue to function just fine.

That might be the result of the console putting less demand on the drive compared to Windows and its swap file, but hey anecdotal evidence is awesome.

More ontopicsh:
I installed a Matrix glitch chip in my slim and so far it does nothing but sit there acting amusing. It was programmed correctly and the ecc file was flashed. I swapped in 50cm of wire for the RST point. The only thing I have yet to do is try a 270pf capacitor.

Would this dev kernel be bootable using a Cyngos or is my assumption incorrect?

 

Yes you can boot it with a cygnos. I have a youtube video here of it running: http://www.youtube.com/watch?v=d8hoQvGymts&list=UUSoPGRM7ueufcOdpd7HuQFA&index=1&feature=plcp

 

You can boot with cygnos, but only once you get your glitch working right.

 

Put an LED on pin 27 of the Xilinx chip as it will allow you to see what's going on ... (Glitch chip will put a pulse on pin 27 every time an glitch signal is sent to CPU_RST).

Also the key for it to function on a slim console is the length of the wire.

To make wire length more adjustable I do this:

CPU_RST---------fixed length of wire, 45cm------Glitcher chip---variable length of wire for adjust-----|cap|--- GND.

Meaning, I connect an fixed size of wire from the CPU_RST point to the A point on the MTG chip. I then wrap it around the X CLAMP for 2 turns and pull the wire up to the other side where the MTG is.

It's around 45-50cm. An additional wire of up to 15 cm is used to adjust the inductance and delay. Because the metal casing do affect the performance of the hack slightly, having it assembled before doing the final adjusts is a great idea. :thumbsup:


Edit: forgot to mention that I do not use the cap on the chip... I usually use an external cap as that part value is also an thing that can be adjusted.

 

Wrong, Coronas are NOT glitchable. The standby clock was on the HANA port which has been integrated into the southbridge. The clock is now non-existant.

 

*cough*
http://www.x360glitchip.com/en/news/21-x360glitchip-vous-apporte-la-compatibilite-corona
*cough*

 

Sales gimick. Don't believe me go do some research and you will see for yourself.

Also I like how their "POC" is on a trinity board. Yea good one...

 

Well, I suppose they could show it hooked up to a Corona not doing anything since not only is it not complete there isnt software for it yet...

They arent the first to do this either

What this shows is they do not need to rely on the clock on the motherboard for the timing, which is why Coronas are "unglitchable" and once any timing is figured out then coronas will be just as vulnerable as trinities

 

Please don't tell me that my glitch chip didn't glitch because of the latest dash update. Or is the CB something that is mobo specific (honestly I can't recall as the 360 isn't my strong side, yet).

I did go ahead and reprogram it for a Jasper that my friend has. Hopefully it'll work there. Fun finding out the dumps from the CPLD were getting a different hash each time as they have an embedded timestamp.

 

I like cookies.

 

There are a few CB's that currently arent glitchable. You should check your dump before attempting anything.

 

CB isnt required to glitch the systems, but do help if the chip does not boot under 5 times.

They can glitch a corona if the jed is figue out.

 

two stage Phat CB's are currently unglitchable - so yes, it matters (at the moment anyway).

5772 and 6752 off the top of my head.

 

Pretty a long time.... But it depends on who did the reballing job...A Professional or shoddy backyard job.... I've got a Xenon here that was just reballed a while ago like apprx 4 months ago, it's still trucking on today... But at the same time I had a Falcon reballed only to have it fail a few days later with a RROD again.... So really YMMV it's not a perfect solution but it's alright if you got the $ and time to pour into it... Nowdays I'd say toss it and just get a Slim. Which I plan on doing when my JTAG Jasper croaks!

Speaking of booting to Dev Kernels when does anyone think the setup will be released for the JTAGs to follow suit?

 

When a rebooter is made for one, as like freeboot and all others.

 

When my Xbox1 devkit is ready I gonna fix my Jasper... Hope such rebooter will be released or made
(yeah, if it takes to long ill take a look myself with my n00b knowhow on fuses and boot process... and kernel stuff)

I like researching this all, don't hack a lot, but its so fun to discovery stuff hardcore gamers don't know a lot of
I'm a "Hardcore" console archaeologist

 

They've said that they plan on working on a JTAG port as soon as they stabilize the RGH version. So I would assume it might be a bit...