Xecuter 3 Clone (R3dux) X3 - build.

[Bowlsnapper]

11 hours ago, trencherfield said:

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.

...whuuuuut? That's a new one for me. Interesting...

Kaos?

[KaosEngineer]

On 3/1/2023 at 4:13 PM, Bowlsnapper said:

...whuuuuut? That's a new one for me. Interesting...

Kaos?

I've not tested this procedure.  But, I always thought that once the BIOS was loaded from the modchip's flash, the chip could be removed without causing a problem.  The kernel gets loaded into RAM and runs from there. No need for the modchip anymore until the console is rebooted/power cycled which loads the BIOS/kernel again across the LPC bus. 

[xxkryptos]

> 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.

I'm not trying to be a dick. Hopefully not coming across that way. But why? This is not "Obvious" to me. Calling back to bios / firmware is a relatively new concept. I won't believe that the xbox does this until you show me the asm.

 

 

[trencherfield]

7 hours ago, xxkryptos said:

> 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.

I'm not trying to be a dick. Hopefully not coming across that way. But why? This is not "Obvious" to me. Calling back to bios / firmware is a relatively new concept. I won't believe that the xbox does this until you show me the asm.

 

 

No not at all. As I say, I have no idea why. I can only see what I test. The only reason I found out myself was seeing if I could get further by swapping chips on the LPC header. I tried another the other night (regular openxenium), same thing. Unless it's my 1.0 board or sommet. Will try another board and a 1.6 and see what that does I suppose.

Since this happens on chips with a short 2x6 pinheader, then that ommits it being anything with the SMbus pins (13/14) as queried by Prehistoric on page 1, as far as I can see.

Theoretically, if I can get past this and load an xbe, well then the r3dux chip would be a functional multibank chip, by using the switch panel which works, though without the config live. I guess the LCD would work, not tried that yet. Also the issue of flashing the chips to sort, as currently can only flash them before soldering them on.

I was hoping to get this done and dusted, so I could just get it working then everyone can make their own chips.

[trencherfield]

Just tested a V1.6 board with an openxenium boot using 5035 v1.6 bios.

Booted to Unleash X dash, removed chip, tried to launch XBMC xbe = freeze, black screen.

Reattached chip, cold booted to Unleash X, then XBMC, then removed chip again, tried to boot Halo off hard drive = freeze, same again.

Reattached chip, cold booted again to EvoX dash, tried to launch Halo, freezes on launch screen as pictured.

 

So, modchip needs to be on the LPC, even after loading BIOS up and to dash, else can't load any xbe, period.

Additional: With just say a 'cheap mod' chip on the LPC, which functions correctly, without any other IC or CPLD present, then one can assume that the Xbox does in fact require to access the flash again for XBE launches, and of course LPC cold reboots.

 

Edited March 3, 2023 by trencherfield
Additional.

[trencherfield]

Did some more testing back on the 1.0 board with various chips.

You can boot up say with 5035 bios on a genuine xenium chip, then once at a dashboard, lift that off and replace with a DuoX chip flashed with 5035 bios, and it will work and boot xbe's.

Now if you do the reverse, boot with the DuoX on 5035, then lift that and fit say the Xenium with 5035 then that will not work. This is because the cpld and OS on the flash chip has bank control and is not a dumb chip (like the DuoX is) so it can't find the correct bank.

Looking back at the R3dux X3 chip, this appears to be probably shutting off the bank register or access as I guessed. Either the code is missing for xbe calls back to it or its shutting down access.

So the current status of Kekules code he put on the github is unfinished. Simple as that. If anyone wants the jed file for programming and building one for testing etc give me a shout here.

I will look at trying the other code next. Other than that I'd say it's at a dead end, unless Kekule feels like releasing an update to the repo. Which by the look of it, he doesn't. So why setup the github in the first place begs the question. Make your own conclusions.

[Prehistoricman]

On 3/3/2023 at 3:31 AM, KaosEngineer said:

I've not tested this procedure.  But, I always thought that once the BIOS was loaded from the modchip's flash, the chip could be removed without causing a problem.  The kernel gets loaded into RAM and runs from there. No need for the modchip anymore until the console is rebooted/power cycled which loads the BIOS/kernel again across the LPC bus. 

It's theoretically possible for that to be true, but it's not how MS implemented the kernel.

When the kernel loads a new xbe, it basically reboots itself. Even the debug monitor command to load an XBE is called "magicboot". It's not a full reboot, so it doesn't read the entire kernel out. I tested this and it only reads 1668 bytes from flash when you launch a new XBE. My guess is that it's reading xcodes and then a small bit of code to go back to the kernel which is still in RAM.

[trencherfield]

1 hour ago, Prehistoricman said:

It's theoretically possible for that to be true, but it's not how MS implemented the kernel.

When the kernel loads a new xbe, it basically reboots itself. Even the debug monitor command to load an XBE is called "magicboot". It's not a full reboot, so it doesn't read the entire kernel out. I tested this and it only reads 1668 bytes from flash when you launch a new XBE. My guess is that it's reading xcodes and then a small bit of code to go back to the kernel which is still in RAM.

Thanks for verifying that. Appreciated.

[KaosEngineer]

5 hours ago, Prehistoricman said:

It's theoretically possible for that to be true, but it's not how MS implemented the kernel.

When the kernel loads a new xbe, it basically reboots itself. Even the debug monitor command to load an XBE is called "magicboot". It's not a full reboot, so it doesn't read the entire kernel out. I tested this and it only reads 1668 bytes from flash when you launch a new XBE. My guess is that it's reading xcodes and then a small bit of code to go back to the kernel which is still in RAM.

Interesting.

[Bowlsnapper]

2 hours ago, KaosEngineer said:

Interesting.

Yeah, this is the first I've ever heard of this. I'm genuinely perplexed, even with the limited knowledge I have.

[Prehistoricman]

This is the kernel API call for rebooting:

https://xboxdevwiki.net/Kernel/HalReturnToFirmware

Here's an MS implementation of changing XBE:

https://github.com/xerohour/xbox_leak_may_2020/blob/master/xbox_leak_may_2020/xbox trunk/xbox/private/ntos/xapi/k32/launch.c#L183

First, it takes the XBE info, like its path and name, and writes that to a special place in RAM. Then, it calls the HAL function to quick reboot.