---------- Original Message -------------
Subject: Re: macppc boot process.
Date: Thu, 26 Aug 2004 22:00:33 +0900
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: port-macppc@netbsd.org

>>
I guess the problem here is currently there is no way to make
a fresh disk bootable on OF3 machines if we use the method
"boot from HFS," and "booting from MS-DOS fs" is the only (easy) way
to make it possible. "FDISK or APM" is not the matter here.
(I don't know if bootxx method works or not on OF3 machines, though)
>>

It seems to me that one of the problems is the coupling of the bootloader to the kernel locations. As I am still getting up to speed on NetBSD's code, I can only state how it's being done in OpenBSD and note that much of what I learned to make their bootloader work with Old World Macs came from NetBSD's bootloader code. As such, in the OpenBSD bootloader code the location for the kernel as recorded in /chosen is stripped and made relative to the bootloader. This is not necessary, if the proper file system code is in the bootloader itself and the partition map is understandable. I've been working on decoupling this and I have a code example at

http://www.dialectronics.com/bootloader/code/of_mfs.c

Although not tested thoroughly, the purpose is to load the bootloader over tftp but have the kernel located somewhere else (possibly locally). If the proper code for reading the Apple Partition Map were implemented in the bootloader, the bootloader could reside in an HFS partition but the kernel reside in a properly formatted FFS partition on the same disk or elsewhere (if OF contains the hfs file system package, i.e., 3.0). In the OpenBSD bootloader, the HFS stategy is basically just a wrapper for OF routines, instead of a true stategy capable of reading HFS partitioned file systems. Some of the decoupling will have to go higher up, in the libsa loadfile.c routines (which is almost identical between NetBSD and OpenBSD, IIRC), so that the calls to the strategy matching will include the full path.

tim
--