Otherware/Otherware_1_SB_Development.iso/amiga/os/kludge.rea

Text File | 1992-11-11 | 8KB | 177 lines

NOTE from Zik - the files you want for KludgeMach are
KludgeMach-x.xxx.tar.Z (the normal distribution) and SIM.lha (if you
want the special kernel debugger). This is seriously hackerware,
be warned!

The rest from Bryan:
--------------------------------------------------------------------------

                               Requirements
                               ~~~~~~~~~~~~

I'm running on a 25MHz A3000 with 2.04 in RAM with four megs of fast
memory, two of chip.  This version of Mach ('KludgeMach') should work with
any amount of fast memory as long as you have some.  (The microkernel
_only_ knows about the fast memory; chip memory is not paged or even kept
track of by it.)  Mach probably requires an A3000, but may work with other
68030-based Amigas.  (If it doesn't work for you the first time, try
turning Enforcer on.)  It probably works with any Kickstart version.

To work with KludgeMach, you'll need Markus Wild's GCC 2.1 port (later
versions will probably also work), plus some other tools which I've included
in the 'bin' directory.  I'm using ixemul.library version 39.26; you will
probably need that version or later.



                               Installation
                               ~~~~~~~~~~~~

OK, hold tight, this is rather messy...

First, find a partition with plenty of space, and un-tar The File into it.
Be sure you use GNU tar (which should be available the same place you get
the archive), or a newer version built with ixemlib.  It will create a
directory called 'mk74'.  Then do these assigns, making them permanent if
you wish (in your startup-sequence or whatever):

Assign Mach: mk74
Assign MK: Mach:kernel

Now add the 'bin' directory to your path, or otherwise make the programs in
it accessible.

Now create a bunch of directory links with the following commands:

ln -d mk:mach mach:include/mach
ln -d mk:amiga/include mach:include/machine
ln -d mk:amiga/include mk:mach/machine
ln -d mk:device mach:user/libmach/device
ln -d mk:mach mach:user/libmach/mach
ln -d mk:amiga/include mach:user/threads/machine

You should now have an environment in which you can build KludgeMach.  To
do so, go into mk: and type 'dmake'.  (Other makes will probably work too.)
To run it, type 'mach:mach' (or '/mach' from the MK: directory).  If all
goes well, a green-on-black machSIM screen should be displayed with the PC
at $40000000, which is the virtual memory address where Mach is currently
loaded.  You can step through it to examine the boot process (though note
that there are some places you _cannot_ step through, such as load_context
- you must use a breakpoint afterwards).  To quickly see if Mach will
successfully bootstrap itself, type 'b_idle_thread_continue' <return> and
then <amiga-g>.  If you again get the machSIM display with the PC at
_idle_thread_continue, then it's gotten through the whole kernel bootstrap
sequence - if you continue to step through this function, you will notice
it goes into an infinite loop waiting for something to do.  (Also take a
look at the console output at this point, as explained below.)

I have managed to build libmach, but it is completely untested.  (Nothing
to test it with...)  I had to coax MIG through most of the C-file
generation by hand, but as it's set up you should be able to 'dmake' in the
user/libmach directory and get a 'libmach.a', a 'libmach_sa.a', and a
'crt0.o'.  I have included pre-made versions of these in the 'lib' directory.
The situation is the same with libthreads.



                          Working with KludgeMach
                          ~~~~~~~~~~~~~~~~~~~~~~~

First, you'll need to learn how to use SIM, if you don't already know how.
I've included the manual in this directory; like the author says, "read it
or die."  The version of SIM included, which I have dubbed "machSIM", is a
version specially modified by me to work with Mach.  As such, the manual is
not completely accurate, and some features may have been broken by my
changes.  However, all of the necessary functions seem to work.

Note that SIM is normally a Shareware product, and does not come with
source code, but I have received special permission from the author to
distribute machSIM in binary form for the purpose of getting Mach going.

To reboot back to AmigaDOS from , run the code at absolute address 0.  (In SIM
type 'A0' <return> <amiga-j> <amiga-x>.)  Rebooting by the keyboard doesn't
work for some reason.

To see the console output at any time, look at the buffer starting at the
symbol '_console_buf' (i.e. 'm_console_buf' in SIM).

I have 'illegal' instructions sprinkled around most of the Amiga code that
I haven't tested, so if SIM traps because of one of those, you can NOP it
out and see what happens.

The interrupt vector table is set up at 0 for SIM's benefit.  (SIM 1.x has
never been fully adapted to 68010+ processors; the authors is currently
working on the "next-generation" SIM that will fully work on all
processors.)  Most of the interrupt vectors come pre-initialized to trap
into SIM; you can see the exceptions in trap_init() in kernel/amiga/trap.c.
However, the vector table is also mapped into kernel address space by
pmap_bootstrap; this is where the VBR actually points to.

I currently have memory configured in a rather weird configuration for
debugging purposes:

        $00000000-$0fffffff     Transparently translated in supervisor mode
        $10000000-$3fffffff     User address space
        $40000000-$ffffffff     Kernel address space

I haven't yet figured out completely how AST's and interrupt scheduling
work, so I have the clock interrupt and such disabled.  Thus, right now
Mach is not preemptive.  Otherwise it seems to work fine to the limited
extent to which I've been able to test it.

One small but important module, kernel/amiga/takeover.asm, requires a
commercial 680x0 assembler (or a freely distributable assembler that I
don't know about) to assemble.  I'm using an as-yet-unreleased assembler,
ProAsm, by Daniel Weber.  To assemble this module with another assembler,
you'll probably have to make some changes.  In any case, you shouldn't need
to reassemble this module unless you want to change the way KludgeMach is
booted.



                         Where do we go from here?
                         ~~~~~~~~~~~~~~~~~~~~~~~~~

We'll need three main things before we have something workable:

* A basic console device driver.  A serial-based driver may be simplest and
easiest to work with, if most of the people who will be doing the initial
work have access to a second computer or a dumb terminal.  That way we can
debug with SIM locally while viewing your session on the remote terminal -
quite a reversal of standard OS debugging procedure. :-) We'll need a
regular graphical console driver.  I've got some code to copy the topaz
font out of ROM (in a system-friendly way), if anyone wants it.

* SCSI device drivers: either specially written drivers to run under Mach,
or a way to run standard Exec device drivers under Mach.  The first,
"brute-force" method is probably what we should start with, probably for
the A3000's built-in SCSI chip first.  But to support a large percentage of
capable Amigas we may need a way to run Exec drivers eventually anyway.

* An operating system. :-)  Michael Saleeba may be able to get the BSD
Single Server working, but since that requires a Unix source license it
will probably not do most of us much good (including me).  I'm looking into
the possibility of porting the higher-level parts of 386bsd or Linux onto
Mach.  Any other ideas are more than welcome.



                             Contact Addresses
                             ~~~~~~~~~~~~~~~~~

You can contact me at the following addresses (in order of preference):

        [e-mail]
        [e-mail]

You can contact Stefan Walter, the author of SIM, at the following addresses:

        [e-mail]
        [e-mail]

Note that any problems you find with machSIM are likely to be _my_ fault, not
Stefan's, due to my hacking of his code to work with Mach.  Also, unless you
find something really seriously wrong with machSIM, please don't complain
to either of us about it - machSIM is only a temporary hack, and we should be
spending our time getting Mach going, not perfecting machSIM.