McPX X2 Compatible Bios

[MrBriteSide]

Hey guys,

So I have a project where I was able to come in possession of what im assuming to be a original Xbox test kit motherboard. The reason I say this is because it is an xbox motherboard with an MCPX X2 as appose to the X3 and yet it only has 64mb of ram soldered to it. It also looks like one of the previous owners tried to run Hexen and flash a retail bios on it since the solder points have been connected. Since (I'm assuming) it has a retail bios loaded on it it wont boot due to the lack of hidden boot sector in the X2. Ive finally fixed some OpenXeniums ive been working on so I have access to a couple modchips that can fit 1mb bioses in them. I am wondering, with the lack of 128mb of ram on the board, does anyone know if the development bioses will still boot to a screen showing something at least like the startup animation? I would like to see if the board is at least still functional with a proper bios and not completely nuked since it is currently in a state of FRAG that I hope is due to a retail BIOS being flashed on there. 

 

Thanks

[eeksdee]

Debug kernels should be able to work on 64MB on a X2, they aren't specific to 128MB. But such a shame the previous owner ruined the board by reflashing what was on it. Those usually have internal kernels built in debug mode (checked). I wouldn't really call it a test kit either, just a random run they decided to do.

[OGXbox Admin]

Yeah you can boot a debug bios on a lpc modchip just fine. You can also unground d0 and run the recovery disk and it will reflash your tsop. I know because I recovered one this way. 

[samspin]

I thought I'd chime in here as I also have a couple of boards with MCPX X2 chips on them (in my case with the full 128MB RAM on them) originally used in Sega Chihiro consoles. From the get-go they FRAGd until I applied heat to reflow the GPU, and now they light up solid green but display nothing. From what I can see, all non-retail boards *always* have the TSOP write enable points bridged, and have the LPC port populated as that is where the mediaboard is normally plugged into. I therefore strongly believe that this was also the case for your test board: I do not think a previous owner tried to flash it, it likely contains the Chihiro bios which does not display any video at all unless you have the mediaboard plugged in so that it can find "segaboot.xbe". I have been able to get them to boot from common Aladdin modchips (that are 256KB in size) by grounding D0 but only with a BIOS specifically designed to boot externally- and even then, it's not a debug BIOS, but a very early retail test BIOS from the recent source code leak. I think this is because how the address regions are hardcoded. I'm also struggling to find a modchip that has 1MB to fit a full debug BIOS that does not manipulate the code being passed to the Xbox LPC port. Xeniums will not work because they always expect to boot from an X3 MCPX, and therefore always respond from 2BL (completely skipping the required boot sector which would normally be overlayed by the Secret ROM on an X3) no matter what you flashed to it (the 2BL is hardedcoded in the Xenium and then it passes execution to the chosen BIOS, as it is designed to work in an X3). So matter what I flash to my Xenium to set up, even with 'fastboot', it always FRAGs once moved to the test boards. Try as I might, I cannot overwrite the original TSOP because I have no dashboard files that work with such an early retail BIOS. I am planning to do it the hard way by removing the TSOPs with a hot air station and flashing them manually with a PIC programmer in a socket. I just really hate doing it this way because the damn legs are so tiny and it's a nightmare getting them back on the board without getting solder bridges. If I do succeed in converting my boards this way, I'll write back.

Edited August 25, 2020 by samspin

[eeksdee]

Chihiro boards are always 128MB.

[KaosEngineer]

20 hours ago, OGXbox Admin said:

Yeah you can boot a debug bios on a lpc modchip just fine. You can also unground d0 and run the recovery disk and it will reflash your tsop. I know because I recovered one this way. 

Hmm, I thought flashing the TSOP  was not possible after the console booted from an LPC bus attached flash chip.

The recover disk must know a secret way to re-enable access to the TSOP flash chip on the motherboard that was not discovered or released by the Xbox scene dev teams.  Also, it could be a difference between the MCPX X2 (devkit) version vs. the retail MCPX X3 chip.

[KaosEngineer]

On 8/24/2020 at 12:59 PM, MrBriteSide said:

Hey guys,

So I have a project where I was able to come in possession of what im assuming to be a original Xbox test kit motherboard. The reason I say this is because it is an xbox motherboard with an MCPX X2 as appose to the X3 and yet it only has 64mb of ram soldered to it. It also looks like one of the previous owners tried to run Hexen and flash a retail bios on it since the solder points have been connected. Since (I'm assuming) it has a retail bios loaded on it it wont boot due to the lack of hidden boot sector in the X2. Ive finally fixed some OpenXeniums ive been working on so I have access to a couple modchips that can fit 1mb bioses in them. I am wondering, with the lack of 128mb of ram on the board, does anyone know if the development bioses will still boot to a screen showing something at least like the startup animation? I would like to see if the board is at least still functional with a proper bios and not completely nuked since it is currently in a state of FRAG that I hope is due to a retail BIOS being flashed on there. 

 

Thanks

Flash the original debug BIOS to the OpenXenium modchip - add it as a Load Item to the XeniumOS while installed on another Xbox.

You'll have to set it to autoload so the XeniumOS doesn't try to start when the console is powered on but instead loads the debug BIOS.

[samspin]

57 minutes ago, KaosEngineer said:

Flash the original debug BIOS to the OpenXenium modchip - add it as a Load Item to the XeniumOS while installed on another Xbox.

You'll have to set it to autoload so the XeniumOS doesn't try to start when the console is powered on but instead loads the debug BIOS.

This is precisely what I tried to do, but it still FRAGs once I move the Xenium chip to the X2 board. I truly believe this is due to the Xenium chip initializing itself and loading a common 2BL before passing onto where the remainder and kernel would be from the BIOS bank. Since the Xenium then won't work normally in either a retail or X2 board at that point I end up having to use emergency mode and flashing a new BIOS over the network. If anyone else manages to find a way to get around this please do tell.

[MrBriteSide]

Well interesting to see how this has developed. I guess that is one thing I didnt know about the Xenium and how it goes about booting. Makes me think now I should use me FPGA dev board and get craft something up such that the system will be able to view the exact flash image and nothing special. In regards to the X2 motherboard, I am certain it is a test kit board and not a Chihiro. From what I understand of what you are saying, all Chihiros are 128mb and up for RAM. This board is only 64mb. I also think the previous owner did try and do a FLASH overwrite with something like hexen since, unless someone wants to show pictures of the bridge points from there dev-kit, the bridge points look very hand-soldered. At the moment I have removed the memory chip with a hot air system and am trying to find out where the hell I put my TSSOP breakout board that I had ordered a little while back. I made a little program that fit on a TI dev kit that read out the memory contents of a retail 256kB flash chip correctly and so I plan on doing that once I find the damn breakout. Then I can make it official once and for all if one of the previous owners tried to flash the chip with a retail BIOS, or if maybe the board is just toast in general.

[MrBriteSide]

7 hours ago, KaosEngineer said:

Flash the original debug BIOS to the OpenXenium modchip - add it as a Load Item to the XeniumOS while installed on another Xbox.

You'll have to set it to autoload so the XeniumOS doesn't try to start when the console is powered on but instead loads the debug BIOS.

Out of curiosity, which debug bios are you talking about? When I go into the 5849 SDK, I see 3 bios's. A DVT 4 one, DVT 6 one and an XBlade one. I tried the DVT 6 and XBlade one and neither of them seemed to work. They both just instantly FRAG'd making me wonder if its a side effect more of the Xenium and not the bios image.

[OGXbox Admin]

14 hours ago, KaosEngineer said:

Hmm, I thought flashing the TSOP  was not possible after the console booted from an LPC bus attached flash chip.

The recover disk must know a secret way to re-enable access to the TSOP flash chip on the motherboard that was not discovered or released by the Xbox scene dev teams.  Also, it could be a difference between the MCPX X2 (devkit) version vs. the retail MCPX X3 chip.

Yeah I didn't just say it or make it up. I've done it. 

[KaosEngineer]

1 hour ago, OGXbox Admin said:

Yeah I didn't just say it or make it up. I've done it. 

Have you, can you, no make that will you rip the files from a Recovery disc and share them?

[KaosEngineer]

8 hours ago, MrBriteSide said:

Out of curiosity, which debug bios are you talking about? When I go into the 5849 SDK, I see 3 bios's. A DVT 4 one, DVT 6 one and an XBlade one. I tried the DVT 6 and XBlade one and neither of them seemed to work. They both just instantly FRAG'd making me wonder if its a side effect more of the Xenium and not the bios image.

I don't know which BIOS the .../bios/original/debug.rar archive holds that's on xbins' FTP server.

Downloadable from here - https://downloads.diodematrix.com/homebrew/xbins/Console Based Applications/bios/original/debug.rar

 

Edit: The MD5 hash of this rar archive's debug.bin file is F38D3E050F78E8B5B7105386E055E59D.  I don't know if it matches one of the BIOS files you mentioned.

 

[KaosEngineer]

8 hours ago, MrBriteSide said:

...<some text removed>...

 They both just instantly FRAG'd making me wonder if its a side effect more of the Xenium and not the bios image.

Set the debug BIOS as the default item and enable Instant Boot in the Xenium OS Settings menu. 

As discussed in the XeniumOS v2.0 User Manual on page 8 under the section Setting the Default Launch Item.

I believe all of these operations will have to be performed on a different Xbox then swap the OpenXenium modchip to the debug motherboard.

The Xenium OS is not booting on the debug motherboard is it?

[OGXbox Admin]

1 hour ago, KaosEngineer said:

Have you, can you, no make that will you rip the files from a Recovery disc and share them?

It's not special to me... if that's what you are implying. I don't want to distribute the xdk recovery disks on this site as that could make us a target. They are pretty widely available out there. 
Are you insinuating that I am not being truthful in some way? 

[MrBriteSide]

2 hours ago, KaosEngineer said:

Set the debug BIOS as the default item and enable Instant Boot in the Xenium OS Settings menu. 

As discussed in the XeniumOS v2.0 User Manual on page 8 under the section Setting the Default Launch Item.

I believe all of these operations will have to be performed on a different Xbox then swap the OpenXenium modchip to the debug motherboard.

The Xenium OS is not booting on the debug motherboard is it?

This is exactly what I did with the BIOS marked DVT6. I think the specific version was 5844 or something like that that was packed within the 5849 SDK. Its hard to tell without the XenoimOS source code, but I think SamSpin is right in terms of how the Xenium works. It hooks in and hijacks the 2BL process with custom X-codes and such which is why its able to offer services such as recovery, quick boot and multi bios boot without having toggle switches. The system regardless of what happens boots to XeniumOS but immediately XeniumOS checks status bits like quickboot and such which is why its able to have custom LED colors display depending on the bios you have setup. It would make sense then why it still FRAG's even with those setting on since that "hidden" X3 section wont be filled in on the Xenium hijack section and the X2 xbox will directly be requesting the reset vector data from the Xenium which it doesnt have as appose to an X3 which starts in the hidden section and then gets hijacked. At least thats my take on things.

[MrBriteSide]

On 8/24/2020 at 6:24 PM, OGXbox Admin said:

Yeah you can boot a debug bios on a lpc modchip just fine. You can also unground d0 and run the recovery disk and it will reflash your tsop. I know because I recovered one this way. 

Once I can get at least something booting, debug or hacked retail, this is what I plan on doing so I can properly setup a hard drive. I find it interesting since Ive heard this is how the Xbox ROM was flashed from the factory from what I assume where Pogo pin style connectors to the LPC header. Surprised no one has really gone into depth with how the factory recovery actually happens since all the homebrew TSOP ROM recovery methods with modchips seem a little sketchy and only seem to work on the 1mb ROM xbox's.

[OGXbox Admin]

12 minutes ago, MrBriteSide said:

Once I can get at least something booting, debug or hacked retail, this is what I plan on doing so I can properly setup a hard drive. I find it interesting since Ive heard this is how the Xbox ROM was flashed from the factory from what I assume where Pogo pin style connectors to the LPC header. Surprised no one has really gone into depth with how the factory recovery actually happens since all the homebrew TSOP ROM recovery methods with modchips seem a little sketchy and only seem to work on the 1mb ROM xbox's.

The confusion is that on a retail... this absolutely does not work like this.
I didn't expect it to work like this on my debug... but it did. The debug had a bad flash and wouldn't boot.
 I booted from a Chameleon modchip with debug bios installed to my lpc and booted to the xdk dash. I backed up all data on the hdd and popped in the recovery disc. As soon as I saw it was loading the recovery executable I flipped my toggle to turn the chameleon off. (ungrounded D0). I assumed it would just fail to flash anything at that point since on retail that's what would have happened. It proceeded and shut off the console. I pulled the chip off the header and booted up and it worked. 

Edit: I always put the yoshihiro bfm bios on there that lets the debug run retail xbe's. I doubt that had anything to do with it... but thought I would mention it. 

[samspin]

6 minutes ago, OGXbox Admin said:

The confusion is that on a retail... this absolutely does not work like this.
I didn't expect it to work like this on my debug... but it did. The debug had a bad flash and wouldn't boot.
 I booted from a Chameleon modchip with debug bios installed to my lpc and booted to the xdk dash. I backed up all data on the hdd and popped in the recovery disc. As soon as I saw it was loading the recovery executable I flipped my toggle to turn the chameleon off. (ungrounded D0). I assumed it would just fail to flash anything at that point since on retail that's what would have happened. It proceeded and shut off the console. I pulled the chip off the header and booted up and it worked. 

I have a feeling this worked for you because on retail boards, the X3 secret ROM fixes the address lines during the boot process when the D0 point is grounded, preventing you accessing the TSOP even if you unground it. However the X2 on debug, test, and Chihiro boards has no secret ROM so this shouldn't happen! In that case I may try this method with an Xecuter Lite 2.3B I've just bought, as it has 1MB which is plenty for the debug BIOS to fit (although I will have to hotswap it from a retail in order to flash the debug BIOS onto it in the first place of course, as the flash chip is non-removable). As far as I can see, this modchip has plain old bank switches and does not have any custom fancy OS that adds features on the expectation it be used on a retail board. If it boots the debug BIOS properly I'll unground D0 and go from there the same way you did after bunging in a burned CD with the XDK Recovery. Fingers crossed this will work!

[MrBriteSide]

2 hours ago, samspin said:

I have a feeling this worked for you because on retail boards, the X3 secret ROM fixes the address lines during the boot process when the D0 point is grounded, preventing you accessing the TSOP even if you unground it. However the X2 on debug, test, and Chihiro boards has no secret ROM so this shouldn't happen! In that case I may try this method with an Xecuter Lite 2.3B I've just bought, as it has 1MB which is plenty for the debug BIOS to fit (although I will have to hotswap it from a retail in order to flash the debug BIOS onto it in the first place of course, as the flash chip is non-removable). As far as I can see, this modchip has plain old bank switches and does not have any custom fancy OS that adds features on the expectation it be used on a retail board. If it boots the debug BIOS properly I'll unground D0 and go from there the same way you did after bunging in a burned CD with the XDK Recovery. Fingers crossed this will work!

Maybe this is another hardware difference between the X2 and X3. To my knowledge there hasnt been much documented difference between the two other then one has a secret ROM and the other doesnt and one comes on retail hardware and the other comes on debug/development and Chihiro hardware. Would be nice if there was more thorough documentation on what the differences are since I thought the only hardware level difference was the ROM section. I dont know if people ever looked into whether there is a special register you write to through the PCI bus that will re-enable the FLASH access and instead just accepted the FLASH recovery method developed by the Chameleon people.

[KaosEngineer]

8 hours ago, OGXbox Admin said:

It's not special to me... if that's what you are implying. I don't want to distribute the xdk recovery disks on this site as that could make us a target. They are pretty widely available out there. 
Are you insinuating that I am not being truthful in some way? 

No, I'd not seen ripped recovery disc images online. (Not that I've really looked for them.)  I just wanted to get a copy of the content to try and reverse engineer some of the code to see how it gains access to flash the TSOP if booted from a modchip. 

[GoTeamScotch]

Wish I would have known OpenXenium modchips don't work on MCPX X2 (devkit) motherboards before I ordered a couple. Lol

I ran into a similar situation of needing to put a debug BIOS onto a modchip to fix a debug kit. Watching this thread.

[KaosEngineer]

On 8/28/2020 at 9:11 PM, GoTeamScotch said:

Wish I would have known OpenXenium modchips don't work on MCPX X2 (devkit) motherboards before I ordered a couple. Lol

I ran into a similar situation of needing to put a debug BIOS onto a modchip to fix a debug kit. Watching this thread.

Try that DuoX2 modchip.  It has 512KB BIOS banks and the debug BIOS is actually a 512KB BIOS not 1MB.  The 1MB file is used to flash the entire 1MB flash chip on v1.0/1.1 motherboards.

The only BIOS I know of for X2 MCPX's is a debug BIOS used on Debug or Dev Kits.

[MrBriteSide]

Okay so its been a while since I've last posted so I'll give a quick update. At the moment I was able to create a new CPLD image for the OpenXenium I'm dubbing the dumbXenium. This effectively transforms the xenium into a generic 1mb modchip with no special features. After testing it with a couple bioses (stock 3944 and X2 5035) I was able to get it working on a retail board. After flashing it with the bioses packed in with the XDK 5849 (or whatever the number is) I tried it out with the DV6 and Xblade labeled bioses. Nothing. Ill try it with a bios that KaosEngineer suggested earlier but at this time its not looking to good for the dev board. I might try and just give it a good cleaning with some iso and distilled water and just inspect the hell out of the board. As well Im planning on soldering some wires to one of the xenium modchips I made, specifically to the LPC data pins so I can try and monitor if any data is even transferring through to the MCPX. The logic analyzer I have isnt technically rated for that bandwidth, but it should be able to at least show some activity on the LAD lines. Im getting tired.

[GoTeamScotch]

On 8/31/2020 at 6:45 PM, KaosEngineer said:

Try that DuoX2 modchip.  It has 512KB BIOS banks and the debug BIOS is actually a 512KB BIOS not 1MB.  The 1MB file is used to flash the entire 1MB flash chip on v1.0/1.1 motherboards.

The only BIOS I know of for X2 MCPX's is a debug BIOS used on Debug or Dev Kits.

This method worked for me. 

I split the 1MB debug bios to a 512KB version, flashed it to my Duo X2 Lite using a retail console, then moved the modchip over to my DVT4 kit and it booted right up. Now I just need to get the TSOP flashed properly so I can hook the serial debugging daughter board back up again.

On 8/24/2020 at 5:24 PM, OGXbox Admin said:

Yeah you can boot a debug bios on a lpc modchip just fine. You can also unground d0 and run the recovery disk and it will reflash your tsop. I know because I recovered one this way. 

I tried this with my dvt4 unit and it didn't work. I tried a few times using different timings. I even tried leaving the chip on and just removing the D0 wire. I can flash the modchip on the lpc port just fine using the recovery disc, just not the tsop.

Is your success due to the fact that you're using a Chameleon modchip? https://www.xbmc4xbox.org.uk/forum/viewtopic.php?t=433