Re: Status of miBoot in Debian?
On Mar 5, 2006, at 11:38 PM, Sven Luther wrote:
On Sun, Mar 05, 2006 at 10:42:55PM -0800, Daniel Gimpelevich wrote:
Please forgive me for trying to start a discussion off any mailing
list, but the Debian lists are rather high-traffic for my tastes. I
Well, nothing forces you to read it, please just CC debian-powerpc in
the
future, so other interested folk can participate in the discussion. I
don't do
it here, but please CC your reply there.
Done.
have only now noticed that you have a Debian package for miBoot, and
that it is based on a very early release. I have put forth a proposal
Well, later version are known not to work correctly, so we use what
works. I
never really worked on it myself, it was Jeremie Koenig who made the
packaging.
May I ask exactly what worked improperly? I'm sure it could be easily
fixed if it used to work.
to maintain the upstream miBoot sources, even if I don't have the
logistics worked out yet:
http://www.mail-archive.com/nubus-pmac-users@lists.sourceforge.net/
msg00117.html
http://www.mail-archive.com/nubus-pmac-users@lists.sourceforge.net/
msg00306.html
You would be very welcome to maintain it in one of the alioth
repositories,
either as a sub-repository of the kernel repository, or in a separate
repository. We would also maintain yaboot (at least the debian part)
there.
Perhaps I'm missing something obvious, but I can't quite imagine how
that would work.
I realize that the primary Debian use of miBoot is to squeeze a
bootloader with kernel onto a floppy disk, for which a current miBoot
is less suitable due to the larger binary size, but once a patch
submission system is established, conditional compilation may be added
Yes, this would be welcome. Not sure about patch submission system,
just put
it in a SVN repo and let people modify it there, maybe having two
branches or
something to test patches in a devel branch.
The problem with SVN is that, AFAIK, it cannot keep track of the
resource forks and HFS metadata associated with the source files,
without which, any degree of integration into the build process would
become nearly impossible.
to trim out things like the GUI and config file parser. I see
scattered
mentions in the Debian mailing list archives of efforts to "free"
Well, miboot is non-free for two reasons :
- the boot sector is taken from apple's boot block, and contains a
couple
100 or so m68k assembly instructions. As we don't have any kind of
distribution licence on it, this is why it is not possible to
distribute
it.
- miboot needs code-warrior 4 and mac os 9 or earlier to build, as
thus it
cannot enter debian-main, which needs to be buildable from
debian/main.
Both problems are individually handled. We have two ideas for the
first point.
First benh mentioned that miboot could actually boot by purely
removing the
code bit, but nobody has gone out and actually tried that.
I can confirm that. The boot block may indeed contain any arbitrary
m68k machine code, with certain restrictions. The first time I saw
miBoot some half-decade ago, I was surprised that BenH chose to use
Apple's boot block directly, and only replace the code that executes
after it. It would have been perfectly possible to engineer a
bootloader that begins its execution at boot-block time, rather that
following it, but miBoot evolved to depend heavily on having the
standard boot block execute prior to its own code. However, I believe
it would still be possible to modify miBoot to be able to execute at
boot-block time. When BenH told you that the code may simply be removed
from the boot block, he was referring to the fact that, under certain
circumstances, it is never executed at all.
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.
The second problem is also somewhat tackled by Piotr, who did some
early work
to build miboot using gcc/m68k. I think he uses some apple wrapper
library for
it, whose licence needs to be checked. Piotr, can you comment on this
? And
would you be willing to participate in a joint effort with Daniel to
work on
miboot ?
Now, _that_ is very exciting. And I was planning to do a little work on
BootX as well...
miBoot, but not a lot of specifics. What is the current nature of
these
efforts with regards to their progress? I would be glad to offer any
assistance that I can with miBoot.
Cool. The current nature is as above, i am not sure many people are
working on
it beside Piotr, but we have a package that is used to build the debian
non-free miboot installer floppies, and mostly work. We aim to free
miboot for
the etch timeframe (freeze planed at the end of july), but i saddly
don't
really have time for working on miboot itself myself.
I wouldn't really have much time for it either, so I don't know how
much I'd end up accomplishing by July, but I would definitely be able
to make some kind of contribution to the effort, even if it means
keeping the package in the non-free section. I think the first order of
business should be turning the "mostly work" into a "work" so that
existing problems are eliminated. Perhaps the elimination of the
dependency on rsrce is worth the extra bulk in the binary? If all the
problems with the last binary I built from Etsushi Kato's sources could
be catalogued...
Reply to: