So since I succesfully integrated mimicked Chameleon TSOP recovery feature into my own modchip, I've started playing some hex editor magic. I made my own BIOS, similar as tsop_d6.bin, that will work exactly as tsop_d6.bin. The only difference is that this BIOS will boot on every Xbox that has a flashable TSOP(so 1.0 to 1.5). I named it tsop_m7.bin as it uses the kernel found in Evox M7 BIOS. As tsop_d6, you need to have to solder a wire to the TSOP A15 signal. Chameleon modchip will work it's magic by itself. If you don't have a Chameleon (or soon a XBlast), you can *try* to manually make it work using a basic modchip like a DuoX2, Xecuter 2.x or aladdin XT. I recommend you use a modchip with at least 2 banks to still be able to flash over this BIOS once you're done. To make it work, you'll have to manually operate D0 and A15 wires. Make them long enough to reach a ground spot. Here's the procedure: 1. Insert you booting disc in the DVD drive(HeXen, Auto-Installer...) 2. Tie both D0 and A15 to ground 3. Boot the Xbox with tsop_m7 4. Remove D0 from ground (leave it hanging without touching anything)once the front LED starts flashing 5. Remove A15 from ground one you see the Xbox logo on your TV. 6. Flash your TSOP using your favorite tool. Some important info: - As tsop_d6, you can only boot from a Xbox disc in your DVD drive. If no disc is in the DVD drive, the Xbox will just sit at the booting Xbox Logo. - There is no boot animation. I chose a really weird color combination for the Xbox logo so you know you're booting the right thing. - There is a chance this BIOS will not boot if you have previously flashed a hacked BIOS on your TSOP. From personnal experience, M8+ and X2 5035 are problematic across all revisions. IND-BIOS 5004 works on my 1.2 and 1.4 but not on my 1.0(probably an RC4 key issue). - There is no LBA48 support. This BIOS is not meant to be used as your everyday BIOS anyway. - Pre-insert you disc in your DVD drive. This BIOS resets on Eject. I thank Xphazer(on XBMC4Xbox forums) for lending me his Chameleon modchip and weinerschnitzel for supplying me with a 1.4 Xbox. Without them, this would have been nearly impossible to make! So anyway, I'll just leave this here: View attachment tsop_m7.zip
Fantastic work. Now I can try to fix an old v1.4 that I failed to TSOP flash years ago (tried a 28 wire mod, but my soldering skills weren't up to it!). What's the latest, most reliable software for flashing the TSOP?
the most reliable software for tsop flash is search in google hexen heimdall's xbox engineering disk : )
Nice job...you save my "new" Xbox 1.0 founded on garbage on the street.... http://www.razielconsole.com/forum/...ni]xbox1-recover-tsop-bad-flash.html#post4337
Is this trick using some unknown feature of the mcpx chip? What's special about a "tsop recover" flash bios compared to a normal one? Just trying to understand how this might work to understand better if it doesn't work, why so. I mean, I read somewhere that some parts of the tsop flash still need to work properly. That's what puzzling me.
Oh boy, tons of assumptions and guessing coming up. The first thing to know is that every Xbox BIOS have 2 "executables" packed together. The actual Xbox Kernel based on Windows 2000 source of course but also a small bootloader, called 2bl. The job of the 2bl is to answer a couple of security challenges to (try to) prevent tampering of the boot process and then to unpack the Xbox Kernel (essentially a stripped .cab archive), verify it's integrity and jump to it. From that point, the Xbox kernel takes on and it's at that point that you'll see the flubber animation. That's verified info. The rest is mostly speculative (mostly by me and my understanding of the process). The magic of the tsop recovery BIOSes all lies in the 2bl. The 2bl embedded in the tsop_recovery BIOS contains some instructions to toggle a signal line on the LPC modchip (A15 pad) which in turn will ground the A15 address line of the Xbox onboard TSOP. After doing that, it tell the modchip to release D0 control and soft-reset the console in order to allow booting from TSOP. At that point, the 2bl on the TSOP just try to do it's job like normal but will ultimately fail as grounding the A15 line will corrupt the packed Xbox kernel. It corrupts it because if the MCPX is not able to toggle correctly the A15 address signal of the TSOP, it will not actually receive the correct data when A15 is expected to be at "1" or 3.3V. My assumption is that grounding A15 specifically results in failing to unpack the kernel at a critical point in the process where the MCPX decides to branch to another state than generating a FRAG(normal behavior when trying to load a corrupt kernel). During implementation of this feature on my modchip, I experimented grounding other address lines on the TSOP and found that neighboring address signals could also be used successfully (A15 to A18 if I remember correctly). Anything other than that would not make it work and would result in a FRAG. Continuing on this, another assumption is that after a couple (unsuccessful) retries unpacking the kernel on the TSOP, the MCPX is programmed to switch to LPC bus temporarily without reseting the system thus keeping the 2bl active in memory. With the normal 2bl in memory and LPC bus being active, the 2bl fetches the packed (hacked) kernel from the modchip and does its job with it. After a while, the MCPX switch back to TSOP access. You're now in a state where you loaded a hacked kernel but MCPX still points to TSOP, containing a corrupt/stock packed kernel. From then on, you need to either launch Evolution-X dashboard or XBlast OS in order to release modchip's hold on A15 signal (done on launching either program). At that point, you now have full access to flash the TSOP, providing the write enable points are soldered of course. In order to make this work, the part of the TSOP containing the 2bl must be valid. The rest can be corrupted. Second, the Xbox kernel embedded in the tsop_recovery BIOS must be packed as such as the 2bl contained on the TSOP will be able to unpack it. It needs to be encrypted using the same key contained in the 2bl and packed archive must be at most the same size as the stock kernel (because size of the packed image is contained in the 2bl itself and thus cannot be changed on the fly). Since Evox M8 X2 5xxx and some later BIOSes radically changed how the Xbox kernel is packed (because they use a custom 2bl, I don't know why...), you cannot use the current tsop_recovery images to repair a corrupt TSOP that contain either of those. My theory is you could make it work if you'd manually pack a tsop_recovery BIOS containing the magic 2bl and a packed kernel that was packed using evox's 2bl "standard". So far, I have not been able to make this work. I have not dissassembled this evox 2bl to see how it ticks but there is something fishy going in there when it comes to unpacking the kernel. My guess is this TSOP recovery process takes advantage of a manufacturing loophole set in place in the MCPX to easily flash the Xbox TSOP through the LPC port while on the asembly line, or during QA testing. There is probably a way to send a signal to the MCPX in order to fully control that loophole but I guess nobody ever found it. It's quite common practice in electronics manufacturing to automate flash programming while in production. Coupled with the fact that in this case, this process must remain hidden away from the public, finding how to trigger it is always a challenge or takes a really long time to figure out. Just look at the Pandora Battery exploit on PSP or the PS3 jailbreak dongles in the early days of PS3 hacking. Both were likely purposedly put in place in order to facilitate programming in production or service them in repair centers.
I wonder will it be possible to create a solution to repair all the xboxs bricked tsop, such as creating a programmer that connects to directly into the LPC (something like the jr programmer on xbox 360 rgh) and thus repair or flash the tsop? it would be possible to create programmer with arduino to flash or repair tsop?
You can pull the tsop out and reflash it. Pretty sure the eprom method works on a tsop in any state too. Regarding just programming from the lpc port - as above the method to make this happen is unknown currently.
Yep, the 29-wire mod with a switch that toggle between the DIP flash chip and the TSOP's "CE" pin will enable you to recover a TSOP regardless of the content of it. Did it many times when trying to test TSOP recovery feature of XBlast!
More likely than not, the reason why Evox used their own 2bl is because the keys that sign the 2bl are unknown. You can compile a patched kernel, but re-packing it is the problem, as the normal 2bl's keys aren't available to re-sign the kernel image. There's also likely a better way to handle the compression of the kernel, which can only be implemented in the 2bl. Microsoft used LZ compression, taken from the CAB format. Evox likely used something with a little higher compression ratio, which would allow them to add larger patches to the kernel (I don't know if they actually did so or not).
