-
Notifications
You must be signed in to change notification settings - Fork 4
Build Verification Testing Monitor Wiki
I will try to add more 'detailed' info on parts of the Script and Plans for the Script, for now it is simple.
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!
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.
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.
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!
-
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.txtand Easy-Build will initiate a 'Dirty Build' of the tree. Remove or rename to enable Clean Builds again. -
You will have 'better luck' targeting
XM3when 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.binfile with Easy-Build, copy it to$(BVTDrive)\xboxbins\Release\eeprom.binbefore running BVT Build, it will be detected automatically and configured with XEMU
I will eventually add suggestions for what can be done to adapt BVTMonitor and Easy-Build.
My built kernel doesn't boot
- You could try extract
2bl.binandremainder.binfrom a known working custom Kernel withxbtooland place them in$(XboxTree)\public\idw\biospack\bootfor 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_BVTMONITORand 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.txtand 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 insideBVTMonitor.cmdwith 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