Subject: Re: Still can't alloc physical memory in cpu_setup().
To: Alexander Funcke <funcke@daemon.se>
From: Gregory McGarry <g.mcgarry@ieee.org>
List: tech-kern
Date: 05/08/2002 08:55:22
Alexander Funcke wrote:

> > > I'm now running NetBSD-current and want to add support for National's
> > > Geode SCx200 family. One of the features on the chip is an scratchpad
> > > RAM area.
> > > 
> > > The physical address is at gx_base and the area is GX_BASE_SIZE bytes.
> > > This code is executed from cpu_setup() in arch/i386/i386/machdep.c
> > > for the particular CPU.
> > > 
> > > Running this code tell me kernel_map equals NULL, so I guess uvm_init()
> > > hasn't taken place? even though I believed it had...
> > 
> > init386() is called before main().  cpu_startup() is called from main()
> > after uvm_init() though.
> 
> That was what I thought too, but shouldn't kernel_map be something different
> then NULL after uvm_init(), well I guess not, but it was something I read
> in the mailing-list archinve.

Do you mean cpu_setup() or cpu_startup()?  Your "cpu_setup()" will
be invoked before uvm_init().

kernel_map won't be NULL after uvm_init().

> I don't know if scratchpad ram is a known term, but it wasn't for me, so
> maybe it isn't, anyways... it is a part of the L1 cache (2, 3 or 4kb) that
> can be used as really fast memory in programs especially built to fit the
> CPU.

ISTM your intended application is special and the code won't be
fed back to NetBSD.  I say dump it all in cpu_startup().  It will
"just work".

	-- Gregory McGarry <g.mcgarry@ieee.org>