[9fans] moving 9load to 0x800000

[9fans] moving 9load to 0x800000

[Ronald G Minnich]

we need it to run at 0x800000. What we've done is simply change the -T in
the ld to 0x80800000. Will this do the trick or are we missing something.

Note also that all code is 32-bit code (#ifdef on the early startup stuff,
no 16-bit code left) so that 16-bit addressing is not an issue.

Anything else we're missing (almost certainly ...)

Re: [9fans] moving 9load to 0x800000

[jmk]

You probably need to change at where load.c/ialloc() starts allocating
(currently 3MB).

On Fri Jan 25 11:20:32 EST 2002, rminnich@lanl.gov wrote:
>
> we need it to run at 0x800000. What we've done is simply change the -T in
> the ld to 0x80800000. Will this do the trick or are we missing something.
>
> Note also that all code is 32-bit code (#ifdef on the early startup stuff,
> no 16-bit code left) so that 16-bit addressing is not an issue.
>
> Anything else we're missing (almost certainly ...)

Re: [9fans] moving 9load to 0x800000

[Ronald G Minnich]

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

Re: [9fans] moving 9load to 0x800000

[Russ Cox]

The only dependency on the base address in the
source code itself is in the copy loop that relocates
9load to half a megabyte.  It sounds like you've done
away with that, so you should be okay.

Russ

Re: [9fans] moving 9load to 0x800000

[jmk]

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