From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] moving 9load to 0x800000
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020125172424.1F6E719A74@mail.cse.psu.edu>
Date: Fri, 25 Jan 2002 12:24:21 -0500
Topicbox-Message-UUID: 45de1eb8-eaca-11e9-9e20-41e7f4b1d025

One of the first things 9load does in main() is
	if((ulong)&end > (KZERO|(640*1024)))
		panic("i'm too big\n");
KZERO is defined as 0x80000000 in mem.h, which should be OK for most
other things. However, mem.h defines where some other datastructures
go in memory, such as the vector table:
	#define IDTADDR		0x80000800		/* idt */

Basically, you want to grep for KZERO and 0x8 in the source to see what
turns up.

On Fri Jan 25 12:13:33 EST 2002, rminnich@lanl.gov wrote:
> On Fri, 25 Jan 2002 jmk@plan9.bell-labs.com wrote:
>
> > You probably need to change at where load.c/ialloc() starts allocating
> > (currently 3MB).
>
> actually that ought to be ok with us.
>
> Here's the problem. We're loading 9load from linuxbios. There is
> significant usage of the area 0x10000 and up by linuxbios, so 9load has to
> live elsewhere. 0x100000 won't do, since that's where the kernel goes.
>
> So I hoped we could put the 9load code at 0x800000. I don't see a problem
> with allocating at 3 MB, that leaves plenty of room for the kernel at 1
> MB.
>
> It ends up like this:
>
> 0-0x90000 linuxbios
> 0x100000-0x2fffff -- plan 9 kernel (when loaded)
> 0x300000          -- 9load allocator
> 0x800000          -- 9load code
>
> Does that sound reasonable? Will the -T switch to ld fix all that needs
> fixing or are there manifest constants somewhere we have to fix up too?
>
> thanks
>
> ron