Re: i386/loader compiled with NOFORTH

Ruslan Ermilov wrote:
> On Fri, Apr 25, 2003 at 04:49:21PM -0400, John Baldwin wrote:
> > On 25-Apr-2003 Ruslan Ermilov wrote:
> > > But if we manage to load kernel high, above 1M, there
> > > should be something that allows us to relocate heap
> > > there, no?  Also, can't we just trust what BIOS thinks
> > > about the amount of memory?
> >
> > We load the kernel into lower memory first and then copy it
> > up above 1mb.  The memory above 1mb is not managed by the
> > heap and is only used as the destination of the kernel.
> 
> I understand that this is how it works now.

The main issue here is the link location for the kernel itself,
and the minimum amount of memory FreeBSD wants to require for
installation and operation.

The problem comes down to not being able to use RAM below the
kernel load address until after the kernel is up, after which
it can be added to the available kernel memory.

The reason for this is that, when you boot, you boot in real
mode, and you need to convert from running in real mode to
running in protected mode, and you need the image in memory
that was loaded by the real mode loader to exactly correspond
to the image after relocation, plus some base address, plus
some relocation address.

What this boils down to is that you want the unrelocated code
to look exactly like the relocated code, and then enter protected
mode and start executing the relocated code (this is done using a
stack trampoline to "return" to the start address of the relocated
code in protected mode).

FreeBSD fails to implement this wholly in 5 places (one of which
is the recursive mapping for the GDT, which is unavoidable), most
of which live in assembly language code.

> Well, hm, the installation requirement was always slightly
> larger than operational, so requiring 8MB for installation
> is normal.  The "normal" loader can still have its heap
> pool in real-mode 1MB, but the "install" loader would
> benefit from using say 900K for bzip2 plus the current heap
> of 512K, at the top of available memory.  Just like we
> "load" kernel and other modules there, we could modify heap
> routines to operate in upper memory, no?  Is this handled
> by the i386_copy{in,out} stuff in sys/boot/i386/libi386?

If you want more low memory available, you have to sacrifice
high memory, which means sacrificing size for minimal install
and run.  This doesn't mean 8M, this more likely means 12M, or
more:

	N = low_mem_for_loader + minimum_required_kernel_mem

The only real alternative to this is not an alternative: make
all the code in the kernel PIC, so that it can be relocated
anywhere, and isn't linked against a specific base address.
It's not an alternative because the toolchain (apparently)
still has problems statically linking PIC objects.


> > I guess the real reason for your questions is that bzip2
> > requires some outrageous amount of memory for some internal
> > tables?  Does bzip2 really buy us that much more space than
> > gzip in this case?
>
> Here are the 5.0-R numbers, from kern.flp and mfsroot.flp:
> 
> -r-xr-xr-x  1 root  wheel  1310896 Jan 17 00:45 kernel.gz
> -r-xr-xr-x  1 root  wheel  1247884 Apr 26 14:00 kernel.bz2
> -rw-r--r--  1 root  wheel  1407218 Jan 17 00:39 mfsroot.gz
> -rw-r--r--  1 root  wheel  1358835 Apr 26 14:01 mfsroot.bz2
> 
> That is, saves us 50-60K of space on 1.44MB floppies.

I'm guessing that it doesn't really, and what you are
pointing to here is bzip2 results that are based on
more than -1 (i.e. you are assuming that the memory limits
aren't being enforced on bzip2 by the loader), right?

What are the numbers when -1 is used instead?

-- Terry