Projects

Well, I set this blog up almost a year ago and now I have nothing to show for it. I’ve been pretty blocked when trying to get myself excited enough to work on a personal project.

Xbox

Recently I bought an HDMI to USB capture card, and the first thing I used it on was my old Xbox 360 project.

I took a screencap of the boot process when XeLL turns on the Xenos (the GPU) before initializing the framebuffer. Pictured there is what the 360’s RAM looks like after the system is powered on. The RAM is (mostly) initialized in blocks with 0x55 and 0xAA, a bit pattern where the bits mirror each other (0b0101 and 0b1010 respectively).

The blocks appear to be rectangles in this image because the Xenos displays memory with a tiling pattern. Imagine a mosaic like your kitchen tiles, where each tile combined makes the full picture. You can also look at the wildly crazy math yourself.

Anyways, I thought it would be neat to rewrite the bootloader using Rust. I’m in love with Rust mostly because of its community and toolchain support.

Want to pull in a library to use in your bootloader? No problem - just add it to your Cargo configuration file, and the toolchain will take care of downloading and linking to it. Rust even has a special “no_std” mode, which disables the standard library so that it won’t require runtime support. You can find plenty of packages that conform to this mode, and you can simply include them in your bootloader.

But for the roadblocks - I’m just hitting points where I bang my head against undocumented things in the existing XeLL bootloader. “Why did they twiddle the bits in this particular register this particular way?” is a common question I have.

How do they initialize the Xenon PowerPC processor? What bits are they touching to increase the processor’s frequency?

A few of these questions have been answered by the PS3. IBM released the documentation for the Cell Broadband Engine, and the PPE element is almost identical to the Xenon processor. The register documentation in particular is very useful. Unfortunately, most of these questions are likely going to go unanswered unless IBM and Microsoft release the datasheets for their chips. XeLL got their answers by reverse-engineering the firmware, which is why they use a lot of magic numbers in their code.

Bootloader

As for the bootloader, I’ve been thinking of doing something like Chocolate Milk. It’s a resilient bootloader, so if you run code that crashes the machine, it will simply fall back to a TFTP network loop and fetch more code off of the network.

This makes it incredibly easy to prototype code. Rebooting the system will take a few hundred milliseconds, and if you screw up, it will send you a crash dump and reboot automatically. Certainly a lot easier than the current setup I have with my Xbox.

Anyways

At some point I’ll have to get organized enough to focus on a single thing.

With the pandemic, a lot of things have been put into flux. I won’t be returning to the office for the rest of the year, and a lot of places to hang out have shut down (or are unsafe to visit). It’s been an interesting year. Maybe I’ll write about it.