Wednesday, October 9, 2013

Scripted boot sequences on OldWorld PowerMacs

Having a decent bootloader on an installed system is a good start, but how do you install it in the first place?

iQUIK relies on having OFW properties or boot arguments to figure out where to look for the configuration file. Having the user pass extra arguments involves knowing those arguments - in our case, the file path and the device path. While the first we know (as a developer), the second depends on the choice of boot media and machine. Of course, we could bake in nasty logic to special case CDs, or scan all partitions on the booted device, or use magic locations in the binary, but none of this is a clean approach.

Ideally we would want to run on a CHRP machine, where we could boot a "CHRP script", which looks something like this:

FreeBSD/powerpc bootloader


boot device:partition,\ppc\kernel;.elf

This would let us verify the target system, and run arbitrary Forth to set up the needed parameters (or even interact with the user). A good example of a complicated CHRP script is the MacOS ROM file on NewWorlds, which is a pretty large blob of Forth followed by an embedded ELF image.

But we're on OldWorld. No bootinfo support. What can we do? We can do pretty much the same, except we have to prefix our Forth with a machine code stub that will call into PROM to interpret the following Forth code. Afterwards, we can pass control to the regular boot loader, which is embedded right after the Forth words. Whereas before the boot partition contained just the iQUIK boot block, now it's a "sandwich" of simply concatenated Forth hand-off stub, the Forth code and the iQUIK boot block. All we have to do is compute the load address correctly, such that the iQUIK boot block falls on its expected linked address.

Thursday, October 3, 2013

iQUIK updates

iQUIK (my fork of QUIK, the OldWorld Linux bootloader) has seen a few enhancements.
  • Better 3400c support. Now that I have a CD drive, I verified that the media bay ATA only needs to be hidden when there's nothing attached to it. CD booting is still at large (but will probably work just fine).
  • PDQ/Wallstreet documentation. This includes patches to get booting via PCMCIA/CF and via internal IDE, as well as kernel options needed. CD booting is still untested (and will likely cause the nvramrc patches needed to grow).
  • Bug fixes around large disk access that was preventing from correctly reading partitions larger than 4GB. There's still a problem with partitions on large disks, so you should probably create a '/boot' partition. I wonder if certain ATA packages on old OF have issues... Needs investigation.
  • !cat to display short files
  • Bug fixes to path handling and compatibility with yaboot.conf used by debian installer.
  • Turn on shallow setprop support for OF 1.0.5 (pending testing to see if it's needed)
The current to-do list:
  • Clean-up command parsing/handling a-la U-Boot
  • Investigate partition access on large disks
  • Automatic nvramrc patching to ease deployment
  • Janitorial:
    • malloc/printf replacements
    • claim() load area and prom_exit() path should close all opened handles, release all claimed memory (end goal is being able to quit and load again)
  • Add !parts to scan and display partition/fs info for devices
  • Rewrite shallow setprop support to work for all props, not just initrd-base/initrd-size
  • BSD kernel loading
  • Partition-less device support
  • FAT support
  • ISO9660 support
  • EXT4 support
  • FCode loading
  • Forth loading
Current test plans:
  • OF 1.0.5
  • CD booting
  • More machines (anyone?), maybe try some different CPU modules on my PDQ
It's actually sort of interesting that there's no guarantee that the same OpenFirmware release (i.e. 2.0.1) will have the same bugs. And I'm not just talking about device support, because that's fairly obvious (different I/O chipsets need different drivers). For example, the 3400c has 'setprop' issues that need to be worked around, but the Wallstreet doesn't. The Wallstreet is obviously newer, but there's no way to draw a line between support without trying it on every model (so might as well always use the work-around).

As usual, everything is at