On Mar 6, 2006, at 1:11 AM, Sven Luther wrote:
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).
The miBoot bundled with BootX 1.2.2 can be a temporary alternative and
a way to test newer code.
to maintain the upstream miBoot sources, even if I don't have the
logistics worked out yet:
http://www.mail-archive.com/[email protected]/
msg00117.html
http://www.mail-archive.com/[email protected]/
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.
What kind of access would be possible to the alioth project's storage
space?
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 ?
You yourself pointed out that this is currently required.
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.
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.
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...
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 ?
They converged, and then they diverged. The latest miBoot still has
BootX 1.2.2 sources, but nobody has attempted to build BootX in quite
some time, and BenH's final builds exposed problems with the build
process that were never resolved. A comparison of the generated machine
code is necessary to figure out what went wrong with version 1.2.1 that
necessitated 1.2.2, and the results of that may be used to adjust the
1.2.2 sources to build a binary equivalent to 1.2.2 using the 1.2.1
build process (because that is what is available to me). After that
gets done, there was a version 1.2.3 floating around, which needs to be
merged in.
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.
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.
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
