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
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.
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
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.
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
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.
Reply to: