Subject: Re: Still can't alloc physical memory in cpu_setup().
To: Gregory McGarry <email@example.com>
From: Alexander Funcke <firstname.lastname@example.org>
Date: 05/07/2002 12:13:08
On Tue, May 07, 2002 at 01:51:02PM +1200, Gregory McGarry wrote:
> 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.
> > anyways, I don't have a kernel_map, but I still want to alloc this area,
> > should I just wait until later in the startup or is there away to do this
> > before uvm_init?
> Depends what you want to do with the allocated space. The longer
> you can defer it, the easier it will be.
What I primarly want is to get a pointer initilized till an physical address
in cpu_setup(), apart from that I believed that it'd be a good idea to map this
'scratchpad RAM' in the very same function, but that won't do the trick... (?).
Should I settle for getting the pointer, from whom (+offset) I can map my
scratchpad ram later?
And in that case, when?
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
> -- Gregory McGarry <email@example.com>