Subject: More loose ends - disksubr.c and fdisk.c
To: None <port-macppc@NetBSD.org>
From: Tim Kelly <hockey@dialectronics.com>
List: port-macppc
Date: 04/11/2005 12:14:51
At http://dialectronics.com/NetBSD/code/disksubr.patch is a patch to fix
the problem where MBR partitions can't be set if there is no NetBSD
disklabel first. The problem here is that when no disklabel is found, a
string message is returned but the calling code assumes any string message
returned is an error. I've used the patch to successfully set NetBSD
disklabels within MBR partitions that can be used by NetBSD on an APM disk,
but there is a problem with the installer blowing away any MBR partitions
and the bootloading process on Old World Macs runs into problems so I
haven't actually booted from it.

At http://www.dialectronics.com/NetBSD/code/fdisk.patch is a patch to allow
writing to the first sector on MBR partitioned disks if the kernel is a
PowerPC based system. It just basically overrides the protection mechanism
for PC systems. Open Firmware can and does read from the MBR partition.
OpenBSD has done it for some time and I've done it on Old World Macs with
the bootloader I've been working on. On OF 1.0.5 systems there is a problem
where the same 2k of the bootloader gets loaded over and over again, so
that while the correct length of data is read into memory, it is a
repeating 2k of data. This only occurs on setups where there is an MBR
partition first, as obviously PC formatted floppies work just fine. There
are some differences between an MBR partition map and a DOS formatted file
system, so while the MBR partition is recognized by OF 1.0.5, something
isn't incrementing the read location. This is not a problem on New World
Macs.

I believe the solution to this is similar to what Dan LaBell was working on
independently, which is a Forth bootscript. I had a chance to play with a
Mac mini and see how far into MacOS 9.2.2 it'd run, without booting OS X
first, and this required modifying the Mac OS ROM file, which contains the
ELF bootloader. The Forth boot script portion of the CHRP file locates the
bootloader within itself, loads it into memory, sets up the initialization
and then runs it. A similar approach could be used that would be a sort of
hybrid bootxx/ofwboot.xcf file, where bootxx is replaced by a Forth script
that locates ofwboot.xcf and loads it into memory. If ofwboot.xcf was
embedded in the file, the Forth bootscript would just have to locate itself
on the disk, read itself into a memory location, locate the start of the
bootloader, move it to load-base, and boot. It'd be one file. I'd do it,
but I haven't figured out how to do a seek in OF without knowing the file
location, and I don't know the routines to walk the file system. Otherwise
I'd have posted this sooner.

This approach would work on both Old World and New World Macs, as long as
both files were on a file system OF could read. I haven't been able to get
concrete evidence that on Old World Macs is possible to boot MacOS and
NetBSD from the same disk, so while preserving the APM partition map may be
useful on New World Macs, I'm not sure it is useful on Old World Macs and
as I recall, the 2.0 release didn't go so well due to problems with bootxx
and ofwboot.xcf not meshing well. With New World Macs, OF can read Apple
Partition Maps, so there's no conflict here.

As an aside, I got as far as do-quiesce on the mini. This is either at the
very end of the bootloader or at the very beginning of the operating
system. Since do-quiesce stops Open Firmware, I'm not able to determine how
much farther it goes, and the video chip may not be supported. The
interrupt controller should be, as it is compatible with Key Largo. It was
worth a shot.

tim