[Top] [All Lists]

Re: smp8634 add memory at dram1

To: David Kuk <>
Subject: Re: smp8634 add memory at dram1
From: Ralf Baechle <>
Date: Wed, 14 Nov 2007 11:04:26 +0000
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.14 (2007-02-12)
On Wed, Nov 14, 2007 at 04:44:27PM +0800, David Kuk wrote:

> After study about the memory configuration of sigma smp8634, i found 
> some difficult to accomplish the task.
> so my question is if have two 128MB ram separately under dram0 and dram1 
> controller, where dram0 for linux and dram1 for video decoding. Now the 
> situation is the memory for linux is not enough and video decoding can 
> not use all of it's 128MB at dram1, what we plan to do is to share 64MB 
> at dram1 to the linux kernel as high memory, and only reserved 64MB at 
> dram1 for the video decoding.
> first, in MIPS architecture, we found that the kseg0 and kseg1 are 
> mapped to 0x00000000-0x20000000, which include only dram0 controller, so 
> we wish to add the dram1 memory manually to the kernel using function 
> add_memory_region at setup.c , after booting up result the warning that 
> the memory larger than 512 need to configured the kernel support high 
> memory.
> then when we configure the kernel to support high memory at menu 
> configure, the kernel when booting up will remind us our CPU do not 
> support high memory due to cache aliases.

This is really a software restriction.  I originally developped highmem for
MIPS on a Sibyte SB1250 which doesn't suffer from aliases so I didn't even
attempt to solve the cache aliasing issue.  The other platforms on whic
highmem used to be used was the E9000 family but it seem by now the users
of these platforms have all moved to full 64-bit kernels, so aside fo the
implementation restrictions has also started to bitrot a little.

What would be necessary to get it to work is to flush the page from cache at
kunmap() rsp.  kunmap_atomic() time.  That should do the trick though there
are significant further optimizations possible.

An alterantive to solve the aliasing issue would be to increase the
page size to 16K.  Again, the combination of highmem and 16K pages is

I don't know what processor core Sigma is using in this SOC.  In case its a
64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
kernel, it's much less painful than highmem.


<Prev in Thread] Current Thread [Next in Thread>