Jump to content
OGXbox.com

Xecuter 3 Clone (R3dux) X3 - build.


trencherfield
 Share

Recommended Posts

Thought I'd stick this up here - since I was nudged by a friend to do so. (I posted it on a group)

Decided to have a go at making the Xecuter 3 clone (r3dux) chip.
Used ispLEVER to load up the github code, seemed ok (nag about missing x3.txt) but ran fine. Ran the fitter and produced the jed.
Programmed the cpld, in VM. Had to fiddle with the settings as got another nag. Wouldn't program in diamond so used the main VM.
Tried the flashbios 3.1... flashing not working, ID's verified of my chips doubled checked - all fine, so something wrong there. So decided to make various bios packs in terminal command... some 8x256, 4x512, 2x1's and some debug's etc along with various 2x1 X3 bios.
Can boot up some 256 x2 and the cromwell xblast etc to dashboard. Also boots X3 2913 1mb x2. Also tried 8x256 flashbios 3.0.3 (frags) so probably 3294 will frag too.
Switch panel functions correctly for all these bios in relation to size and buttons - so bank switching is fine.
No config live holding white on X3 bios.
 
Anyway, upon loading up dash... can navigate dash etc, but soon as I try loading any xbe then the loading screen comes up and hangs. That's it.
Call back to the lpc bios function seems out.
Tried various drive combos/bios/settings/dash etc all result the same - freeze on xbe launch.
That's where it's at. Can't flash the chips on X3. Either data line call error/ID register or maybe the pcb dunno yet, short on time. Have some dead purples to test up as well I suppose.
So, anyway in case anyone wants to have a go, thought I'd post up my experience with it so far for info.
(stutter on bios is just the usual no dvd connected in the video clip, have tried with one attached anyway)
 

IMG_1935.JPG

IMG_1933.JPG

  • Like 1
Link to comment
Share on other sites

You can try booting with a real X3 into config live and then hotswap to r3dux and see if you can change any settings.

Since the BIOS data can be read okay, I'm putting my money on the issue being SMBus comms. Xblast has a hacky way to detect X3, so this doesn't prove that the SMBus is working fine.

Did you program anything into the EEPROM? That's a step on the installation page that you didn't mention.

Link to comment
Share on other sites

Yeah tried that, have a couple working X3's... also removed the flash chips from the working X3CE and tried them on the r3dux. No joy unfortunately.

I am using the genuine X3 eeprom from the X3CE chip on the r3dux which I also lifted. I do have some eeprom chips as well to program up but have not bothered, since I was lifting the flash chips at the time I lefted the eeprom too.

Checked and read the 2mb flash chip - could not properly detect the 256k X3 backup chip - I don't think anyone has, I can read it.

Tried xecuter 2 bios and others, all have the same issue, load to a dashboard (the X3 bios loads up Evox dash), but then freeze on launch again of any xbe.
Also tried hot swapping on another Xenium after boot, that doesn't work either. So somethings up.

Link to comment
Share on other sites

Just now, Prehistoricman said:

Missing D0/ethernet/HDD connector?

Yeah. My work xbox there has D0 to ground at the side, so didn't bother with the r3dux connector. I did end up soldering the D0 wire to the D0 pad on the r3dux though in case it was that... still the same. Don't think LAN or HD LED will have any bearing though.
Yeah I've run out of ideas really.

Link to comment
Share on other sites

Aaron (Kekule) by the way saw my post on the group... said he'd try and remember to send me a new .jed file. So he probably needs to update the repo with a commit. Which I suggested, if it was easier.

It's an expensive chip to make really so its not something that's going to take off like the Openxenium for instance.... it's just too much work and the parts cost make it not worth it really. You can pick up an X3 for less lol

Link to comment
Share on other sites

4 minutes ago, Prehistoricman said:

You can swap the CPLD to find out if it's the PCB or the CPLD that's faulty.

CPLD appears fine, though I have a couple more I could try, I have some duff purple X3's too I was hoping to fix which is why I bothered in the first place :)
I could build a r3dux on a genuine purple x3 board too.

Link to comment
Share on other sites

> Call back to the lpc bios function seems out

Can you elaborate on this? My mind might be fogged up by modern day UEFI booted systems calling into runtime services.

Kernel is loaded into memory at this point. You've booted up and ran unsigned code. If you need to reach back to the LPC bus for services then maybe its a chip issue. I don't know where or why this would happen, but I'm not well versed?

What BIOS callbacks are you talking about?

 

Edit:

This seems like a kernel issue to me. Maybe? You load an unsigned dash no problem. The dash probably calls back to the kernel to do an executable load. At this point it freaks out.

In my mind, the chip did its job. If something doesn't maintain control after this it's another problem.

Edited by xxkryptos
Link to comment
Share on other sites

2 hours ago, xxkryptos said:

> Call back to the lpc bios function seems out

Can you elaborate on this? My mind might be fogged up by modern day UEFI booted systems calling into runtime services.

Kernel is loaded into memory at this point. You've booted up and ran unsigned code. If you need to reach back to the LPC bus for services then maybe its a chip issue. I don't know where or why this would happen, but I'm not well versed?

What BIOS callbacks are you talking about?

 

Edit:

This seems like a kernel issue to me. Maybe? You load an unsigned dash no problem. The dash probably calls back to the kernel to do an executable load. At this point it freaks out.

In my mind, the chip did its job. If something doesn't maintain control after this it's another problem.

Simple test. Boot a working chip, Xenium... whatever brand, gets to dash, lift your chip off the lpc and try booting an xbe.

So no, the chip is not doing its job after initial boot.
If you read some of psyko_chewbacca's info regarding his xblast lpc mod you'll see he mentions about this regarding his 'logic1' for lframe for instance as an example.

This is the limit of my knowledge as far as how the xbox communicates with the lpc after boot. The cheap mod for instance has no cpld on it, just the flash chip, so I gather from what I've read that it needs access back to the flash rom for each xbe launch etc.

I'm no programmer, all I've worked with is the arduino IDE and getting the OLED 20x4 to work. So despite being able to look at the source for this, I have no idea what I'm looking at or for.

Link to comment
Share on other sites

2 hours ago, Bowlsnapper said:

Are you sourcing the ics solely from genuine x3 chips?

No, that pic was me just throwing all kinds at it to see if I could boot the original flash chips.

I Have a range of chips, lots, so program various BIOS banks up for the 2mb flash chip for instance on an external flash programmer. This is how I got this far.

I can get Kekules flashbios 3.1 up and running, menu works, flashing does not. Chip ID codes are incorrect in the release it appears. Also can't hot-swap flash and neither can XblastOS flash.
So think there are major 'issues' in the code.

Kekule said he'd send me a new jed file, so assume he knows whats wrong, but has not updated the Github. Not responded back to me, maybe he's too busy with work.

IMG_1903.JPG

Link to comment
Share on other sites

What is the Manufacturer and Device ID of the flash memory chips you have?

An X3's AMD 29F016 is Manufacturer ID 0x01 and Device ID 0xad.

Edit: Team Xecuter's raincoat implementation limited the chips it can flash to only 2.  Those used on their X3 and X2.6/X2.6CE modchips (Edit: Possibly any X2.x modchip.)

Excerpt from FlashBIOS 3.0.3's source code - flashbios_x3_303/drivers/flash/BootFlashUi.c:

const KNOWN_FLASH_TYPE aknownflashtypesDefault[] = {
      // default flash types used if /etc/raincoat.conf not available
    
     { 0x01, 0xd5, "XECUTER2", 0x100000 }, 
     { 0x01, 0xad, "XECUTER3", 0x200000 }, 

    { 0, 0, "", 0 } // terminator
};

Edit: I'm not sure if FlashBIOS 3.1 changed anything to allow for other flash devices to be used.

Link to comment
Share on other sites

27 minutes ago, KaosEngineer said:

What is the Manufacturer and Device ID of the flash memory chips you have?

An X3's AMD 29F016 is Manufacturer ID 0x01 and Device ID 0xad.

Edit: Team Xecuter's raincoat implementation limited the chips it can flash to only 2.  Those used on their X3 and X2.6/X2.6CE modchips (Edit: Possibly any X2.x modchip.)

Excerpt from FlashBIOS 3.0.3's source code - flashbios_x3_303/drivers/flash/BootFlashUi.c:

const KNOWN_FLASH_TYPE aknownflashtypesDefault[] = {
      // default flash types used if /etc/raincoat.conf not available
    
     { 0x01, 0xd5, "XECUTER2", 0x100000 }, 
     { 0x01, 0xad, "XECUTER3", 0x200000 }, 

    { 0, 0, "", 0 } // terminator
};

 

Yes they are AM29F016D and the ID's are correct. I'm on about Kekules flashbios 3.1 (which is not Xecuters - well was, but that's besides the point) anyway yes they are the correct ID etc, checked all that. His flashbios returns the 0xFF status code errors and halts. Xecuter 3.0.3 won't boot... just frags. Hence I just went straight to flashing BIOS offboard first to bypass that for now.

The 256 on an X3 is actually unknown in truth, it has an odd pin 9 and does not match up to any of the AMD devices in the software (and they are all there), though is similar to AM29F002BB used here. Again not important at this stage as its the backup anyway, but it does boot whatever I flash to it before soldering it on.

It also appears that an original X3 uses a Lattice LC4128V (not the 4256 as used here), again not relevant in this application at the moment.

The flashing is a secondary issue really, either the cpld code is blocking access or has the wrong ID's again. The main issue at the moment is after booting up say X3 2913 bios (besides no config live) once at any dash (bios path dependant of course) then you can navigate the dash, but can't load an xbe.

So as above, its probably an early release of Kekules code and needs work. I haven't looked at it yet as I got tired of it after doing so much testing & soldering chips on/off etc. Will have a look at it when I feel like it.

Did edit some hex of 3.1 which I thought the cpld might be looking for, but didn't work, just went bananas! (did say mention I can't code lol)

Link to comment
Share on other sites

23 hours ago, trencherfield said:

The 256 on an X3 is actually unknown in truth, it has an odd pin 9 and does not match up to any of the AMD devices in the software (and they are all there), though is similar to AM29F002BB used here. Again not important at this stage as its the backup anyway, but it does boot whatever I flash to it before soldering it on.

Maybe it was an Am29F002NB that doesn't actually use pin 9.  It is an NC (no connection) pin to the internal circuitry.

 

Link to comment
Share on other sites

23 hours ago, trencherfield said:

Did edit some hex of 3.1 which I thought the cpld might be looking for, but didn't work, just went bananas! (did say mention I can't code lol)

You can't directly hex edit most of the BIOS' data.  It is compressed and encrypted.  To obtain the actual assembly code to edit things, the BIOS needs to be unpacked into its constitute parts - 2bl.img, remainder.img and xboxkrnl.img.

Link to comment
Share on other sites

1 hour ago, KaosEngineer said:

Maybe it was an Am29F002NB that doesn't actually use pin 9.  It is an NC (no connection) pin to the internal circuitry.

 

Yeah I looked up the PDF's and saw that, but this particular X3 chip, whatever they had done, does not match that pin 9 - wasted hours upon hours and thought sod it, it's of no use here anyway. Kekule specced his own for the board and code, but I was just interested to see. As I say it does read, and if you ignore that pin it will write, but does not match up.

See pic attached - some say its AM29LV020B .... tried that, same result. Maybe Team Xecuter had a special, who knows.

Screenshot 2023-02-24 at 15.07.58.png

Edited by trencherfield
Link to comment
Share on other sites

1 hour ago, KaosEngineer said:

You can't directly hex edit most of the BIOS' data.  It is compressed and encrypted.  To obtain the actual assembly code to edit things, the BIOS needs to be unpacked into its constitute parts - 2bl.img, remainder.img and xboxkrnl.img.

Yeah correct, only realised after that it has RC4 encryption. Was trying to add it to xblast. So then looked into unpacking bios in xbtool etc and got fed up setting that up with the key from complex bios etc.

Just been looking at the r3dux HDL... as expected, means bugger all to me. Guess I could compare it with some of Ryzee's LPC code to see, but doubtful.

Attached it here as a text file if anyones interested.

Thanks for the suggestions.

r3dux.txt

Link to comment
Share on other sites

I've found this other repo as well...

https://github.com/maximus64/OpenX3_GW

Which is for the original X3, so might solder up to the test points on one of my purple x3's and program the cpld (4128V) will check that. Will have to lift that LAD0 cpld pin and solder a jumper wire over.

Code loads up in the Lattice isp, so worth a shot on that one. If I can get that working, then I could design a new PCB to accommodate that in Eagle probably.

  • Like 1
Link to comment
Share on other sites

On 2/24/2023 at 4:31 AM, trencherfield said:

Simple test. Boot a working chip, Xenium... whatever brand, gets to dash, lift your chip off the lpc and try booting an xbe.

This is nutty to me. I will try it soon. I don't doubt that it's the truth. First thing I'd do is let the kernel get loaded, search for some code signature in kernel land, then disable the signature check in the loaded kernel. The kernel exports are a little difficult to figure out, but you *can* edit high memory and do this. Hell, even if you can't do it by the API, everything runs in kernel mode and you have free reign. "You" means TX or whoever btw, not OP. I think they could have had a better product.

Where does X3 / clone hand off control? You could compare high memory to a real console (Your console with the chip lifted). What gets modified? anything?

Would love to see this under the debugger.

Link to comment
Share on other sites

3 hours ago, xxkryptos said:

This is nutty to me. I will try it soon. I don't doubt that it's the truth. First thing I'd do is let the kernel get loaded, search for some code signature in kernel land, then disable the signature check in the loaded kernel. The kernel exports are a little difficult to figure out, but you *can* edit high memory and do this. Hell, even if you can't do it by the API, everything runs in kernel mode and you have free reign. "You" means TX or whoever btw, not OP. I think they could have had a better product.

Where does X3 / clone hand off control? You could compare high memory to a real console (Your console with the chip lifted). What gets modified? anything?

Would love to see this under the debugger.

What you are describing and the vhdl code which obviously interfaces with these instructions, including the IO registers the X3 uses, are all way beyond my capabilities here. It's not just TX X3 though, all chips do it. That's because it loads the BIOS through the LPC, so the xbox will need access back to it just like a PC, which obviously its based on.

Link to comment
Share on other sites

11 minutes ago, trencherfield said:

What you are describing and the vhdl code which obviously interfaces with these instructions, including the IO registers the X3 uses, are all way beyond my capabilities here. It's not just TX X3 though, all chips do it. That's because it loads the BIOS through the LPC, so the xbox will need access back to it just like a PC, which obviously its based on.

From my understanding, once the bios has been read from the lpc by the mcpx, the chip has served its purpose until the next cold reboot, since the bios has been loaded into RAM. I don't believe there is any modification or writing to and from the chip afterward, except in the event of erasing or writing to the flash. The vhdl or cpld is the code for the IC that acts as a bus or bridge between the MCPX and the flash chip and handles the transfer of data between the two.

Unless I'm misunderstanding what you were trying to say. In which case, derrrrrrr.

Link to comment
Share on other sites

3 minutes ago, Bowlsnapper said:

From my understanding, once the bios has been read from the lpc by the mcpx, the chip has served its purpose until the next cold reboot, since the bios has been loaded into RAM. The vhdl or cpld us the the code for the IC that acts as a bus or bridge between the MCPX and the flash chip and handles the transfer of data between the two.

Well, I have no idea why, but if you lift your chip (any that I've tested) after booting to the dash it won't boot anything else and freeze.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

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.