Posts: 35
Joined: Nov 2005
Reputation:
10
Well, I tried to do what was asked but it's not working on my X2 box. X3 box I get a dump of the BIOS and eeprom just fine. No go on the X2 either with or without modchip detection. Turning up debugging now to see if I can get any clues.
-Whoopin'
Posts: 35
Joined: Nov 2005
Reputation:
10
No lockup, but no dumpfiles either. Instead in the python log I see:
AttributeError: 'module' object has no attribute 'execbuiltin'
-Whoopin'
Posts: 3,909
Joined: Dec 2004
Reputation:
20
Nuka1195
Skilled Python Coder
Posts: 3,909
import xbmc
xbmc.executebuiltin("backupsysteminfo")
Posts: 35
Joined: Nov 2005
Reputation:
10
That worked, thanks.
So I got two sets of files. Ran a compare of them and found that byte for byte they were identical except for BIOSBackup.bin. Will this still provide anything useful? I'd prefer to keep my EEPROM in my own hands if possible.
-Whoopin'
Posts: 35
Joined: Nov 2005
Reputation:
10
Pulled out X2BM to pick apart these files, looks like may not be anything useful. Of the BIOS extracted when the chip ID hadn't been probed there were two 512K images. Found that these are vaild X2CL 5035 BIOS images. The file that was created when the chip ID was probed had 3 files... one 5035 image and two 256K FlashBIOS 3.0.3 images. Now, this may provide a clue. One thing I noticed is that when the Xbox locks up after a chip ID probe followed by an XBE execute occurs, if I press the eject button I get FlashBIOS loaded on screen.
Now, I'm not certain on this but I seem to think that the entire 1024K BIOS gets loaded into memory on boot, right? I suspect that only the chip's selected boot BIOS gets loaded into that 1024K, repeated to fill it if necessary. If (for whatever reason) the system is expecting to be able to execute from any byte offset of that code and instead of finding X2CL it hits FlashBIOS... whack. Lockup. I guess the chip ID probe is refreshing the memory image byte-for-byte off the chip. Going to run a test, I'll reflash with X2CL 5035 on both banks and see if XBMC locks after probe. Results in a few...
-Whoopin'
Posts: 35
Joined: Nov 2005
Reputation:
10
Imagine that, after the flash ran the same tests and data collection. Two identical BIOSBackup.bin files, each with two copies of X2CL 5035 in them. And no problem executing XBEs. Going to bring this info over to the Team Xecuter forums, hopefully I'll get some input.
-Whoopin'
Posts: 26,215
Joined: Oct 2003
Reputation:
187
Nice work. Let us know if you hear anything from Xecuter.
Posts: 35
Joined: Nov 2005
Reputation:
10
While I was waiting for a response I was also thinking about this further... I'm wondering if this is really pinned down to an X2 chip/BIOS issue. Since it looks like the chip ID query is pulling a full 1M BIOS off the chip and into memory, what happens under different combinations? What if I've got EvoX in the first 512K and FlashBIOS in the second 512K of an X2? What was in the 512K after the 5035 BIOS I had on my X3? What do other chips see? While I really don't want to muck around with my setup, I'm going to try the following tests this weekend:
* X2 with EvoX/EvoX/FlashBIOS/FlashBIOS, dump before query
* X2 with EvoX/EvoX/FlashBIOS/FlashBIOS, dump after query
* X2 with FlashBIOS/FlashBIOS/EvoX/EvoX, dump before query
* X2 with FlashBIOS/FlashBIOS/EvoX/EvoX, dump after query
* X2 with EvoX/EvoX/EvoX/EvoX, dump before query
* X2 with EvoX/EvoX/EvoX/EvoX, dump after query
* X2 with FlashBIOS/FlashBIOS/5035, dump before query
* X2 with FlashBIOS/FlashBIOS/5035, dump after query
* X3 with 5035 in banks 5/6, FlashBIOS in 7/8, dump before query
* X3 with 5035 in banks 5/6, FlashBIOS in 7/8, dump after query
* X3 with FlashBIOS in banks 5/6, 5035 in 7/8, dump before query
* X3 with FlashBIOS in banks 5/6, 5035 in 7/8, dump after query
* X3 with 5035 in banks 5/6 and 7/8, dump before query
* X3 with 5035 in banks 5/6 and 7/8, dump after query
I only have an X2 and X3 to test with. Anyone able to run similar tests on a non-Xecuter chip? Before the move/removal of the chip ID probe (i.e., in the April 15th T3CH build) what chips/BIOS combinations were confirmed as working? What is in the image stored on the chip and what comes out in the dump?
-Whoopin'
Posts: 2
Joined: Apr 2007
Reputation:
0
Big_Whoopin
Based on what you wrote, I decided to switch the cromwell flashbios into bank 1 and 2 and the Xecuter 5032 bios into bank 3 and 4. Miracle, now I can launch .xbe from within latest xbmc T3CH.
I have an old xbox v1.0 with X2.3lite
Thanks to all of you
Posts: 35
Joined: Nov 2005
Reputation:
10
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.
-Whoopin'
