Fwd: [Debootloaders-miboot] current status of miBoot

[Piotras]

This time including debootloaders-miboot at l.a.d.o and Sven:-)

---------- Forwarded message ----------
From: Piotras <piotras at gmail.com>
Date: Jul 26, 2006 11:34 PM
Subject: Re: [Debootloaders-miboot] current status of miBoot
To: Aurélien GÉRÔME <ag at roxor.cx>


On 7/26/06, Aurélien GÉRÔME <ag at roxor.cx> wrote:
> 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?

1.0a3-ek is an similar to jcarr version (used in LinunPPC 2000).
It includes yaboot-like configuration file, GUI and some support
for NuBus Power Macs. AFAIK all the parameters can be updated
on boot.  1.0d4 is much simpler and also smaller so we should
start with it.

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

Yes, I have build system with Makefile. I'll import source code
of miBoot into svn by the end of the week.

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

OK

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

I've send the boot block specification to debootloaders-miboot.
It includes link to Apple documentation. You will need to find proper
APIs to implement functionality described in the specification.
There is also some info on assembly ABI in the Apple doc.

For development and testing you could try Mac-on-Linux in OldWorld
mode. You would need to own a compatible machine [1] to legally get
MacOS ROM from it. I've got my PowerMacintosh 8500 from a friend who
didn't need it anymore.

And of course, I can assist with finding bugs.

[1] http://www.maconlinux.org/userguide/owroms.html

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

Another option is to switch to miBoot-1.0a3-ek in the future.

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

I'll send some more info. Probably I need to provide some textual
description as Apple doesn't give much info about implementation.

>
> > 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)?

Point taken.

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

This is not related to Linux kernel loader. Two of miBoot modules
are compiled to PEF format to facilitate loading then on run-time
by Apple dynamic loader.

>
> > 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".

Usually dynamic resolver assumes that program or library cannot
be loaded if any of the referenced symbols is not resolved. Weak
symbols are intended to remove this limitation:
====
int optional_func () __attribute__ ((weak));

int test () {
    if (optional_func) {
        /* if function has been resolved successfully at run-time ... */
        ...
    }
}
====

Even with all optimizations disabled GCC assumes that all functions
are defined unless "__attribute__ ((weak))" was specified. If I remove
__attribute__ in the code above GCC will remove the check and assume
that the condition is true. The actual code that perform this optimization
is in gcc/c-common.c, just before lines:
        warning ("the address of `%D', will always evaluate as `true'",
                 TREE_OPERAND (expr, 0));

The problem with using this attribute for miBoot is that it triggers
some problems with binutils for my target (powerpc-ibm-aix4.1).

I could think of adding work-around to miBoot sources (some magic
__asm__ __volatile__). The other options are patching single line in
GCC or fixing binutils:-(

>
> > 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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFEx9VMI2xgxmW0sWIRAniLAKDnSEBcJdblcIWeJCU8P4OG05JUYACg0Z/U
> u8TbHYJD58kcB5UXxp8BErY=
> =a6wZ
> -----END PGP SIGNATURE-----

Piotr Krysiuk