There are eight factors to identify on Old World Macs when loading an operating system: 1) the real-base, which is where Open Firmware loads itself 2) the load-base, which is where client programs (i.e., bootloader) are loaded to 3) the link address of the bootloader, which is where the bootloader is copied to and executed from 4) the stack address for the bootloader 5) the link address of the kernel, which is where the bootloader loads the kernel to 6) the address where Open Firmware loads its exception vectors for a client program 7) quirks in addressing 8) pre-OF 3.0 versions can read MS-DOS and iso file systems, and can netboot over enet using tftp. It can not read HFS or FFS file systems. Point 1: when an Old World Mac is left with the default real-base setting of -1 (0xFFFFFFFF), Open Firmware (OF) will choose 0x0400000 (4M) on OF 1.0.5. This can be determined by examining dev /memory .properties to see that the region 4M to 5M is claimed upon entering the OF prompt and before loading any programs. Any loaded client that attempts to write into the area will cause OF to give either a 0x0300 or 0x0400 exception (DSI and ISI, respectively). If a kernel is linked to 0x0100114 and is greater in size than 0x0400000 - 0x0100114, an exception will result when the bootloader tries to write it to memory. The current philosophy in many Unix-like operating systems running on OW Macs is to move real-base to something high like 0x0f00000 or higher. This does work but masks a different problem that is discussed in point 4, and also ends up eventually overwriting OF once control has been passed to the kernel, which is unnecessary and possibly detrimental. Point 2: the load-base after running any MacOS updater is usually 0x0600000 (6M), and the default is 0x04000 (16K). The load-base area is not "claimed" during the process of loading the bootloader and can be written over once control has been given to the client/bootloader program. When OF is given the load or boot command, it copies the client program to the load-base address. In the case of boot, OF will call init-program in order to save the registers in case of exceptions, and then calls go. Point 3: OF will examine the XCOFF header of the client program and move a copy of the client program into memory at its linked address. This region is claimed by OF. Although typically OF operates in virtual mode, due to a badly done implementation of it in pre-New World Macs, this address is almost always identical for real and virtual addressing. This is important to note because any attempt to write into the claimed area for the client program will result in an exception, even if the address is virtual. A RAMDISK that is linked at 0x0100114 that is greater than 0x06c0000 - 0x0100114 will cause an exception even with a real-base of 0x0f00000 or greater. Recently NetBSD moved the linked address for the bootloader to 0x0e00000. While this has helped, eventually the bootloader gets overwritten once control is passed to the kernel, which as mentioned above is possibly undesirable. Point 4: The IEEE 1275-1994 (Open Firmware) binding for PowerPC specifies that the stack allocation will be passed to the client program in r1 and must be at least 32k in size with room for linking. On my OF 1.0.5 7600, this address has consistently been 0x0400000 (and working back to 0x00000000), regardless of where real-base is. This appears to be a flaw in Apple's OF implementation by assuming that OF will be loading at 0x0400000 and attaching the stack to that address. While this area is not claimed by OF and so writing to it will not cause an exception, writing over the bootloader's stack while loading the kernel into memory is generally not a good idea. Point 5: In many Unix-like OSes, the general choice for linking the kernel has been in the 0x0100xxx range. However, it is my opinion that many of the choices revolved around a hit-or-miss approach and failed to take into consideration the four points above. If it worked, the above settings were left alone, if it didn't, other things were tried until something did work. All of the choices I have seen eventually write over the bootloader and OF. This makes a clean exit from the kernel impossible. Point 6: When OF loads a client program, it is responsible for handling CPU exceptions. It does this by installing exception vectors at physical address 0x00000000. DSI, ISI and program exception vectors can be found at 0x00000300, 0x00000400, and 0x00000700, respectively. This space is claimed and is 0x001800 in size and installed after the client program has been moved from load-base into its linked address (which is why a load-base of 0x4000 will not cause an exception). These exception vectors appear to link back into OF. Linking bootloaders or kernels to 0x00000000 will cause problems. The general "black magic" explanation about why the kernel is linked at 1M or higher has been the kernel uses memory below its linked address. This appears unlikely and it is in fact that OF uses memory lower than 1M. Point 7: real-base must always be either -1 or higher than load-base. Reseting this requires pressing the CUDA button on the motherboard. OF does not appear to like large offsets in files. While it is not technically necessary to link at some offset from 1M (and NetBSD does not), due to the size of the OpenBSD kernel using offset 0x0114 creates a very small offset while using no offset from the link creates a huge (0x0800) offset which either OF or the bootloader ends up choking on. Point 8: this requires the bootloader and kernel to reside on a PC formatted floppy, or CD, or the bootloader location must be indentified in the partition 0 area. The current RAMDISK kernel will not compress to a size that will fit on a floppy. Many of the drivers are unecessary for OW Macs and in general the only necessary options are SCSI, Ethernet, ADB, and video. Removing the rest can result in a RAMDISK kernel of 770K or so. The consideration of all of these factors led me to make the following choices for OF settings: real-base 200000 load-base 60000 the following choice for bootloader linking: RELOC=0x24000 and the following choice for kernel linking: RELOC=0x400114 With the real-base at 0x0200000, it will claim 2M to 3M. This is well above the bootloader and load-base addresses, and well below the bootloader stack and kernel linking addresses. The linked address of the bootloader is above the exception vectors and low enough that it will not run into itself at the load-base. A load-base above 60000 but less than 2M - (size of bootloader) will work. The kernel linking leaves both the bootloader and OF in memory and intact. In fact, if the kernel is linked to 0x0500114, neither the load-base nor the real-base need to be altered. I chose to move real-base in order to gain an additional 1M of memory. For distribution I recommend using 0x0500114 in order to reduce as much user interaction with OF as possible. By not requiring load-base and real-base to be moved, the instructions for New World and Old World will be identical (and the kernels may be as well). Moving either setting in a New World Mac will result in a corruption of the NVRAM, which sometimes can be fixed by holding down the indented button next to the programmer's switch past the time in which a loud tone is first emitted and then stopped. For the kernel I have posted the settings need to be changed. I have reasons for this I will explain shortly. Additionally, Apple has an obsolete but available utility that can boot between operating systems with no interaction with OF. The directions for using this will be at the end of this email. I believe that leaving the bootloader and OF intact in memory offers a possible way to interact with the Mac hardware nicely. I don't feel that approaches that overwrite existing functionality that is later duplicated are necessary, especially when it only costs 4 or 5M of RAM to do it. This also offers an opportunity for the bootloader to clean up properly, including setting the Mac to boot back into the Apple OS without requiring user interaction with OF. Much more professional. The above choices coupled with some minor checks have gotten OpenBSD out of the bootloader and into the kernel on my 7600 with a G3 CPU via a ZIF Carrier card (and have done so with a G4 CPU in the socket). This kernel has also run on my AGP G4, to a point. The kernel I have posted is OpenBSD 3.3, by the way, as the 3.4 installer kernel panics on my AGP G4, so I only installed 3.3 and worked with that source code. Additionally, I suspect that there are some more problems lurking in the kernel on OW Macs and I wanted to preceed some recent changes. The kernel and bootloader are at http://www.dialectronics.com/boot024.mac http://www.dialectronics.com/bsd4M.gz Normally one would show the copyright notice, but I haven't been able to get that far. Instead, I'll post the printout and registers from OF: 0 > setenv real-base 200000 ok 0 > setenv load-base 60000 ok 0 > reset-all Open Firmware, 1.0.5 To continue booting the MacOS type: BYE To continue booting from the default boot device type: BOOT ok 0 > boot fd:1,\boot024.mac bsd.gz loading XCOFF tsize=CFE0 dsize=1484 bsize=638 entry=24000 SECTIONS: ..text 00024000 00024000 0000CFE0 000000E0 ..data 00031000 00031000 00001484 0000D0C0 ..bss 00032488 00032488 00000638 00000000 loading .text, done.. loading .data, done.. clearing .bss, done.. >> OpenBSD/macppc Boot no active packageKernel file opened... Header read... Executing ELF file... Reading segment 0...3625976+240620 Zero out bss... BSS maxp... End of segment 0 pass... FREE phdr... ELF and Section Headers... Frobbing...Returned from elf_exec... =0x3867128 chaining...DEFAULT CATCH!, code=FFF00300 ok 0 > ok 0 > ok 0 > .registers Client's Fix Pt Regs: 00 00400124 003FFC60 00000000 00560000 6E20256C 640A0000 696F7320 003FFC7C 08 BDE97420 6F727420 77726974 65212028 2564203C 20256429 00000000 61727077 10 686F6861 733A206F 76657266 6C6F7765 64206172 705F6C69 7374210A 00000000 18 00400000 206E6F20 003FFC18 003FFCA8 00030000 003FFEA8 00030000 00000000 Special Regs: %IV: 00000300 %SRR0: 004F0550 %SRR1: 00003070 %CR: 30000009 %LR: 00400124 %CTR: 0002BF84 %XER: C000BE6F %DAR: 6F72CF20 %DSISR: 40000000 %SDR1: 002E0000 ok 0 > %SRR0 ok 1 > 10 ok 2 > dump 004F0550: 80 69 5B 00 3F E0 4E 77 48 00 29 C1 3C 80 00 55 ok 0 > dev /memory .properties name memory device_type memory reg 00000000 0A000000 available 00018000 0000C000 00033000 001CD000 00300000 00100114 00 7B00F8 0984FF08 Several aspects are different than the standard boot.mac. One is that I've added some milestone feedback to determine where the problems are arising. The readouts prior to "chaining..." are in loadfile.c from src/sys/lib/libsa/loadfile.c. The "chaining..." is immediately preceeding the OF_chain call in src/sys/arch/macppc/stand/boot.c. The %LR is the saved value for the PowerPC Link Register. That value corresponds to the address after the bl to ofw_init in src/sys/arch/macppc/macppc/locore.S in the kernel. The %SRR0 is the saved value of the Program Counter register and corresponds to several instructions past ofw_init in src/sys/arch/macppc/macppc/ofwreal.S. R1 shows the stack address for this routine, with the base stack address in r18. The dev /memory .properties shows an additional claimed area over the default boot.mac as I added a call to OF_claim before reading the decompressed kernel into memory. The size is pmemsz and since the kernel was compiled as a monolithic program (single segment), this should make sure the bootloader won't run over something claimed. Additionally, OF_claim, which was written years ago in the NetBSD port, does not properly inspect the result from OF. The returned virtual address is not always the one requested, and simply returning the requested value instead of the result will discard failed claims. The call into OF will return -1 only if the call fails, not if the claim fails. The bootloader posted above has the corrected code, and if the real-base is left unchanged with the above kernel, the claim will fail as there is not enough room to load the kernel before hitting the OF claimed area. At this point I have hit an obstacle I do not know how to overcome. The memory address 0x004f0550 does not contain the correct byte code. Here is the byte code around the %SRR0 above: 004F052C: 83C10038 004F0530: 83E1003C 004F0534: 3F020040 004F0538: 7C0802A6 004F053C: 93C100D0 004F0540: 9BE10218 004F0544: 9300142C 004F0548: 90820034 004F054C: 3D094E77 004F0550: 80695B00 004F0554: 3FE04E77 004F0558: 480029C1 This is what it should be: 004F052C: 83E1003C 004F0530: 38210040 004F0534: 4E800020 004F0538: 9421FFD0 004F053C: 7C0802A6 004F0544: 93E1002C 004F0548: 90010034 004F054C: 3D200077 004F0550: 80695B00 004F0554: 3FE00077 004F0558: 480029C1 Basically, the compressed kernel (gzip -c -9 bsd > bsd.gz) appears to have been decompressed improperly. Notice that the values do not correspond identically 100%, although much of it does. Additionally, and more telling, the location where the above byte code should be is completely wrong. It's actually 4074 bytes later than where it occurs in the raw, decompressed kernel file: 8069b000 appears at 0x004ef2cc only, and is in the keyboard discovery area. The address for init_ofw that is branched to is actually in the preceeding method, but because of the trashed byte code no blr is seen and the code continues to execute until it attempts to access the bad address in r9. In order to determine that I do not have a media failure (floppy disk), I copied the file from the floppy to a MacOS 9 computer and decompressed it using Stuffit Expander. The byte code in the raw file matched the exact byte code as when in OpenBSD and using objdump -d. This should be about as independent a decompression as I can get. I then took the same compressed kernel and put it on my AGP G4. It got well past the Copyright notice and panicked on mounting the rd file system. This is because I do not fully understand some aspects of rdsetroot and crunchgen and the file system is correctly listed as empty. However, for the moment that's not the problem. The problem is that for some reason that I am unable to determine, the bootloader decompresses the kernel differently on an OW Mac than on a NW Mac. I have tried to identify where this occurs. One aspect of src/sys/lib/libsa/cread.c I have noticed is that the read function does not check for output overrun in accordance with src/sys/lib/libz/zlib.h. The read function only reads until the output buffer is full but does not check to see if the stream still has data to be outputted (avail_out == 0 and s->z_err == Z_OK may indicate more data since according to zlib.h the stream should return Z_STREAM_END). I tried to put in a check by calling inflate and passing it a dummy buffer, but because the kernel header file is read in pieces and read loads 4K of bytes from the compressed file at a time, the stream will have more data than just the header which causes this check to fail. I am not sure of a way to check when the entire segment is being decompressed that there is no more data than is expected, but I suspect that there is because the above indicates almost 4k worth of bytes have been inserted into memory prior to 0x004ef2cc. Being able to check output overrun would confirm that there is a decoding problem. The only additional change that I can recall that I've made was to add "/chaos/control" to the video discovery path. This is because the alias "screen" does not exist in OW OF. The alias "kbd" exists for both OW and NW. None of the code I changed pertained to zlib. One of the reasons I am not posting the source code I've done is because the settings above should be enough for someone to independently get at least as far as I have. I will make all source code available once I've made sure I've got it working. If someone does get past where I have, or can not get as far as I have, please send me the results of the following OF commands (do not copy anything in between [ ] ): ..registers [ (shows the registers) ] %SRR0 20 - dis [ (subtracts 8 instructions from the PC and disassembles) ] %LR 10 - dis [ (subtracts 4 instructions from the LR and disassembles) ] dev /memory .properties [ (shows the claimed memory areas) ] I have not relinked the kernel to 0x00500114 because I've got notes and stuff with it at 0x00400114, which I know will simply translate, and I also wanted to show how real-base and load-base work as there is a lot of misinformation available. One of the things I attempted to use was a PC formatted Zip cartridge. However, it does not like a lot of stuff and repeatedly gave "bad address to DMA-MAP-IN." If you try a bootloader and kernel on a media that gives the above message, it is unlikely that the media hardware is compatible with the bootloader, for reasons I am not entirely sure of. At this point I am posting because I think the issue is less Old World and Open Firmware and more an interaction between the bootloader and the compressed kernel and this is even further from my area of knowledge than Forth and Open Firmware. I tried to remove CPU dependencies in case they exist by installing a G4 CPU on the ZIF Carrier card but I got the exact some scenario. I also used NetBSD's ofwboot.xcf file, even though I knew it would cause an exception but at one past the above address. The raw decoded data was not exactly as above, but the DSI exception occured at the same location. Why the bootloader has no problems on an AGP G4 I have no idea. The aforementioned utility from Apple is System Disk 2.3.1, available at ftp://ftp.apple.com/developer/macosxserver/utilities/SystemDisk2.3.1.smi.bin Do not use later versions, as System Disk 2.3.1 contains functionality that was removed in later versions. The following instructions will be useful: 1) In System Disk 2.3.1, in the main window, select "Advanced Options" 2) Select "Configure Manually" for Input/Output Device 3) Change the Input Device and Output Device settings to "ttya" for both. 4) Select "Stop at Open Firmware prompt" (this is the same as auto-boot? false) 5) Click "OK" 6) Click "Save" 7) Quit 8) Choose "Restart" in Finder (under the menu "Special") When in OF, the following commands are needed: setenv load-base 60000 setenv real-base 200000 reset-all (will reboot) boot fd:1,\boot024.mac bsd4M.gz To return to the MacOS: reset-all bye Booting into MacOS from another operating system will change the real-base and load-base settings. System Disk 2.3.1 will set load-base to 600000, which has to be changed manually to 60000 for now. The primary advantage to using System Disk for this is that it allows one to set the input and output devices to the serial port. ttya is the modem port on a Mac. ttyb is the printer port, which on Macs is not a true serial port but will work with a Mac printer port on the other end. I am not sure if it will work with a PC serial port at the other end. I don't think so. The modem port will, and in general has presented the least problems. Astute observers may note that System Disk allows one to enter the boot-file and boot-command manually. This has been tested against NetBSD and works well. I've also used it to manually boot into OS X with no side effects. Since I believe that eventually the OF settings will not have to be changed, this utility may offer the most effective way to get OpenBSD booted on a Mac. I've been seeing Old World Macs for anywhere from $50 to $150. The ZIF Carrier card was $200 and does not require any software (although NetBSD doesn't seem to recognize the L2 cache). G3 and early G4 CPUs are rapidly getting cheap. I have found that the earlier the hardware from Apple the better the quality. I have a fully functional 1992 Powerbook 160 that has made three cross country motorcycle trips with me. My 7600 is from 1997 or so. In contrast, I am aware of several iMacs that have failed in three years of use. All of the Apple monitors I have bought in the last four years have failed. The point is that the Old World hardware is of high quality and for a few hundred dollars can easily saturate T1 and 10BaseT lines. Seems like a good candidate for OpenBSD. If I can remember anything I may have forgotten or overlooked, I will post it. I will attempt to answer questions as quickly as possible.U