[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of miBoot in Debian?

On Mar 6, 2006, at 2:43 AM, Sven Luther wrote:

On Mon, Mar 06, 2006 at 02:01:05AM -0800, Daniel Gimpelevich wrote:
We use an alioth project with a svn repo and a mailing list to hold
logs. We have there two branches, the stable branch which you control,
and a
more free-working devel branch where more adventurous patches are
freely. If they break or are too buggy, you can easily revert them, or
not to include them in the stable branch or whatever.

What kind of access would be possible to the alioth project's storage

Well, you become a alioth member, you get ssh acces to the server, and access to the svn repo or whatever. I am not 100% sure what you are asking about

That answers my question. I was asking to gauge the feasibility of using it in conjunction with the current build process.

huh ? ... /me guesses you are developping on mac-os, right ?

You yourself pointed out that this is currently required.

Indeed. The aim is to get away from this though.

My previous investigations lead me to believe that accomplishing this reliably would actually involve more work than writing a new bootloader from scratch, a la EMILE. There has already been a proposal to allow CD-booting on OldWorld machines by replacing the proprietary code in the driver partitions with an as-yet unwritten Linux bootloader, based on the NetBSD boot process. Keeping the existing miBoot code is mostly a temporary measure anyway, so whether or not the toolchain needed to build it is free is likely to become moot before long.

Ok. Can you tell us more about this ? Will it be needed for plainly
booting a
linux kernel from a floppy ? I don't think we need more than that.

Without running a few tests, It would be hard for me to say exactly to
what degree miBoot relies on that code being there. In the m68k days,
the version word of the boot block also determined whether or not the
code contained therein would be executed. I think the rules were that
if the first byte is 0x44 or the second is 0x0D, the code would be
executed. Later versions of the boot block always had 0x44 in the first
byte of the version word as required by the changing structure of the
System file, but version 24 (0x18) was the last ever produced, and that was still in the m68k days, so the PPC ROMs may have had rules for when
the code is executed that were different. I have not investigated the
PPC ROM boot code that much.

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.

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

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.

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...

problems with the last binary I built from Etsushi Kato's sources
be catalogued...

Could you provide me with this build, i will try to build some sample
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 :


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.

Reply to: