On Mon, Mar 06, 2006 at 03:27:40AM -0800, Daniel Gimpelevich wrote: > >Ok. But like said, thanks to Piotr, we have a reverse engineered spec > >of the > >boot block, and can do a clean-room reimplementation. > > The spec of the boot-block structure has always been publicly > available. The boot-block code is quite another matter, and it does not > exist in a vacuum. It cannot be described outside of the context in > which the Mac OS ROM code calls (or doesn't call) it, which must also > be reverse-engineered.
Ok, let me rephrase this. The structure is documented, and cause no copyright problems. We have a reverse engineered spec of the actual code blob, which we can thus reimplement. > >>>>>Second, Piotr has > >>>>>actually reverse engineered said boot block, and we only need > >>>>>someone > >>>>>knowledgeable with m68k assembly and mac-os roms to reimplement it, > >>>>>you sound > >>>>>like a likely candidate for that :) > >>>> > >>>>I would not be a candidate for a "clean room" approach because I > >>>>have > >>>>been staring at disassemblies of Mac OS ROMs for more than 20 > >>>>years. I > >>>>do not know what his "reverse engineering" consisted of, but I have > >>>>walked through the m68k machine code that's in it. > >>> > >>>Did you look at the boot block ? > >> > >>A code walk-through is rather impossible without the code in front of > >>you... > > > >Ok, i meant, have you looked at the asm of the boot block, not the > >rest of it. > >If you have not looked at it, but only at other mac os rom parts, you > >are a > >good candidate for reimplementation. > > Yes, when I say "m68k machine code" I'm referring to asm, of course. > And by "in it" I mean in the boot block. I have seen it many times. ok. Maybe you can compliment the info found in Piotr's work then. > >>>We have no problem with rsrce. > >> > >>I have not looked at rsrce's source yet, but somehow I doubt it fully > >>implements the data-moving algorithms that would be necessary to > >>accomplish what it claims to do. > > > >As long as we can boot a linux kernel from a floppy, i am happyt. > > I still dream of a floppy-initiated netboot for OldWorld... :) I guess if the kernel included the network driver and nfs-root support, it should be ok. > >>>>problems with the last binary I built from Etsushi Kato's sources > >>>>could > >>>>be catalogued... > >>> > >>>Could you provide me with this build, i will try to build some sample > >>>floppies > >>>with it and 2.6.15 kernel, and propose them for our users to test. > >> > >>wget http://homepage.mac.com/danielg4/System.bin > >>hcopy -m System.bin : > >> > >>You will also need to create a configuration file, preferably named > >>miboot.conf, with a layout similar to lilo.conf, but more restricted. > > > >mmm, i will add testing this on my TODO list. Not before a week or two > >though. > > > >As for the config file, we right now do : > > > > dd if=/dev/zero of=$@ bs=1024 count=$(FLOPPY_SIZE) > > hformat -l $(DISK_LABEL) $@ > > echo device $(TEMP_BOOT).new > $(TEMP)/miboot.conf > > echo kernel $(TEMP_KERNEL).gz $(KERNEL_CMDL) >> > >$(TEMP)/miboot.conf > > miboot -c $(TEMP)/miboot.conf > > > >with miboot doing the proper magic, and the miboot packages contains : > > > >/usr/share/miboot/System.rsrc > >/usr/share/miboot/hfs-bootblock.b > > > >So, i should replace the System.rsrc by your System.bin in some way ? > > Your current "miboot" shell script bends over backwards to install the > file from a dump of its resource fork. I could supply the binary in > such a format, but this way, it could be installed with a simple "hcopy > -m" command as shown above. The "miboot" shell script would not be > used. What about the configuration file, of which the kernel options are the most important ones ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
