GIRISH V. GULAWANI girishvg@yahoo.com sez;

> ((i know there's an idea of fooling around with dummy or wired tlb entry))

Having hardwired TLB to map at high range of KSEG2 (sometimes called
KSEG3) is very standard practice.

PLS note that MIPS kernel does not require KSEG2 address to run.
TEXT+DATA resides KSEG0 range.  KSEG2 is consumed a little by
"dymanic objects", that is, malloced fragments of memory which is
managed by TLB at run time.

512MB range of KSEG0/KSEG1 should be recognized "conventional
window" through which code can read/write memory and device registers.
This does not mean that it's impossible to have 512MB+ memory.
The issue is in convetional direct access by assuming it makes sense
to convert paddr <> KSEG1(paddr) <> KSEG1(paddr)  at any time.
NetBSD has well designed framework to distinguish vaddr access
and device paddr.   Other architectures which require to have MMU
mapping for TEXT+DATA to run carefully ultilize the framework.
Regretfully NetBSD/mips is premature regarding at the point.

There are possible solutions;

1) populte hardware registers at somewhere beyond 512MB paddr
and map them at KSEG3 with uncached access propertiy.
====> 512MB memory limit cannot be lifted.

2) kernel size is not expected to grow beyond few hundred MB.
Then populate hardware registers at *lower end* of paddr.  Memory
starts somewhere the middle under 512MB and steps across the
boarder.
====> memory must not be handled in KSEG0(paddr) way.  Instead
map it at an intermediate vaddr (somewhere in KSEG3) to change the
contents.  Our pmap.c is the worst practice.

3) The previous layout is obscure at best.  It should be just ok to have
512MB+ continuous memory from paddr 0 while hardware registers
is well beyond maximum memory limit w/ the KSEG3 arrangement
with a *supersized* TLB entry.
=====> no cheat, no trick.  It can be done.

Toru Nishimura/ALKYL Technology