Hi everyone,
I just found this neat little piece of wizardry called Ephemerboot. It lets you boot off of a ram disk on New World Macs. It apparently does not work on a lot of systems, but the coolest things about it are some of the tricks it uses.
(Nearly) every partitionable disk has a patch partition, an obscure and little-used invisible 256 kB partition. Code from this partition is loaded and run at boot. Normally this does boring things like patch ROM disk drivers from the pre-4 GB era and allow machines predating popular CD-ROM drives to boot from them with the "c" key. Actually, that's all that patch partitions have ever done, far as I know. You might have noticed, however, that these functions both deal with letting the machine boot from things it normally wouldn't. That's because the patch partition is run before the boot volume is determined.
Once some physical memory has been cordoned off in Open Firmware, it's tough to access. It's so well-hidden that not even the Nanokernel knows about it — just trying to read those addresses causes a crash (an unmapped memory exception). No public Mac API will bring that memory back.
However, there's a cute little app called PowerMacInfo, written as a kernel monitoring tool by some really cool Apple engineers. It can show you physical memory at any address. (By default, it only shows you memory the kernel knows about, but it can be fooled with MacsBug.)
So I reverse-engineered it. It's the "old-style" 68k VM interface. It centers around opword 0xfe0a (that's an f-trap!). The definitions at the top of EphermerBoot.c should be a good enough explanation. The second parameter to VMUnmap controls whether the page should be remapped upon an unmapped access (true) or if unmapped accesses should cause a propagated fault (false). The parameters are UInt32's because they're page numbers, not addresses.
Both of these tricks could be
very useful for debugging and general messing around with things we shouldn't mess around with...
Topic: Ephemerboot (Read 5987 times)