Skip to content

Build Verification Testing Monitor Wiki

Empyreal96 edited this page Feb 5, 2021 · 2 revisions

Easy-Build Build Verification Testing Monitor Wiki

Preface

I will try to add more 'detailed' info on parts of the Script and Plans for the Script, for now it is simple.

NOTES ON TESTING:

  • For now, its very unlikely that the BIOS will boot on the Standard XEMU Alone.
  • A custom fork will be needed, one that supports BIOS 'Visor' hacked builds.. look at this PR I think its this one anyway
  • If you change the 2bl.img and remainder.img from a bios of your choice, not all of them will work.. (Complex Retail)
  • MCPX 1.1 is recommended so there may be issues, don't quote me on this one!

What Exactly is this utility?

This script's sole purpose is to provide a 'Bridge' between the Build VM running Easy-Build, and the excellent Xbox Emulator XEMU running outside the VM on the host machine. This allows source built files to be tested almost immediately!

Is it a 'true' BVT machine?

Not exactly, but the main concept is almost the same, just 'Modernized':

(Citation needed, this is just what I have picked up from reading) From what I am aware, Xbox BVT Machines were both, actual PCs with Hardware similar to Xbox Hardware (Much like the Alpha Dev Kits) that contained one OS for maintaining drives and other Xbox Source development related tasks, as well as an XBOX OS partition that it could boot into, and Xbox Dev Kits were used to allow a 'closer to retail' test with full debugging support.

But their purpose was to just test the builds 'hot off the press', to allow developers to know the result as soon as possible with debugging utilities and tools that talk with the Xbox OS.

BVTMonitor aims to stick to the principle of the BVT Machines, but allow modern day hardware to run tests instantly.

How does this achieve what it's supposed to do?

With the magical use of Virtual Machines, localhost Network Sharing of a Drive, batch script and XEMU!

The Build VM

It's just a VM, I strongly suggest using Hyper-V as that is all that I have tested with, that said it should be same principle for other VM Software.

  • Starting with the VM, its no different from the usual Build VM (Mine is Windows 10 x86, 4CPU, 4GB Ram running in Hyper-V), just requires network drive it can map to.

  • Make sure it's running Easy-Build with BVT support. (Added as of 2nd January 2021)

Network Share

The network share is essentially the BVT's main hard drive, which would have held the Windows OS and Xbox files for transfer to the Partition or Console at the time.. In our scenario, this is still the main hard drive in terms of it sticks to the xboxbins folder for storing built files that have just been transferred. The "Xbox OS" partition is XEMU emulator. The added bonus is the process will be hours quicker than 'back in the day' and easier for many people.

  • I suggest using a .VHDX file mounted, this allows easy organisation and backups for your BVT environment.
  • Make sure Permissions for the share are Read, Write and Execute for All Users.
  • For me, my share was located at \\tsclient\E, take note of it.

Batch Scripts

This uses Batch Script and one .vbs file used to replace a line of text in a file.

BVTMonitor.cmd has many steps where it sits and waits for different events in the Build VM, I chose to use a set directory $(BVTDrive)\xboxbins\NEEDED_BY_BVTMONITOR which is used to store very basic text files. These files are created from both BVTMonitor.cmd and easybuild.cmd, and are named after specific stages.

For Example:

  • KernelFound.txt - Kernel Check Successful!
  • FinalBuildPrep.txt - PostBuild Finished
  • WaitingOnHost.txt - Waiting on HOST BVT Machine

These are 'detected' by a series of if exist loops that check for specific file names like above.

For Example the initial 'Connection Test' and 'Wait For Build':

:BVTConnectionTest
echo.
echo Waiting for Connection.
if exist "%_BVTMonSanityChecks%\BVTConnected.txt" echo Build Machine Found && goto WaitForBuild
goto BVTConnectionTest

:WaitForBuild
echo.
echo Waiting for Build Start.
if exist "%_BVTMonSanityChecks%\BuildStarted.txt" echo Build has started && goto WaitForPostbuild
goto WaitForBuild

// %_BVTMonSanityChecks% = $(BVTDrive)\xboxbins\NEEDED_BY_BVTMONITOR

Simply looks for the .txt files and jumps to the next section when found.. I think its simple and effective!

With configuring XEMU to use built files, we modify 3 (4 if EEPROM is built) lines of %APPDATA%\xemu\xemu\xemu.ini by using for combined with findstr to search xemu.ini for specific Values, then we save that value to an Environment Variable for later, because we know the new value desired, we set the new path to another Variable.

Now we use $(BVTDrive)\tools\replace.vbs to replace what we want in xemu.ini.

REM                              xboxbios.bin
REM Create a backup, this will be to back up old settings initially, then replaced during each load. It act as an 'autosave' of last sessions settings.
if exist "%APPDATA%\xemu\xemu\xemu.ini" copy %APPDATA%\xemu\xemu\xemu.ini %APPDATA%\xemu\xemu\xemu.ini.bak

REM Create a one-time backup to the root of the BVT drive, this will help revert if any issues occur
if NOT Exist "%_BVTDrive%\xemu.ini.bak" copy "%APPDATA%\xemu\xemu\xemu.ini.bak" "%_BVTDrive%\xemu.ini.bak"

REM Here is our section to find the desired line of text, we use the prefix each value has
for /f "tokens=*" %%i in ('findstr flash_path* "%APPDATA%\xemu\xemu\xemu.ini"') do if "%%i"=="%%i" set "_XEMUOLDFlashPath=%%i"
echo Old entry: %_XEMUOLDFlashPath%
set "_XEMUNEWFlashPath=flash_path = %_BVTBldrFiles%\xboxbios.bin"
rem Pause
echo New Entry: %_XEMUNEWFlashPath%
REM This replaces the old line with new
%_BVTToolPath%\replace.vbs %APPDATA%\xemu\xemu\xemu.ini "%_XEMUOLDFlashPath%" "%_XEMUNEWFlashPath%" /I

BVTMonitor handles the copying of files from xboxbins and subfolders, same for Bldr_files. These are just simple copy commands with some if statements to detect files already there.

XEMU

I need to add some notes here about usage of XEMU with our built kernels. Currently the 'default' build that lives here cannot boot our source built kernels, this is down to the 'Visor' edits made by Complex to modify and skip over parts of the BIOS Boot.

It does however boot on some forks of XEMU, specifically ones that have modifications for better MCPX 1.1 support and the visor edits. So you will need to experiment with builds first unfortunately.

What did boot?

When you find a build of XEMU that suits BVTMonitor's Requirements, make sure to choose a supported 2bl.img and remainder.img from an already packed BIOS (I use iND Bios 5001), and place them into the Build Machine at xbox\public\idw\biospack\boot.

Currently serial debugging is an 'open' issue on the XEMU Github on windows, I can't elaborate but you will find the info looking through their page

Any feedback is welcome!

Tips and Tricks:

Helpful Tips

  • The Network Share will always be Mapped to X:

  • If you would like to run a BVT Build but NOT do a Clean Build, create an empty file in $(XboxTree)\public\tools\BVTNoCleanBuild.txt and Easy-Build will initiate a 'Dirty Build' of the tree. Remove or rename to enable Clean Builds again.

  • You will have 'better luck' targeting XM3 when loading Easy-Build as that is "Retail"

  • If you save your Network Address for future sessions, it will be saved in a plain text file: $(XboxTree)\public\tools\SavedBVTAddress.txt

  • If you build an eeprom.bin file with Easy-Build, copy it to $(BVTDrive)\xboxbins\Release\eeprom.bin before running BVT Build, it will be detected automatically and configured with XEMU

Modifying the BVT Build Process

Coming soon

I will eventually add suggestions for what can be done to adapt BVTMonitor and Easy-Build.

FAQ

My built kernel doesn't boot

  • You could try extract 2bl.bin and remainder.bin from a known working custom Kernel with xbtool and place them in $(XboxTree)\public\idw\biospack\boot for next build. Retail based ones won't be compatible with xbtool.. If that holds no luck, try testing a different fork of XEMU. I am looking at different Bioses that load with XEMU when I can.

**BVTMonitor randomly closes\One or both scripts freeze waiting for xxxxx **

  • Take a look in $(BVTDrive)\xboxbins\NEEDED_BY_BVTMONITOR and look at the most recent .txt file name, this will give a clue to where it crashed. Open a new issue quoting the name of the.txt and I will be able to look at where crashed. If you feel up to it, the file name will take you directly to where the problem if you search for it inside BVTMonitor.cmd with a text editor (If the problem is related to BVTMonitor.cmd).

Why can't it do X feature?

  • I am most likely looking into it, I have plans to slowly adapt the scripts, but I want to make sure things don't break. If you have a suggestion please do let me know in the Issues section!

More soon