Attempting to Diagnose a FRAG

[MrBriteSide]

Hey Guys,

Im currently working on trying to fix a FRAG'd motherboard that I bought sometime last year. While normally I would just ditch the motherboard in a normal FRAG circumstance, this motherboard is special. Its a board that has the MCPX X2 chip instead of the retail X3 and has only 64mb of RAM. Im not entirely sure on what its history is, the person who I bought it from on Ebay didnt seem to know either so whether he is 2nd owner or even further down the line, im not sure. Either way im trying to do all I can to diagnose and fix the board so that I can turn it into a proper debug board that could maybe run stock un-modified Debug ROMs. Just a nice small little thing. Anyways, I had recently posted about this around a year ago asking if anyone had any X2 bioses and whether there was any main difference between a BIOS for a X2 and X3 other then the secret boot portion. After all that I built a Couple OpenXenium modchips and went to town on trying BIOS's. Ill note, the original 1mb ROM chip was FRAG'ing and at the moment i've pulled it and put it on a breakout but havent gotten around to reading it out.

Anyways right now i've made a dumb variant of the Xenium firmware so that instead of doing all the smart stuff, it just boots and mirrors the first 1mb 16x across the memory space. I've also attached a stackable header to one of the chips so I could attach a logic analyzer I bought to read things out. 

So onto the results. While I haven't decoded the LPC address requests yet, based upon my initial inspection, it seems the system is requesting a set of data, and then just stopping. The clock still runs untill the PIC comes in and restarts the system since it didnt receive the special code. I've attached a photo to show what I mean. Im trying to work up a decoder for the analyzer so I can see what address its requesting and what data gets sent back. From what I see and speculate, it almost seems like a memory failure or something along the lines of that maybe? Im just thinking if the MCPX is requesting the first reset vector worth of data for the CPU but then nothing is getting transferred into ram, then it might not execute? Then again I didnt think things got transferred into RAM until the 1bl is loaded, and from what I figure from the capture, only about 16 bytes is getting transferred ( 16 LFRAME signals).

If anyone has some suggestions, im all ears right now. I'd like to try and get this board up and running, but a FRAG state is hard to figure out and diagnose. If I cant get the decoder up and running in a bit here, i may just hand calculate the LPC transactions.

And for those wondering, the bios im running is a patched 3944 bios. Patched as in I tossed the security 256 bytes into it. The dumb firmware works as I've tried it on a retail machine and it boots fine. If anyone is curious or wants a specific picture of the LPC capture, just ask and I'll see what I can do.

Thanks in advance.

[KaosEngineer]

I'd read the TSOP flash chip's content.  If the motherboard has a debug BIOS loaded the chip should have 2 copies of a 512KB DEBUG BIOS; otherwise 4 copies of a normal 256KB BIOS.  Split the 1MB content in half and compare the MD5 hashes of the two files.  Are they the same?  If not what differences are there?  

Split the file into 4 256KB files and compare the MD5 hashes?  Do they all match?  If not, what are the differences between all four (4) files?

Another suggestion - Remove the modchip, reinstall the TSOP flash chip to the motherboard, soldering a ZIF (Zero-insertion force)TSOP socket would be good to do, boot the console, and with the logic analyzer see how many reads of the TSOP flash memory chip occur.

[MrBriteSide]

18 minutes ago, KaosEngineer said:

I'd read the TSOP flash chip's content.  If the motherboard has a debug BIOS loaded the chip should have 2 copies of a 512KB DEBUG BIOS; otherwise 4 copies of a normal 256KB BIOS.  Split the 1MB content in half and compare the MD5 hashes of the two files.  Are they the same?  If not what differences are there?  

Split the file into 4 256KB files and compare the MD5 hashes?  Do they all match?  If not, what are the differences between all four (4) files?

Another suggestion - Remove the modchip, reinstall the TSOP flash chip to the motherboard, soldering a ZIF (Zero-insertion force)TSOP socket would be good to do, boot the console, and with the logic analyzer see how many reads of the TSOP flash memory chip occur.

Sounds good. One thing I guess to note on that, when I got the board the TSOP flashing solder points (R7D3 and R7R3) had been made which leads me to believe one of the previous owners tried to flash the chip with another BIOS. I'll work on that and hope that they were dumb and only did a 256k that didnt mirror over the entire 1mb. 

In regards to the ZIF, are you just wondering if the FLASH is getting the same address requests as the LPC is? I guess I've never seen an in place ZIF socket before so that could be interesting trying to find one.

[KaosEngineer]

41 minutes ago, MrBriteSide said:

In regards to the ZIF, are you just wondering if the FLASH is getting the same address requests as the LPC is? I guess I've never seen an in place ZIF socket before so that could be interesting trying to find one.

Installing a ZIF socket was one of the things that Andrew "Bunnie" Huang did when he first worked on hacking the Xbox.

See it in his now FREE book - Hacking the Xbox.  Available to download for FREE - https://nostarch.com/xboxfree

Edit I thought there was a picture of the ZIF socket installed in the book.  However, after a quick glance at it, I don't see it. Information on the socket he used is on page 92. (From what I recall, they are not cheap!)  I need to find the picture of it installed on the motherboard.

A copy is also downloadable from OGXbox.com's Download section:

 

[KaosEngineer]

Found it!

https://www.bunniestudios.com/bunnie/proj/anatak/xboxmod.html#flash

One location I found the socket for sale has it listed at $21.93 / single quantity pricing.

https://www.tedss.com/2025000538

[KaosEngineer]

I did find a similar socket from a different manufacturer listed on eBay for a lot less.  

https://www.ebay.com/itm/221251456589

[N64 freak]

@MrBriteSide Can you show us a few images of the board. It sounds like someone connected the flash enable points. Which clearly indicates this board has been modified.

As far as i‘m aware the 128mb and 64mb equiped debug kits all had flashing enabled by default.

The areas of interest for the images would be: 
-MCPX-X2
-PIC16LC63A
-The flash enable points

[MrBriteSide]

On 8/13/2021 at 8:22 AM, N64 freak said:

@MrBriteSide Can you show us a few images of the board. It sounds like someone connected the flash enable points. Which clearly indicates this board has been modified.

As far as i‘m aware the 128mb and 64mb equiped debug kits all had flashing enabled by default.

The areas of interest for the images would be: 
-MCPX-X2
-PIC16LC63A
-The flash enable points

Hey N64,

Sorry for the long waited reply. The photos are gonna be below for the areas in question. I took them with a macro and my phone light to help with visuals. If you think a better angle might help I'll try and get back faster.

[MrBriteSide]

[MrBriteSide]

[MrBriteSide]

[MrBriteSide]

This is a general shot. The only thing I've done to the board is add the LPC header and remove the flash chip and solder it to a breakout.

[N64 freak]

Found your problem!  
The board has a „P01“ (production) marked PIC16LC63A. To get the board to work you need a „D01“ (development) marked chip from a debug or development kit board.

Most likely the MCPX-X2 was installed onto a retail board. That the flash enable points are jumpered with solder instead of smd jumpers supports this thesis. So if that was done correctly you „just“ need to install a „development“ PIC16LC63A and flash a debug bios and the board should boot.

[MrBriteSide]

20 hours ago, N64 freak said:

Found your problem!  
The board has a „P01“ (production) marked PIC16LC63A. To get the board to work you need a „D01“ (development) marked chip from a debug or development kit board.

Most likely the MCPX-X2 was installed onto a retail board. That the flash enable points are jumpered with solder instead of smd jumpers supports this thesis. So if that was done correctly you „just“ need to install a „development“ PIC16LC63A and flash a debug bios and the board should boot.

This is an interesting find. I guess its definitely possible, the only reason why im hesitant is that I cant think of much of a reason why someone would do this/ go to this effort. Im not to doubting you by any means, but this seems like a lot of work for someone to effectively transfer the MCPX from one board to another (Assuming it was properly done and nothing went wrong) and then to have a small problem like that creep up.

I guess then my next question is, what's different between a development PIC and a retail PIC? From what I remember, i dont think the Flash of the PIC has been dumped yet. I would think the PIC wouldn't make sense to have a Dev version and a retail unless thats where the flash write enable is all handled as the PIC was used for basic system management as far as I know.

Getting my hands on something like that may be difficult as I received the board and only the board from an Ebay auction. Someone else then must've done the chip transplants and would then have the corresponding PIC from the dev/debug board that the MCPX was salvaged from.

[OGXbox Admin]

2 hours ago, MrBriteSide said:

This is an interesting find. I guess its definitely possible, the only reason why im hesitant is that I cant think of much of a reason why someone would do this/ go to this effort. Im not to doubting you by any means, but this seems like a lot of work for someone to effectively transfer the MCPX from one board to another (Assuming it was properly done and nothing went wrong) and then to have a small problem like that creep up.

I guess then my next question is, what's different between a development PIC and a retail PIC? From what I remember, i dont think the Flash of the PIC has been dumped yet. I would think the PIC wouldn't make sense to have a Dev version and a retail unless thats where the flash write enable is all handled as the PIC was used for basic system management as far as I know.

Getting my hands on something like that may be difficult as I received the board and only the board from an Ebay auction. Someone else then must've done the chip transplants and would then have the corresponding PIC from the dev/debug board that the MCPX was salvaged from.

I'm thinking this was a partner net console or whatever the beta of Xbox Live was called for devs. (if the eeprom contains an online key that might confirm that?) After that service was taken down someone probably attempted to mod it to retail and failed miserably. 

[N64 freak]

The SMC (PIC16LC63A) does play a big role in the system startup. It initializes the system and acts as a watchdog.

When the MCPX doesn’t correctly trigger the watchdog the SMC triggers a reset. This is where the famous frag does come from.

The PIC16LC63A has the ROP (Read Out Protection) enabled and there‘s no source to get a natchung development one other than a Dev, debug or chihiro board.

My guess is that someone wanted to build a debug board from a retail board and bought an MCPX-X2 from china without knowing he would need the matching SMC (PIC16LC63A) to go with it.

You could validate my theory by swapping the SMC (PIC16LC63A) to a retail board. If the retail board still boots then there’s no chance this board could have booted.

You could try getting your hands on a defective chihiro board. They are basically debug boards and someones pop up defective. Such a board would be the perfect donor. BUT only if the soldering for the MPCX-X2 was actually done properly and all is well with the rest of this board.

[MrBriteSide]

On 8/25/2021 at 11:54 PM, N64 freak said:

The SMC (PIC16LC63A) does play a big role in the system startup. It initializes the system and acts as a watchdog.

When the MCPX doesn’t correctly trigger the watchdog the SMC triggers a reset. This is where the famous frag does come from.

The PIC16LC63A has the ROP (Read Out Protection) enabled and there‘s no source to get a natchung development one other than a Dev, debug or chihiro board.

My guess is that someone wanted to build a debug board from a retail board and bought an MCPX-X2 from china without knowing he would need the matching SMC (PIC16LC63A) to go with it.

You could validate my theory by swapping the SMC (PIC16LC63A) to a retail board. If the retail board still boots then there’s no chance this board could have booted.

You could try getting your hands on a defective chihiro board. They are basically debug boards and someones pop up defective. Such a board would be the perfect donor. BUT only if the soldering for the MPCX-X2 was actually done properly and all is well with the rest of this board.

I see what you're saying. The one thing im just questioning is does anyone know what the actual difference between the two is? I've seen on XboxDevWiki there are numerous versions listed, but nothing saying on effectively what the difference between each version even is other then dev/debugs have this retail have that. No one seems to have hooked a bus sniffer to the I2C lines and even see whats going on during boot-up between the consoles.

Even so, with the retail PIC on the board, would you not be able to take a Gen 1.0 bios like the 3944 version, patch it by filling in the last 512 bytes of code with the actual extracted data and then run it on the MCPX X2 and have it work? Thats what I was thinking would work but didnt seem to.