Dialectronics - the dialect of electronic communications





About Us

Our Mission

Minix

RISCV

PowerPC

Lua

XCOFF Bootloader

Old World Macs

Open Firmware

Words

Journeys

Home Repair

Top Level




Generalized Bootloader for NetBSD and OpenBSD on Apple Hardware

The currently supported version is boot25j.xcf. There are several fixes in this version, including an error that was preventing NetBSD gzip'ed RAMDISKs from being properly recognized. This version also introduces bootloader flags, which preceed the kernel name. The only bootloader flag in this version is the -l, which must be set in order to attempt to enable L2 caches. The default behavior is to not enable L2 caches, and the -l flag overrides this.

A typical command would look like:
boot ultra1:1,\boot25j.xcf -l bsd

This would boot from an MBR partition and attempt to enable the L2 cache (and to examine it if already enabled) before booting a kernel named "bsd."

The pre-release version is boot25k.xcf. This version has some additional CPU identification code. Upcoming is boot25m.xcf, which will have 601 support and a diagnostic bootloader flag. The in-house development bootloader is well ahead of the publically released versions, but there has been very little time to make this "public" quality.

The current version will can boot from PC formatted file systems locally or use tftp (instead of NFS) for ramdisk installers. This version has almost complete decoupling of the bootloader and kernel, as long as Open Firmware can read the bootloader and the kernel is on either an Open Firmware readable disk or an MBR/FFS partition and formatted disk. For example, the following are legitimate boot commands:

boot fd:,\boot25j.xcf enet:,\netbsd.rd
boot ultra1:1,\boot25j.xcf ultra0:9,\netbsd_GENERIC-MD.gz
boot ultra0:9,\boot25j.xcf ultra1:0,\bsd

The first boot command boots the bootloader from a PC formatted floppy disk and a ramdisk NetBSD 1.6.2 installer via the tftp mechanism in Open Firmware. The second boot command boots the bootloader from an MBR partitioned hard drive with a DOS formatted partition while the NetBSD-2.0RC3 installer resides on the first HFS+ formatted partition on a disk with an Apple Partition Map (this only works on Macs with OF that can read HFS). The third boot command boot a bootloader residing on the first HFS+ partition on a disk with an Apple Partition Map while the OpenBSD kernel resides on an FFS formatted partition on an MBR partitioned disk (this last command has a small bug that requires one to specify the root partition, i.e., wd1a).

The above is accomplished by replacing several of the components of the stock OpenBSD boot.mac bootloader, which was in turn derived from NetBSD's ofwboot.xcf. A more formal discussion of the approach is forthcoming, once the final kinks are worked out.

An informal discussion is available here. This is the contents of the post to the OpenBSD ppc mailing list announcing its release and discussing the code. It has been updated to reflect the correct locations for the referenc ed files.

The source available is out of date, as the next planned source code release will be for when the bootloader is standalone, instead of within a specific BSD build environment. Some code is available in the meantime. For NetBSD and OpenBSD, the cread.c and loadfile.c files go in sys/sys/lib/libsa, fix-coff.c and Makefile.boot.mac (as Makefile) go in sys/arch/macppc/stand/boot.mac, and L2Config.c, of_mfs.c, boot.c, and Locore.c go in sys/arch/macppc/stand (note that the code reflects the build in OpenBSD 3.5-release). Comments are contained within the code.

The of_mfs.c file is the core to the change of netbooting in the bootloader. Instead of using NFS for the file system, it uses local memory and loads the file from the network into memory via calls to Open Firmware (hence, "Open Firmware Memory File System"). This approach is very useful for development purposes and quick RAMDISK installations when an NFS server is not available. There are several freeware and shareware tftp server applications available for MacOS and Windows. When doing development work, frequent testing is required, and this can have an effect on the quality of the booting media and the lack of a contiguous file image on local media can cause strange errors unrelated to the most recent change. Therefore, during the development of new kernel code, building and running from a RAMDISK loaded via tftp can help.

Note that the bootloader is linked to 0x24000. This will be above any Open Firmware installed exception handlers and below your kernel. For tftp loading, the bootloader will copy via tftp the ramdisk installer image to 0x1000000 (16M) and then copy it to the linked location. For local disk booting, the bootloader will load the kernel to the linked address. Unless your kernel requires the memory space occupied by Open Firmware, it will not be necessary to alter either load-base or real-base. In the case of OF 1.0.5 and larger than 3M kernels, the recommendation is to link at 0x500xxx instead and use only the last available region in /memory. For a further discussion, please refer to the topics Old World Macs. The bootloader also expects the file, if compressed, to be done so with -9 (--best) compression set. This bootloader will not work with GENERIC kernels using NFS, as it conflicts with the use of the enet node for tftp loading. Additionally, there is a 4M file transfer limit in Open Firmware's tftp implementation, so this bootloader can not netboot an uncompressed RAMDISK image.

The all versions since boot25a.xcf have a local stack, which eliminates one problem that had led to suggesting linking kernels above 0x500xxx. previously the bootloader had relied on Open Firmware to provide the stack for the bootloader. In OF 1.0.5, regardless of where real-base was set, this stack always began at 0x4M (and worked 32k down toward 0x0). This resulted in running over the bootloader's stack when loading kernels into memory at 0x100xxx. With the stack now local to the bootloader, this is no longer a problem and will likely lead to being able to link at 0x100xxx.

Version History

8/21/05 - boot25j.xcf, boot25k.xcf: Introduction of bootloader flags, L2 cache enabling off by default, additional CPU identification

10/19/04 - boot25c.xcf: Continued decoupling of bootloader from kernel, better handling of unknown CPUs

8/28/04 - boot25a.xcf: Initial decoupling of kernel location from bootloader, stack local to bootloader instead of using Open Firmware provided one (thanks to Izumi Tsutsui for pointing out this aspect of the NetBSD ofwboot bootloader). New suffix.

8/14/04 - boot24z.mac: Support for tftp booting of RAMDISK installers.

6/30/04 - boot24t.mac: Dynamic enabling of backside L2 caches for G3 CPUs, cache size measuring for G4 CPUs.

5/1/04 - boot24d.mac: first release, link address at 0x24000, OpenBSD 3.3 based

FAQs

What's up with the naming scheme?

Well, OpenBSD started the boot.mac name (they consolidated on the ELF formatted ofwboot, by the way, and don't support their XCOFF bootloader). In order to track where I was linking the bootloader at (instead of the usual 0x640000), I added "24" to the na me, and then the first testing version had "a" for version tracking purposes. After some changes during testing, the first published version was boot24d.mac. The next published version was boot24t.mac, and the one after that was boot24z.mac. At that point I was out of letters. So while now there is "25" in the name, it doesn't reflect any change in the link address. However, I can start over with "a."