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

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.


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

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

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