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,\boot24d.mac bsd5Me.gz loading XCOFF tsize=D180 dsize=1490 bsize=638 entry=24000 SECTIONS: ..text 00024000 00024000 0000D180 000000E0 ..data 00032000 00032000 00001490 0000D260 ..bss 00033490 00033490 00000638 00000000 loading .text, done.. loading .data, done.. clearing .bss, done.. >> OpenBSD/macppc Boot no active package/ Kernel file opened... Header read... Executing ELF file... Reading segment 0...5724656+241140 Zero out bss... BSS maxp... End of segment 0 pass... FREE phdr... ELF and Section Headers... Frobbing... Returned from elf_exec...=5966332 (0x5b09fcu) chaining...leaving initppcCopyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2003 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 3.3-stable (OWRAMDISK) #66: Mon Apr 26 13:26:03 EDT 2004 root [at] OpenG4.my.domain:/usr/src/sys/arch/macppc/compile/OWRAMDISK real mem = 167772160 (163840K) avail mem = 140673024 (137376K) using 1254 buffers containing 8388608 bytes of memory mainbus0 (root) cpu0 at mainbus0: 750 (Revision 202): 195 MHz: L2 cache not enabled mpcpcibr0 at mainbus0: bandit, Revision 0xff Now that I've got everyone's attention... :-) Yes, that's the initial part of the dmesg from OpenBSD on an Old World Mac. The last line is where it hung up. I infer there is still work to do. The CPU is correct - I have a ZIF Carrier card from XLR8 with a 300Mhz G3 in it. I've posted several files at http://www.dialectronics.com/OpenBSD that show the code to get to this point. I will document them below, after further descriptions of the Open Firmware obstacles that had to be overcome. I had been thinking that there was a problem with how the kernel was getting its input and output devices. This was not correct, as RAMDISK allows for serial ports. Since Old World Macs still have serial ports, it's perfectly reasonable to accept ttya as the input/output devices. The hangup I previously encountered was in the /src/sys/arch/powerpc/powerpc/pmap.c file. I don't know exactly the full problem, but it also ties back into claiming memory in OF before jumping into the kernel. When pmap_bootstrap is allocating HTABs, it requests from pmap_steal_available a 4M block aligned 4M (at least, it does on my G4, which I use to ensure that the kernel works before testing it on my 7600). pmap_steal_available looks at the memory regions it got from pmap_avail_setup, which gets the memory regions and total memory from ofw_mem_regions in src/sys/arch/macppc/macppc/ofw_machdep.c. If the memory area for the kernel is not claimed in OF, the kernel area will be included in the regions returned. When I moved the kernel link address to 0x500114 from 0x100114, this resulted in the kernel getting run over as apparently the memory block returned started below the new link address. I think there is some code in pmap.c that checks for regions before the end of the kernel, so I am not completely sure why this occured. I resolved this in two steps. The first was to claim the memory, as previously documented, and the second was to modify ofw_mem_regions to return only the _last_ memory region OF returns, instead of any available memory regions, contiguous or not. This second part is probably not absolutely necessary on OF 2.x and later, as they do a better job of placing critical components in memory at better locations. For OF 1.0.5, this is critical because as discussed in the lengthy initial post, the stack area for the bootloader is not claimed in OF and will be returned as an available region smack dab in the way. Not a good idea. By not moving real-base, OF loads at 0x400000 in OF 1.0.5. Linking the kernel at 0x500114 and claiming the memory means that the kernel is the last thing in physical memory. By using only that last unallocated region, the memory is guaranteed to be contiguous and free of critical code. An additional benefit to not moving real-base is that the user does not have to make any changes to OF settings to boot OpenBSD kernels. OF 3.0 loads real-base in the last 2M of physical memory, and loads all exceptions and related stuff for bootloaders beginning at 0x0. This leaves a very large contiguous region. For OF 3.0, it'd be nice to leave the kernel down at 0x100114, just to get every last Meg of RAM. I do not know of a way to move the stack for the bootloader, so for OF 1.0.5, I think the best option is to sacrifice the bottom 5M. I think that the claiming could be tweaked some in order to return two regions, but the one underneath the kernel would have to be limited to give stack a lot of room. The same stack that is passed to the bootloader appears to be passed to the kernel. I do not know if this is the same stack the kernel uses (I assume it is). The only other thing I found is that the reason OF_chain appears to be passing the RELOC and end addresses relative to the bootloader instead of the kernel. This is probably why using the OF interface "chain" is failing. I haven't had a chance to test this, but it would stand to reason that if the interface is expecting the start and size of the kernel, passing it the bootloader values would fail. However, I believe that not using OF "chain" and remaining with jumping into the kernel directly is a better approach. The docs state that when OF does the chaining, it frees up memory associated with the bootloader. This could lead to problems with the bootloader memory area showing up as an available region. I believe that leaving the bootloader in memory and valid is a good option. This can allow for a much better cleanup after the kernel exits, for stuff like restoring default values and possibly logging. Which brings me to another point: ddb. While it is the standard debugger, for OF 3.0 Macs I suspect it may not be of much use, given that these Macs (New World) do not have serial ports. I've seen a few posts of people unable to give ddb reports because there's no screen capture and I found that ddb would not respond to keyboard inputs anyways. As such, I've started on trying to tie ddb/debugging into the OF interface. The RAMDISK I posted will kernel panic back into OF instead of ddb. Unfortunately, the keyboard and monitor do not respond, so some more work is warranted. I've been able to read into memory files from disks in OF, but I am having some problems getting OF to write to files. If I can figure this out, I believe I can do some debug logging. As an aside, and further out, it might be possible to use Open Firmware as an interface for generic device drivers to any peripheral that is OF (IEEE 1275) compliant. For example, I could have saved myself a lot of headache if the Asante Ethernet card I have in addition to the motherboard Ethernet on my 7600 was OF compliant. If the card was, I could use OF to use the card with OF's tftp package and netboot, without any driver. Unfortunately, Asante didn't build in any OF ROM at all and it's basically just a card until the MacOS kicks in. (Compounding my headache, Bellsouth's DSL requires the motherboard Ethernet on Macs, and because I needed my G4 for OpenBSD, I had to use my 7600 for internet access. Completing the Keystone Kops devel environment, I only have one working monitor in addition to the Powerbook I use for a serial console.) I've posted a bootloader and kernel: http://dialectronics.com/OldWorldMacs/code/boot24d.mac http://dialectronics.com/OldWorldMacs/code/bsd5Me.gz The "d" and "e" are just versioning. The two files will fit on a floppy disk. I can not stress enough that the files must be _contiguous_ on the floppy or other media. These two files will also boot OF 3.0 New World Macs, at least, they do my AGP G4. The kernel will panic when it attempts to read the rd filesystem. It hasn't been a focus of mine to figure out how to use crunchgen and rdsetroot, so it's just a plain kernel. The bootloader can handle gzip -9 files as well as raw ones (that's in the code, nothing I did), so one can unpack the kernel and try it on a New World Mac. To do this, put the bootloader file on the DOS partition (I believe this has to be partition i, accessed by /dev/{}i, where {} contains the drive driver), and the unpacked kernel at /. Unpacking might not be necessary, but I haven't tried it like that. On a New World Mac you should get to the file system panic. The above bootloader will do the proper claiming, so the linking described above will be taken care of. The bootloader will also do proper claiming for the GENERIC kernel already installed as well, if you want to launch from it instead of OFWBOOT. One thing about the bootloader format - so far, all of the OF Macs have been able to boot XCOFF bootloaders, but OF 1.0.5 can not do ELF bootloaders. This may be something to keep in mind, although the source tree does an excellent job of being able to generate everything in /stand. To boot a floppy with the two files above, at the OF prompt type: boot fd:1,\boot24d.mac bsd5Me.gz Any DEFAULT CATCH messages quite likely means that the files are not contiguous. Try brand new floppies (yeah, I haven't bought one in years either and I've already gone through a ten pack). So, without further ado, I will discuss the changes to the files that yielded the above dmesg (please accept that further cleaning and revision are forthcoming). (hyperlink - source tree location) BOOTLOADER: http://dialectronics.com/OldWorldMacs/code/Locore.c - src/sys/arch/macppc/stand/Locore.c altered OF_claim to return either -1 if the interface call failed or the address returned. This is because if aligning is requested the memory address returned may not be the one the block was requested to begin with. changed setup() to check for both -1 and 0 return values from OF_open. This is important because when requesting an instance to a package/file that is not present, OF_open will return 0, not -1. OF_open will return -1 when the syntax to OF_open is invalid. If OF_open succeeds, it will return a memory address. This can be verified in OF by the following Forth code: " file name" open-dev where file name is replaced by either a package name or a file. For an instance of the input device, the call would be: " input-device" open-dev OF will return an instance of whatever the input device is for the Mac while in OF. If the command was " keyboard" open-dev on an OF 1.0.5 Mac, the call will return 0, as the alias "keyboard" does not exist. The white space between the quote and file name is critical, as the actual command is "(space) _not_ ". Since the alias "screen" does not exist on OF 1.0.5 Macs, there's a good chance that if the OF_open fails the output device will be "/chaos/control" so try that. To be done: need better examination and determination in the event of stdin is not listed. Added two routines: ofw_dbg and ofw_panic. At some point, ofw_dbg was defined but not actually written, or at least I've been unable to find it. ofw_dbg will print to the output device any messages passed to it. ofw_panic will revert call OF_enter, which is in another file and is different than OF_exit. According to the OF docs, using "enter" instead of "exit" should allow resumption of the executable, but this hasn't worked for me. These two calls need be consolidated with the kernel versions and vprintf needs to be properly linked. http://dialectronics.com/OldWorldMacs/code/openfirm.h - src/sys/arch/macppc/stand/openfirm.h added prototypes for ofw_dbg and ofw_panic http://dialectronics.com/OldWorldMacs/code/boot.c - src/sys/arch/macppc/stand/boot.c altered the routine chain to claim the kernel memory in OF based on the esym (end of symbols) address and the entry address. Just to ensure ease of use, I run the end of the claim to the next 1k boundary. As it stands, OF_chain doesn't use the starting address and size and manually jumps into the kernel, but if OF_chain does ever call into the OF interface with "chain," the proper values for the kernel start and size need to be passed instead of the bootloader's. Earlier I had the call to OF_claim in /usr/src/sys/lib/libsa/loadfile.c, but that file is machine independent and not appropriate for that call. The downside is that loadfile.c will write the file into memory without seeing if anything is in the way. OF will catch this, so if we've gotten to boot.c's chain routine, apparently nothing was in the way. As discussed above, claiming the memory for the kernel in OF will remove it from available regions returned to the kernel during set up. http://dialectronics.com/OldWorldMacs/code/Makefile.boot.mac - src/sys/arch/macppc/stand/Makefile The primary changes are to RELOC at 0x24000 and some of the link flags. I consolidated on NetBSD's settings, including using fix-coff instead of hack-coff. I recommend that if hack-coff is going to stay in the tree it be properly licensed, as http://www.iglu.org.il/lxr/source/arch/ppc/boot/utils/hack-coff.c clearly shows crediting to Paul Mackerras and has significant code overlap with the one in the OpenBSD CVS tree. The big link flag difference is to link static. Maybe important, maybe not. http://dialectronics.com/OldWorldMacs/code/fix-coff.c - src/sys/arch/macppc/stand/boot.mac/fix-coff.c Copped from NetBSD, license intact. http://dialectronics.com/OldWorldMacs/code/loadfile.c - src/sys/lib/libsa/loadfile.c No code changes, other than adding milestones for feedback. If the bootloader exits at the "lseek symbols" message, the kernel being loaded has been compiled with symbols intact. The kernel needs to be linked without symbols. KERNEL: http://dialectronics.com/OldWorldMacs/code/db_interface.c - src/sys/arch/macppc/macppc/db_interface.c Changed Debugger to call OF_enter() instead of ddb_trap(). http://dialectronics.com/OldWorldMacs/code/machdep.c - src/sys/arch/macppc/macppc/machdep.c Added ofw_dbg and ofw_panic, same as above. Prototyped ofw_kdoprnt and ofw_kprintn, which were identical to the versions in src/sys/lib/libsa/printf.c but are typed static and not available. While the vprintf calls are in ofw_dbg and ofw_panic, they aren't working. Not important for the posted bootloader and kernel but useful for debugging. http://dialectronics.com/OldWorldMacs/code/ofw_machdep.c - src/sys/arch/macppc/macppc/ofw_machdep.c Altered ofw_mem_regions to return the last listed memory region. Could be tweaked to return more than one, in order to recover a few M of RAM, but care has to be taken to ensure that the bootloader and kernel stacks are not included in the available region. Altered save_ofw_mapping to handle "screen" and "keyboard" aliases not present, and added better checking on OF_open calls as discussed above. The commented code is an alternate way of determining the input and output devices but is not in strict adherence to the 1275-1994 specification, which recommends using the "/chosen" package for determining these. http://dialectronics.com/OldWorldMacs/code/openfirm.c - src/sys/arch/macppc/macppc/openfirm.c Added OF_enter to revert to OF that in theory is supposed to allow resumption of execution. http://dialectronics.com/OldWorldMacs/code/OWRAMDISK - src/sys/arch/macppc/conf/OWRAMDISK This is the config file for the ram disk kernel above. It's the only file I added any personal identification, because I want it clear that screw ups here are all mine. The basic premise is that for a RAMDISK on Old World using a floppy, lots of Ethernet drivers aren't really necessary, OW Macs don't have IDE, Firewire and USB, but they do have SCSI and mace Ethernet (which is commented out in the stock RAMDISK config file). Stripping out those drivers got the compressed kernel to around 700k, plenty small enough to fit on a floppy. If I've screwed up something here it's because the kernel/driver aspect is outside of my knowledge. I'd like to reduce the MINIROOTSIZE as much as possible, because the floppy drive can timeout on long reads (maybe). http://dialectronics.com/OldWorldMacs/code/Makefile.owramdisk - src/sys/arch/macppc/compile/OWRAMDISK/Makefile There are only a few changes that have to be done to the Makefile generated by config. The first is to change the LINKFLAG to 500114 instead of 100114. Much futher down, when determining if DEBUG is enabled, the -S flag needs to be changed to -s to strip symbols. What I would do when figuring this out is to compile -S and do objdump -d bsd > disBSD, change to -s and do "make bsd" without doing make clean or anything. That would relink and strip the symbols, but leave me with a disassembly file that had the symbols intact. Other files posted in the http://www.dialectronics.com/OldWorldMacs/code/ directory have been poked and prodded by me, but should work stock. I don't recall any code changes in them. I believe that's all of the files I modified. If I recall anything else, I will post them. At this point, I'm going to try to get the kernel booting further. If anyone has advice, feel free to volunteer it. I'm going to talk to Ryan about his code that deals with turning on the L2 cache on upgrade CPUs. That would be a great help with speed. G3s without L2s are slugs. If anyone has experience with the mace driver, please see what will be needed to get it working because the installer will need internet access. Oh, one last thing - I've found that when logging off from kde and the monitor doesn't come back up, the keyboard is still available. It takes a while for it to happen, but if you type "reboot" into the keyboard, the Mac will reboot properly. The monitor aspect may relate to the patch code posted at various places and probably can be incorporated into the bootloader if it resolves the problem of the monitor returning to use. tim