Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!bruce!cechew
From: cechew@bruce.cs.monash.OZ.AU (Earl Chew)
Newsgroups: comp.os.minix
Subject: Re: Received:
Message-ID: <3492@bruce.cs.monash.OZ.AU>
Date: 20 Dec 90 22:15:08 GMT
References: <39678@nigel.ee.udel.edu>
Organization: Monash Uni. Computer Science, Australia
Lines: 74

In <39678@nigel.ee.udel.edu> pillay.kda@exeter.ac.uk writes:

>>  In the referenced article kevin@nuchat.UUCP (Kevin Brown) writes:

>>> What I REALLY want is a loader that does its thing in 386 mode so it can
>>> load the kernel anywhere in memory, not just in the first 640K.

>I wrote a loader for MS-DOS .EXE files for 80x8/6 systems (PCs) which I
>subsequently used on a target 80186 system. You have to find out what
>format the relocatable binary code produced by the compiler/linker is stored
>as. In my case, it was the standard MS-DOS .EXE file structure. See my
>article 'Relocating Loader for MS-DOS .EXE executable files' in
>Microprocessors and Microsystems Vol 14, No 7, Sept 1990, pp 427-434.

>To have such a loader under Minix, you have to find out what the
>ACK compiler produces as relocatable code. The rest is pretty straight
>forward as all you do is extract the relocatable binary from the file,
>perform relocation (i.e. fix up the relocating items within the program)
>and then jump to the entry point of the fixed-up program.

This, I think, misses the point. I think that Andrew would still like Minix to
load at 0x600 and not necessarily to relocate it. Relocation is trivial (to a
certain degree) by suitably aligning the load point and reloading the segment
registers (because Minix only uses the `small' model). What he wishes is to be
able to load an arbitrarily large kernel image (eg larger than 640k). The
current problem is that the loader (bootblok.s) moves itelf to some high
address and begins loading Minix at 0x600. If your kernel image is
large enough, the loader will quite happily plaster itself with bits
from the kernel.

bootblok.s can maximise the size of the allowable kernel image by doing as
shoelace already does --- moving itself to the last 64k below 640k (assuming
you have more than 640k machine as most do these days). This limits the size of
kernels to about 586k.

What Andrew wishes is for the loader to switch to 32 bit mode to allow loading
of large kernel images. In 32 bit mode, memory above 1Mb can be accessed. This
means that large kernel images can be loaded.

The need for this can be reduced somewhat by dynamically allocating many of the
large buffers required by the kernel (so that the load image is small, even
though the runtime image is large). Bruce has already done this. It does
require a patch to stop shoelace from allocating space.

If you read the kernel code, I think that you will find that the kernel expects
to be located at the bottom of physical memory. Loading it elsewhere may just
cause more headaches for mm (more holes to fill).

So if one decides to leave the kernel low, and the size of the kernel image
exceeds 584k, what does one do about the 384k hole between 640k and 1Mb?
There's not much one can do, I suppose. The loader would have to load the first
584k of the kernel below the 640k boundary and the rest of the kernel above
1Mb. But this causes a problem because things like the BIOS interface and the
video drivers expect their stuff to live in the 640k-1Mb region. Because of
this, it is difficult to map things into this region. Moving, for example, the
BIOS out of this region is probably too difficult.

Perhaps the easiest thing to do would be to load the kernel starting at 1Mb,
leaving memory below 1Mb unused. With Bruce's 386 implementation, memory below
640kb can be easily mapped high -- other implementations may have a hole to
fill. Now, the problem is --- how do you start Minix? Loading above 1Mb is
possible with minimal effort, even using the current shoelace code. However,
the loader would have to switch to protected mode to execute code above 1Mb.
This is possible with a little trickery I presume.

Hmmm... sounds interesting... I might do this in the new year... now if someone
would like to donate some memory so that I have something to load into above
1Mb :-)

Earl
-- 
Earl Chew, Dept of Computer Science, Monash University, Australia 3168
EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655447 FAX: 03 5655146
----------------------------------------------------------------------