Phoenix Loader Source Code

[undead]

Hey Guys (and any Gals present)

First off, GOOD JOB !! well done !!

I'm busy writing a bios bootloader that is loosely based in the Linux XBE bootloader and the Phoenix one.

I have several questions regarding the Phoenix loader..

1. doesnt seem like you are using the "escape" code to turn off memory paging and disabling interrupts.. Are you doing this at all ??

2. is the 2BL completely different from original MS 2bl ?

3. I ported parts of it to a regular VC 7.0 project and it compiles fine, even works from the XDK Launcher. It loads the BIOS i want etc.. but if im not in a dev envirionment (not using xdk shell and debug bios) then it just hangs ??

Are you just creating contigeous memory through the kernel exports or also other memory routines ??

why are you using yout own memcpy and memset.. is the C runtimes not sufficient ??

any answers would be appreciated..
thanks

[TEAM-ASSEMBLY]

[Artifex]

Originally posted by undead
Hey Guys (and any Gals present)

First off, GOOD JOB !! well done !!


Thanks.


I'm busy writing a bios bootloader that is loosely based in the Linux XBE bootloader and the Phoenix one.

I have several questions regarding the Phoenix loader..

1. doesnt seem like you are using the "escape" code to turn off memory paging and disabling interrupts.. Are you doing this at all ??


No need to.
The kernel being loaded handles this. It wipes the page tables and sets up its own interrupt vectors when it's loaded.


2. is the 2BL completely different from original MS 2bl ?


Well, yes and no. The 2bl needs to "know" how to be booted in this fashion, which means that it needs to have a MediaROM entrypoint, and needs to support being loaded shadowed. Also, the kernel needs to support being loaded shadowed as well.


3. I ported parts of it to a regular VC 7.0 project and it compiles fine, even works from the XDK Launcher. It loads the BIOS i want etc.. but if im not in a dev envirionment (not using xdk shell and debug bios) then it just hangs ??


Not going into the fact that the XDK is illegal, and that VC7 is not, in it's default configuration, very suitable for this sort of embedded development.....

Your problem could lie in a few different places, and we'd need some more details to really help you. XDK free gcc works just fine. :-)


Are you just creating contigeous memory through the kernel exports or also other memory routines ??


Kernel exports, as is evident in the code.
I'm not sure how you'd go about calling kernel exports from an XDK app, or if you even can (reasonably). I also don't know if the XDK libraries provide a suitable allocator in it's memory manager library. I don't work with the XDK, really, because it is (as mentioned) illegal.


why are you using yout own memcpy and memset.. is the C runtimes not sufficient ??


C runtimes? What C runtimes? I'm assuming you mean a libc?
There are no C runtimes.
Look at the source, look at the build process. No comfy xdk here, no helpfull "C runtimes" for us. If it's not a kernel export, it doesnt exist at runtime.
Hence we implement them ourselves. :-)


any answers would be appreciated..
thanks

[TEAM-ASSEMBLY]

Hope I've been helpfull. Feel free to post any other questions you may have, or try to catch one of us on irc.

--Artifex

[stealth]

I just wanted to clarify a couple of things.

MS debug bioses are inherently capable of booting from media. They have a special 2bl which has 2 entry points. The first entry point is the normal boot from flash one, which intializes hardware, sets up memory, and then continues to decompress and execute the kernel. The second entry point only sets up memory, and then continues in the same execution path as the first entry point to decompress and execute the kernel.

Now, the kernel that is going to be shadow booted also needs to have some special capabilities to handle it, as Artifex mentioned. But more specifically, kernels that can boot from media first check command line parameters passed to it by the 2BL (or perhaps more accurately the process initiating the shadow boot) to see where it was booted from (HD, CDROM, etc.). If it discovers it is shadow booting, then it also needs to be able to grab its initialized data section from the shadow rom instead of the flash.

All MS debug bioses have this ability. The reason the X2 4977 bfm bios works is that the X2 bios is based on a debug bios afaik, and has the necessary shadow booting capabilities. The bfm release pretty much just wrapped it in a bfm capable 2bl.

If you are curious about the kernel exports used, simply look at the file xboxkrnl.h in our source package. There are all the exports defined for use in the application (there are others that are left over from xbeboot as well). For instance, MmAllocateContiguousMemory to allocate memory, and XcRC4Crypt and XcRC4Key to do the 2bl decryption. XboxEEPROMKey kernel export is grabbed and patched into the 2bl.

Yes, the C runtimes are missing for this app. It would be nice to have an xdk free libc-like set of libraries, but I'm not sure if anyone has implemented that yet. Perhaps openxdk has. Mostly only a couple string manipulations and memory calls are needed, so it's not too bad to just implement in the app. You have to thank xbox-linux for providing all this functionality outside of the xdk. It really is a tremendous starting point.

I hope this clarified things a bit.