Re: Status of miBoot in Debian?
On Mon, Mar 06, 2006 at 12:45:33AM -0800, Daniel Gimpelevich wrote:
> On Mar 5, 2006, at 11:38 PM, Sven Luther wrote:
> >>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.
Not sure, this is only second hand info from Jeremie Koenig or random users
two years ago or something such. We should try the newer code maybe, but the
size issue is also important, since we had something like 67 bytes free on one
set of floppies (the 2.6.14 i think).
> >>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.
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.
> >>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.
huh ? ... /me guesses you are developping on mac-os, right ?
> >>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.
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.
> >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 ?
> >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...
I thought that latest miboot/bootx was integrated already ?
> >>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
We have no problem with rsrce.
> 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.
Friendly,
Sven Luther
Reply to: