Subject: Re: Still can't alloc physical memory in cpu_setup().
To: Alexander Funcke <email@example.com>
From: Gregory McGarry <firstname.lastname@example.org>
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
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
-- Gregory McGarry <email@example.com>