X2 5035 Bug Reports


VIP Member
Jan 29, 2004
SE Pennsylvania, USA
Just posted this over in the XBMC forum and now bringing it here, hoping that I'm on the right track and a solution can be found. Xecuter, we need your help.

From the XBMC forums:
ok, I've figured out the source of the problem but just can't wrap my head around it well enough to explain it properly. (F'ing ADD. This is now the 5th attempt I've taken at trying to get this out in text. I deleted the previous 4 before posting.) Basically the X2 BIOS is aware of the X2 bank select switch. Any access to the BIOS gets mapped to the appropriate area and duplicated to equal a 1024K image. If you change the switch position once booted the next BIOS read will look to the alternate area. Without rebooting or launching anything I did two consecutive dumps, the only difference was the position of the switch. On one dump I saw the first bank repeated twice, on the second dump I saw the second bank repeated twice. If I launched an XBE with the switch in the changed position the system would lock. So far a BIOS dump and XBE launch are the only two things I've seen that trigger a BIOS code read. The dump because, well, that's what it is designed to do and an XBE launch because in a way it is sort of a mini-reboot.

When booting the EvoX BIOS it is not switch aware, it just shows the BIOS as it was flashed. Changing the switch has no impact.

It seems to me that Xbox BIOSes load themselves to memory and then define the area to read from as the 1024K mark minus the size of the BIOS itself. So a 256K BIOS would expect to read from 768K to 1024K when BIOS data is needed, a 512K BIOS would read from 512K to 1024K. This would explain the following on X2 chips:
*256K BIOSes need to be doubled up, because while at first boot the system reads from byte 1 after the BIOS starts executing it instructs itself to read from 1024K minus a specific offset (less than 256K).
*EvoX won't boot from an X2 if only on bank 1. (at least I can't get it to work.) Since it isn't switch aware when it looks to the offset for code it will find a different BIOS. I'm thinking of trying to prove this by making an EvoX/FlashBIOS/FlashBIOS/EvoX 1024K image and flashing. I've got an X2 programmer to recover if needed, I just don't want to have to crack the box open.

It seems the action of pulling the chip ID breaks the X2 BIOS' magic switch mapping ability. The BIOS is now reported the same was as EvoX would report it, one lump 1024K image. Now, combine this with my offset theory above, and what happens is if you've got an image with X2CL/FlashBIOS/FlashBIOS (what I typically recommend) when the magic breaks and the X2 BIOS looks to the offset it will no longer see itself, it will instead see FlashBIOS. Crash. But if you've got the X2 BIOS on the second bank, no mapping is necessary, it's already in the right place regardless of what bank you booted off of.

So, what needs to be figured out is why the chip ID read breaks the switch-aware magic. This really puts the ball in Xecuter's court I guess. I'm hoping they can figure it out.

Ow... my brain.