Jump to content
OGXbox.com

MrBriteSide

Members
  • Posts

    32
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MrBriteSide's Achievements

Rookie

Rookie (2/14)

  • Dedicated Rare
  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done

Recent Badges

3

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.