[Debootloaders-miboot] current status of miBoot

[Aurélien GÉRÔME]

Hi,

On Wed, Jul 26, 2006 at 08:02:24PM +0100, Piotras wrote:
> I have both miBoot_1.0d4 and miBoot-1.0a3-ek working. That said
> I haven't done any work on it in the last two months.

What is the difference between 1.0d4 and 1.0a3-ek?

Have you got a build system (Makefiles) running? If so, would you be
able to put them in the SVN repository with an INSTALL file describing
what toolchain to use? Evenif it does not work yet (missing pieces),
it would allow us to have a "Unix view" of the project.

You can put everything you can under
<http://svn.debian.org/wsvn/debootloaders/trunk/miboot/src/>. You
will need to create src/ first.

> At this stage I don't consider it release ready. However it can
> be used for testing. There is no much work with the miBoot source
> code necessary before the release. It's more about providing the
> components it requires during build and at run-time.

Sure.

> The TODO list:
> 
> 1) Reimplementation of the boot block
> The specification is ready. We need to a person with some knowledge
> of m68k assembly. Some knowledge of MacOS APIs would be helpful
> as well.

I can manage for the m68k assembly knowledge part...

However, do you appear to have some documentation of the MacOSROM
API (functions, parameters, memory entry points)? Without that,
I am completely clueless.

In the future, it might also serve the purpose of implementing some
kind of scanf() function to get input from the user to select different
kernels for instance...

> Temporarily I use original Apple boot block.
> 
> 2) Reimplementation of tiny part of Apple run-time library
> I need to have clean-room reimplementation of 6 trivial functions.
> These should be documented by Apple.
> Temporarily I use my own reimplementation. However it should not
> be redistributed as I implemented these looking at the original
> assembly.

For that, we need to know more about them, can you describe them?
Maybe in a prototype header file in the SVN.

> 3) Remove dependency on UniversalInterfaces
> I read the license again and actually it will not be possible to
> redistribute this code with Debian. It's necessary to reimplement
> fragments based on Apple specification. Possibly there is some
> overlap with libmacos from Emile project. I could also check
> licensing of older distributions of UniversalInterfaces.
> Temporarily I use UniversalInterfaces with some patches for GCC.

OK, since you cannot work on 1) and 2), maybe you can do 3)?

> 4) Remove dependency on PEF
> Essential parts of PEF (Preferred Executable Format) are covered by
> Apple patents, so I'd prefer stay away from PEF. I started to work
> on adding XCOFF loader in miBoot. This change is going to increase
> the size of miBoot image by about 1-2kb.
> Temporarily I use my own quick&dirty XCOFF to PEF converter during
> build and PEF at run-time.

Maybe I am out of topic here, but will this not affect initrd
loading? I remember a special image containing the kernel and its
initrd was needed to use an initrd with miBoot.

> 5) Fix bug related to weak symbol handling
> There is a simple workaround possible. I didn't work on it since it
> affect very limited number of machines (these with no name registry).

I cannot grasp what you intend to say here by "weak symbol handling".

> I should not work on 1 and 2 as I've seen reverse-engineered Apple
> code.

Indeed.

Cheers,
-- 
 .''`.   Aurélien GÉRÔME
: :'  :  
`. `'`   Free Software Developer
  `-     Unix Sys & Net Admin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debootloaders-miboot/attachments/20060726/23e416b4/attachment.pgp