[Release] XBlast OS v0.3Beta

Discussion in 'Xbox (Original console)' started by bennydiamond, Apr 17, 2015.

  1. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    It has taken a very long time but it's finally here!

    Here's v0.31Beta update to XBlast OS:
    https://bitbucket.org/psyko_chewbacca/lpcmod_os/downloads/XBlast_OS_v0.31beta.zip

    BIOS bin file and XBE version are present in this package.
    Please read the "readme.txt" file before using XBlast OS.

    Changelog:
    EDIT: Big thanks to wienerschnitzel who provided the new icons and backdrop!

    For those who are wondering why it took so much time here's why:
    TL;DR : I had to reverse engineer a lot of code from SmartXX OS and gradually test everything I integrated into XBlast OS.

    Longer explanation:
    To avoid having a separate BIOS file for 1.6b Xbox consoles, I initially extracted a part of the initialization sequence(X-codes) from flashBIOS 3.0.3-1 which supposedly was universally compatible across all Xbox revision in a single BIOS file. The problem is that there is a know issue with this code that sometimes caused trouble on 1.6a consoles. Initially, I didn't encounter such issue but it became an increasingly recurrent problem as OS development progressed.

    Since the initialization part of the boot process of the Xbox is rather obscure and obviously not very documented, I had very little choice but to try and mimic the init code of other BIOSes that had 100% boot success on all consoles.

    I first tried to extract X-codes from Evox M8+ and inject them into XBlast OS (Evox M8+ BIOS will boot on all console) and use more conservative memory timing values (because the main difference between 1.6 M8+ and non-1.6 are memory timings. That's why you should never use a non-1.6 version on a 1.6(b) console and vice-versa.). It partly worked but I then had issues with 1.0 consoles. From an OFF state, I would press the power button, the 1.0 Xbox would power ON for half a second, power cycle and finally reboot into XBlast OS. Really weird stuff I deemed unacceptable behavior for XBlast OS! The M8+ approach was scrapped mainly because of this but also because X-Codes in it looked like a real mess. X-Codes section in M8+ is at least twice as big compared to any other BIOS and there are so many unconditionnal goto statements that could have been avoided by having proper code construction... Really poorly done by the Evox BIOS team...

    At the time, I also suspected that there was some sort of x86 assembly init code in M8+ past X-Codes execution that was complementary to it but I did not want to get into this at the time. The issue with 1.0 consoles according to a comment left in cromwell sources is that 1.0 PIC have more strict timeout value to init console than other revisions. If a certain part of the initialization isn't done in a certain amount of time, the PIC will forcefully reset the console. The fact that XBlast OS succesfully boot on such reboot is probably due to the fact that RAM content will be retained across reboot because capacitors on the motherboard will power the RAM for a short period of time even if the console is powered OFF. On the second reboot, the init code is executed much faster because some calculated values from last power ON are already present and thus reduce the init time enough to not trigger the PIC timeout. Ironically, it's kind of like replicating the principle of the Reset Glitch Hack on the Xbox 360!

    I then turned myself to a better suited alternative: SmartXX OS. SmartXX OS is cromwell-based(just like XBlast OS) and the last few OS update BIOS files are universally compatible across all Xbox revisions. To my knowledge, no one ever complained of OS boot issues that could relate to a specific motherboard revision. To do this, I downloaded the latest SmartXX OS update and used the decrypter program found in Eurasia's download section (SmartXX udecode, something like that). This produces a 1MB file that contains a lot of stuff and in this pile of bytes, there's a 256KB section that is essentially the OS BIOS file. From this extracted section, I took the MCPX init table (offset 0x00 to 0x80) and X-Codes section (0x80 to 0x1000) and integrated it in XBlast OS sources. Trying to boot this hybrid abomination, I was presented with the same issue on 1.0 consoles I had with the M8+ X-codes... Darn it, so much frustration.

    I tried to reorder the X-Codes execution to help speed up Connexant encoder init but it wouldn't do any good. I then proceeded to gradually change the x86 ASM code from XBlast OS (offset 0x1000 and up) to get the same thing that was pesent in the decrypted SmartXX binary. Nothing would do it and I had changed all the assembly code up to the point in cromwell where it changes from x86 assembly to C language. I didn't want to reverse x86 ASM into C code but I did notice in IDA pro that the ASM section of what represent the C code section of the 2bl bootloader was much smaller in SmartXX OS than any other recent cromwell BIOSes (Cromwell 2.40, Gentoox loader, flashBIOS and XBlast OS of course). Ultimately, I found out that the moment when the 2bl was replying to the PIC cryto request happened much later than in SmartXX OS!

    To deactivate the timeout counter of the PIC, you have to answer to a "cryptographic" challenge posed by it. Once you supply the PIC the correct "decoded" values, it will disable the timeout countdown and will never try to forcefully reboot the console(until reboot).

    The problem reside in the SHA-1 checksum calculation to check integrity of the 2bl in RAM. It takes too much time to calculate! During the time it will calculate the output checksum, the PIC will timeout and reset the console for 1.0 revision. In regular cromwell BIOSes, this wasn't an issue because X-codes execution took less time to complete and SHA-1 calculation could be completed in time to move on to PIC crypto challenge reply. The X-Codes in SmartXX take much more time to execute but that's a side-effect of having true universal revision compatibility. In fact, cromwell uses the PIC reset feature to forcefully reset the console by deliberately not replying to the PIC crypto challenge in the event of a SHA-1 key mismatch (that would signal corrupted 2bl in memory).

    So to fix this, I reduced the calculation time of the SHA-1 hash by reducing the algorithm complexity (it's only used as a checksum not encryption so we don't need a full blown SHA-1 compliant value here) and moved PIC crypto challenge reply before SHA-1 calculation (2bl will still reboot the console if a SHA-1 mismatch is detected). Problem solved! 100% boot rate on all Xbox revisions. XBlast OS now uses the "same" init code as SmartXX OS to make it universal. While I was at it, I also reduced the size of 2bl in the 256KB image file of XBlast OS to leave more space for OS features; I gained 3.75KB of space which is not as negligible as you might think. In fact, it's a lot if you consider that this space was occupied by a piece of code that(still) only copy stuff from flash to RAM, calculate checksums, unzip a file and jumps to it.

    Before you ask, no it shouldn't be used in hacked BIOSes to make them universal. To make cromwell universal, I have to reduce RAM performance a lot to accomodate every motherboard revision. This would translate in unacceptable performance lost in games and homebrews. Cromwell is "simple" and does not suffer from any noticeable performance drop by doing this. For those who like Gentoox Loader, vanilla Cromwell or any other Cromwell-based BIOSes, you could recompile them using the new code in the "boot_rom" folder of XBlast OS sources and it would generate a truly universal cromwell BIOS.

    So there you have it. That's why I postponed release of v0.3Beta for so long. This whole process took a very long time in itself. I also have my professionnal and personnal life(I have to work to live and live to work!), my main dev rig died on me in March and I had some pretty memorable birthday parties the last few days :p
     
    Last edited: Aug 9, 2016
    dark ricardo, CodeAsm and Getta Robo like this.
  2. fxmech

    fxmech Active Member

    Joined:
    Aug 6, 2014
    Messages:
    40
    Likes Received:
    4
    Thanks! Great job on this release, I appreciate the attention to detail and the insistence on taking "the one best way" to implement functionality.

    [Happy birthday!]
     
  3. keropi

    keropi Familiar Face

    Joined:
    Feb 2, 2011
    Messages:
    1,056
    Likes Received:
    60
    very nice!
    are there any screenshots of this in action?
     
  4. Looney Bin Jim

    Looney Bin Jim Spirited Member

    Joined:
    May 1, 2014
    Messages:
    119
    Likes Received:
    10
    Awesome! Thanks dude! Still can't wait for the arrival of your chip!
     
  5. ToxicMedz

    ToxicMedz Enthusiastic Member

    Joined:
    Jul 6, 2014
    Messages:
    509
    Likes Received:
    106
    Benny you are amazing, the more you post about your changes and features the more excited I get for your chip. It is so amazingly capable! Truely cannot wait to get my hands on a couple!
     
  6. mrgreedy98

    mrgreedy98 Active Member

    Joined:
    Mar 14, 2015
    Messages:
    33
    Likes Received:
    5
    v3.0 boots from a stock aladin advance chip also.
     
  7. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    Terribly sorry... At least you can still reflash the modchip by hot swaping it. That is of course if you have another modchip laying around.

    If you don't or are having issues with it, PM me and I'll help you the best I can!
     
  8. mrgreedy98

    mrgreedy98 Active Member

    Joined:
    Mar 14, 2015
    Messages:
    33
    Likes Received:
    5
    lol i was meaning i flashed version 0.3 to an aladin advance chip and it worked perfectly :)

    this is professor_jonny from the xbmc forums the sadly I could not use my name on this forum as under scores are not allowed in user names :)
     
  9. weinerschnitzel

    weinerschnitzel Spirited Member

    Joined:
    Sep 23, 2012
    Messages:
    153
    Likes Received:
    13
    Hi Benny! I will definitely test this in the next couple days. Thank you! Greets to professor_jonny, too.
     
  10. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    I had a feeling you were indeed professor_jonny lol! Now I know for sure.
    Good to read that the modchip isn't dead!

    In fact, I found and read the internal tech manual of the Xbox and found out exactly why v0.3Beta bricked the TSOP.

    The very first thing the MCPX does to determine from where it's going to load the boot ROM from is check the very first bit in TSOP flash. If it's set to 1, MCPX is instructed to boot from TSOP. If it's set to 0/ground, it will attempt to load from LPC bus. v0.3Beta took a lot of stuff from SmartXX OS which has this very bit set to 0. I Originally thought this was some sort of initialization constant value for the MCPX so I just left it there. So if any BIOS image flashed on the TSOP doesn't have it's very first bit set to 1, MCPX will think there is no Xbox BIOS on it and jump straight LPC bus to try and load a valid BIOS...
    (That's the confirmed reason why strapping d0 to ground will enable LPC modchips usage)

    Have fun with it and thanks again for the classy backdrop and icons!
     
  11. mrgreedy98

    mrgreedy98 Active Member

    Joined:
    Mar 14, 2015
    Messages:
    33
    Likes Received:
    5
    Yip it confused the hell out of me why it was booting to lcp with d0 disconnected

    is this how the tsop d6 bios works it sets this value during boot up then switches it back after reading a small part of the bios initilising the tsop we wr lines in the process?

    if you can manipulate this bit in memory during bootup it may save the need for the special tsop d6 and hardware soluton, maybe it will set up the we,wr lines to the tsop.

    it would be nice for a way to flash a tsop booting from a chip with no special wires or relying on the data being semi intact and compatable tsop image.

    Thanks weinerschnitzel, I have been testing the hell out of the xblast and its OS benny is probally getting sick of me posting bugs and annoying him with PM's but Im happy to help out with the cause.
     
    Last edited: Apr 21, 2015
  12. Rocky5

    Rocky5 Site Supporter 2015

    Joined:
    Jan 17, 2014
    Messages:
    524
    Likes Received:
    95
    Will support for 3rd party controllers be added?
     
  13. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    There are some controllers already supported. I need to investigate how come not all third party are properly supported.

    So yes, it's something I plan on fixing for next release. I have 2 models of third party not currently supported. Even if their USB VendorID and ProductID are in the list of supported device they don't register as compatible... The weird thing is that the USB core used in Cromwell is supposed to determine if a USB device is compatible solely based on the VendorID and ProductID and nothing else! There something else in the USB core that flags those devices as incompatible.

    If I have to, there's a chance I will just change this whole thing to register every HID classified devices as valid Xbox controllers! Problem solved forever on my side; it will be up to the user to make sure he plugs proper hardware.
    The downside of this will be that keyboards and DVD-IR dongles will also be identified as Xbox controllers and will not work properly. They don't work at all right now because I disabled the support a long time ago. I don't really recall why so I will re-activate them if I fix the third party controller issue the proper way!

    Not at all, please continue. Your help and support is extremely appreciated! I wish more people would report bugs on BitBucket but I guess it'll happen when people have the modchip in their hands!
     
    Last edited: Apr 30, 2015
  14. hennber

    hennber Newly Registered

    Joined:
    Jan 16, 2016
    Messages:
    4
    Likes Received:
    1
    Im runnning an xecuter 2, would this work on it?
     
  15. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    Yes it will work as a standalone, Cromwell-based BIOS. It will not be able to manage and control banks as if it was running on a XBlast-compatible modchip. It's still a very useful tool to modify/repair various parts of your Xbox console.
     
  16. weinerschnitzel

    weinerschnitzel Spirited Member

    Joined:
    Sep 23, 2012
    Messages:
    153
    Likes Received:
    13
    Hi Benny!
    I flashed a new bios onto Bank0 on the XBlast via http, and XBlast OS would boot Bank0 on the TSOP. The flash works properly, maybe XBlast OS is confusing Bank0 on the two? I did this a couple times, so it shouldn't be too difficult to reproduce.
    Thanks!
     
    Last edited: Apr 7, 2016
  17. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    Ok, to get this straight you flash your 512KB bank with a new BIOS via HTTP and right after, without rebooting, if you select XBlast bank0 to boot, the Xbox will boot from TSOP bank0? Or is it the opposite(boot XBlast bank0 when selecting TSOP bank0)?

    I'll get on it in the coming days. Thanks for the bug.
     
  18. weinerschnitzel

    weinerschnitzel Spirited Member

    Joined:
    Sep 23, 2012
    Messages:
    153
    Likes Received:
    13
    I think that was the case when selecting Bank0 after I flashed. Ill do some more testing on it.

    When you finish flashing the 512KB bank via netflash the console will reboot to Bank0 on the TSOP. I think the expected behavior is to reboot to the 512KB bank. After rebooting everything works as it should.
     
  19. obcd

    obcd Spirited Member

    Joined:
    Dec 14, 2009
    Messages:
    125
    Likes Received:
    37
    I observe a strange behavour when I install Xblast_OS in bank 0 of my Tsop (1MB)
    The xbox is a type 1.1 with a sharp Tsop flash.
    I assumed, as it's a 256KB bios, that flashing it in bank 0 only should be enough.
    MCPX secret code executes the xcodes from bank 0 if I remember correctly and the code xblast_os was based on was altered so that it should copy it's 2bl and kernel from bank 0 as well. Nevertheless, when I only flash it to bank 0 (using raincoat on linux) The xbox frags afterwards. A modified standard cromwell bios shows the same behavour. If I use my xchanger modchip and install the biosses on that, they run correctly. If I create a 1MB bios with xblast_os in bank 0 and other biosses in the 3 remaining banks, xqemu can boot from there as well. Only on Tsop, it refuses to boot.
    Anyone has an idea what might go wrong? Please, don't tell me to flash the whole 1MB. If that fails, I have no more options to recover. Now I can still connect the Tsop A19 or A18 to VCC so that it boots from another bank. I disconnected those from the MCPX to prevent that from heating up. Due to it's adress outputs being shorted (to VCC or GND) It's a safe implementation of the TSOP split trick (and a pain to solder)
     
    Last edited: Jun 23, 2016
  20. bennydiamond

    bennydiamond Gutsy Member

    Joined:
    Aug 24, 2011
    Messages:
    476
    Likes Received:
    180
    On boot, the Xbox makes a 16MB mirrored copy of the ROM in RAM. During the boot process, the Xbox reads from both the top and bottom of that memory space. If you flash the first 256KB part of your TSOP, It reads part of the XBLast OS image and part of whatever is in the 4th part of your TSOP. Since they don't match, bad things can occur. Just as an example, the XCodes and 2BL might be read from the top and the Kernel image from the bottom(Maybe it's the other way around but you get the idea).

    Effectively, your console might be trying to unpack a kernel image that is not compress and/or encrypted using the same parameters. On top of that the start of the 2bl in XBlast OS is not at the same offset as standard BIOSes (or even other cromwell based BIOSes for that matter). It's almost certain that the Xcodes of the top image don't even point to the right area to unpack the 2bl.

    So, either you flash the entire 1MB with XBlast OS or you split your TSOP 4 way to mirror 64 times in the 16MB space the 1st 256KB part of your TSOP.
     
    dark ricardo and CodeAsm like this.

Share This Page