E10 (00001010 or 0022 like people talk on the internet) means there's something mismatching from CPU configuration (stuff like CB pairing, lockdown value or even the CB being flagged as revoked) to the nand contents or a error happened during execution of the CB to CF boot stages. That could be either software or hardware causes for the error but in case of the XDKs we know that MS nuked the CPU fuses. What we don't know yet is if there's an alternate mechanism inside the CPU to generate the fuse blowing voltage internally, which existence would explain some cases where R6T3 were removed and still bricked.
There's a design called "charge pump" which allows for making circuits which rise voltages. An excellent example is a photo flash circuit. Such circuits exist on certain ICs like for example the popular MAX232 which uses a such "charge pump" to generate internally the RS232 level voltages it needs.
It is in retails, why do you think all console can not be jtagged, it's because the efuse's have been blown. Hawk
I was referring to what l_oliveira said about there being a way to blow eFuses without the R6T3 resistor present. Are you saying that the technology that l_oliveira was referring to is, in fact, in retail machines? My apologies if I haven't communicated myself clearly enough.
The CPUs on Retails and Devs are identical. Only thing that differ is what MS write to their first two fuselines on the first factory setup. What R6T3 does is pull up the disable pin of the voltage regulator which supplies the XENON processor with power for the fuse blowing circuitry. It's software controlled and I believe the line is kept low while the system is running, being released (going up to +V) only when the fuse blowing circuitry is going to be used. That enables the voltage regulator, then supplying the fuse blowing circuit with power. Such mechanism likely exists to prevent accidental writes to the fuses in case of system hangs. (hardware malfunctions can make even the hypervisor crash) And any unintentional damage to fuse data will cause the system to stop booting. And those registers (just like any kind of hardware register) are usually triggered by memory writes or I/O instructions (or even both), depending on the processor architecture. And hypothetically speaking if an charge pump circuit does exist internally, it could allow for fuse blowing even without the external power on the said circuit. In the end the only difference on them destroying DEVs or retails is the fact that the DEVs still belong to them and if they started to nuke retails people could then sue them or whatever. I know that it's possible to cause damage on certain types of computers by tinkering with certain hardware registers. On a MSX computer built with discrete parts (no custom LSI), for example one can fry the i8255 chip which does the memory control and keyboard interface by inverting the input/output state of one of the chip's ports and all it takes for that is flip a few bits on a single register.
So what's the deal with this, it's been weeks now? I saw the thread about banning profiles, so is that all they are doing now or was this just all a hoax?
The bricking was not a hoax...no one knows who exactly was targeted or why, but kits were dying. Then recently there was a PNet ban wave, just like an Xbox Live ban wave. Not bricking. Haven't heard any news of any similar ban waves...yet.
i have now two kits. The first gets red ringed, and was a zepyhr. My second kit is a jasper, and is banned like on retail...
lol I have an idea MS remote bricking Jtag/SMC hacked xboxes for who ever get on XBL. They can, and possibly will.
Don't think so. MS got in shit for crippling banned consoles from playing installed games in the october/november banwave. I remember part of the crazy class action lawsuit that was started stated that no where in any documentation for LIVE or its bannings did it entitle MS to break or remove functionality to items unrelated to LIVE(like the hdd game support). You can only imagine what would happen if they started bricking jtag's on LIVE. :X -Doom
For the most part I believe they can get away with it if they obfuscate the code and then claim that the unit was modified to work outside of the specs it was designed to (I.E.: put the blame for it failing on the hack) and I think MS knows it has potential to get away with such plan. Still MOST JTAGs have R6T3 patched to block efuse blowing, making this non effective. At most it would be an hindrance to the hackers as they would be forced to pop their hacked systems open to use SPI and restore an working flash on them. So the question is : "Would MS be interested on wasting resources to cripple JTAGs if it can just ban them ?"
Could Microsoft blow a JTAG box? Yes. There are ways to do it without efuses. Will Microsoft do it? Not likely as there would need to be a reason for the code outside of the hack and they would also need to be very clear in the docs about possibly bricking, etc. etc. Although it could be done to put MS legally in the clear it would be horrid PR and owuld likely involve a lawsuit and unneeded lawsuit costs. End result? Not gonna happen. Dev kits? They're Microsoft property. Microsoft can do whatever it wants to them with no worries. -hl718
you atached a nand dump from a demo kit but whats a brig via partnerNet perhaps you ment brick instead of brig?