Jun Sun wrote:
> Daniel Jacobowitz wrote:
>
> > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote:
> >
> >>So... I'm looking at porting Linux to a system with 1.5GiB of RAM.
> >>That kinda blows the 32-bit MIPS port option right out of the water...
> >>
> >
> > Not unless you count bits differently than I do... 32-bit is 4 GiB. Is
> > there any reason MIPS has special problems in this area?
> >
>
>
> MIPS has lower 2GB fixed for user space. Then you have kseg0, .5GB for cached
> physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping of the same area.
> You can map another 1GB of RAM into kseg2/3, but you will then have no space
> left for IO.
>
> So you really can't do 1.5GB on 32 bit kernel.
Is this to say that Linux cannot function unless all physical memory
on the system is mapped at all times into kernel space? I would
have thought that (a) all that really needs to be mapped is all
memory used by the kernel itself, plus that of the currently active
process (which is mapped in the 2GB kuseg), and that (b) one
could anyway manage kseg2 or 3 dynamically to provide a window
into a larger physical memory, and that this window could be
used for any functions that need to do arbitrary phys-to-phys
copies.
I'm not sure what people's definition of a "64-bit kernel"
is around here, but to me, that's a kernel which supports
64-bit virtual addressing and 64-bit registers. It strikes
me as being rather foolish to impose the overhead of all
that on people whose only real requirement is 2G of RAM
on a 32-bit CPU. Particularly when many of the new
MIPS parts that could plausibly be connected to 2GB
RAM arrays, such as the Alchemy/AMD and MIPS 4K
parts, don't support 64-bit operation. So running away
from the problem isn't really an option.
Regards,
Kevin K.
