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, andthat it is based on a very early release. I have put forth a proposalWell, 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 oneset 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/nubus-pmac-users@lists.sourceforge.net/ msg00117.htmlhttp://www.mail-archive.com/nubus-pmac-users@lists.sourceforge.net/ msg00306.htmlYou 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 chosenot 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 abootloader with kernel onto a floppy disk, for which a current miBootis less suitable due to the larger binary size, but once a patchsubmission system is established, conditional compilation may be addedYes, 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 atboot-block time. When BenH told you that the code may simply be removedfrom 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 alinux 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 onBootX 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 onit beside Piotr, but we have a package that is used to build the debiannon-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 meanskeeping the package in the non-free section. I think the first order ofbusiness 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 theWe 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 couldbe catalogued...Could you provide me with this build, i will try to build some sample floppieswith 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.