what part of: Mail-Followup-To: debian-powerpc@lists.debian.org Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. don't you understand? On Thu, Oct 11, 2001 at 11:49:27PM -0400, Albert D. Cahalan wrote: > Ethan Benson writes: > > > not quite, MacOS drivers are not required on floppies, they are on > > everything else (hard disks, CDROMs etc). floppies are the only > > exception and thats the only reason miboot boot-floppies are possible > > in debian (thats what boot-hfs.bin is). > > Huh? > > 1. firmware reads CD-ROM (therefore must have a driver) > 2. firmware demands MacOS code > 3. firmware executes MacOS code ??? > 4. firmware loads the OS > > Um, OK... as long as step 3 doesn't seriously happen, one could > fake out the firmware with a dummy MacOS driver. I wouldn't > expect Apple to have PGP signed these drivers. > > Something like this maybe, in whatever binary format Apple used: you demonstrate how little you know about how OldWorld Macintoshes work. first there are two firmwares in OldWorld PCI macs, the first is OpenFirmware, an extremely and hideously broken implementation of OpenFirmware, on most machines its either not capable of reading the disk at all, or can barly read it. the next is a 4MB ROM with the core of MacOS burned onto it (on very old macs this was actually complete enough to boot without any other media). the boot process goes like this: OpenFirmware simply hands over control to the MacOS hardware ROM, this does not involve disk access in any way, thats why oldworlds generally don't read the hard disk very well in OF, and thus why quik is such a pain in the ass. the MacOSROM does the following (roughly): searches for all available disks, CDs, floppies etc. checks the floppy drive to see if it has a floppy, and if so it sees if its an HFS floppy with MacOS bootblocks, and a `blessed' directory containing MacOS system files, if all of these are met it executes MacOS from this floppy. it then checks the hard disk, the very first thing it checks on a hard disk (or CD) is the Driver descriptor map (block 0 of the partition table) this contains a list of MacOS disk drivers installed on the disk (in Apple_Driver43 partitions), if no drivers are found the ROM code rules the disk unbootable and irrelevant, thus ignores it[0]. if the drivers are found the code in them is loaded to replace the disk drivers that were burned into the ROM (since they are usually broken and barly able to read the disk). once it does that it looks for Apple_HFS partitions, and checks each on for MacOS bootblocks AND a blessed directory containing MacOS system files, if all of these are met the first partition it finds is booted as MacOS. (or a specifically selected partition is, but it still must pass all MacOS checks). the MacOSROM is NOT firmware, its MacOS, the code in this ROM contains most of the MacOS syscalls and many library functions, its used during [macos] runtime extensivly. as i said before it used to BE the OS in macs, all the disk based MacOS consisted of were patches and bugfixes that were applied to the ROM based OS. (how else did Apple fit a fully GUI OS on a 400k floppy with room for applications), this archetecture remains in todays MacOS, even on NewWorlds, the only difference there is the hardware ROM is no longer in hardware, its an image file attached to an OpenFirmware bootloader which decompresses it into RAM and passes control to. now its certainly possible for a disk driver to be written which is free software, or even pretends to be a driver but really acts as a bootloader, but nobody is all that interested in learning and coding such a beast, besides that if you ever boot MacOS it may overwrite this driver to `update' it (macos upgrades typically do this), a fake driver would probably interfere with use of MacOS at all, but if you wanted a macos free machine that wouldn't matter i suppose. what miboot consists of is a bit of MacOS code, compiled with expensive MacOS compilers into what appears to be a MacOS System file, the ROM is convinced enough that its MacOS that it will accept it and boot it, but only if the other checks pass (the MacOS bootblocks present on the disk, and the MacOS drivers are loadable from the disk) Real MacOS isn't always fooled and renders miboot unbootable by removing the bootblocks and blessed directory bits since it can usually tell whats Real MacOS and whats a fake. BenH will also tell you of all the troubles of MacOS based bootloaders and the problems it causes. (miboot is a MacOS based bootloader). your thinking of quik and OpenFirmware, it does not require any MacOS drivers, HFS partitions or any of that crap, the problem is OF is so broken its a pain to get it to read the hard disk, much less a floppy or a CDROM. (floppy is sometimes more reliable then hard disk). [0] there are a couple IDE based oldworlds that the MacOS ROM did not demand have drivers installed on the hard disk, this is because Apple shipped those without a partition table at all, just a HFS filesystem put right on the raw full disk. this is a very few machines though, by far the majority all REQUIRE valid MacOS disk driver partitions for the MacOSROM to consider them relevant. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpdzHIJ4DYVE.pgp
Description: PGP signature