Re: Status of miBoot in Debian?
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
> >commit
> >logs. We have there two branches, the stable branch which you control,
> >and a
> >more free-working devel branch where more adventurous patches are
> >tested
> >freely. If they break or are too buggy, you can easily revert them, or
> >chose
> >not to include them in the stable branch or whatever.
>
> What kind of access would be possible to the alioth project's storage
> space?
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
though.
> >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.
> >
> >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.
> >>>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.
> >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.
> >>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 ?
Friendly,
Sven Luther
Reply to: