All of lore.kernel.org
 help / color / mirror / Atom feed
From: 郭劲 <guojin02@tsinghua.org.cn>
To: "Scott Wood" <scottwood@freescale.com>,
	"vijay baskar" <cn.vijaibaskar@gdatech.co.in>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: The question about the high memory support on MPC8360?
Date: Thu, 29 Nov 2007 11:11:50 +0800	[thread overview]
Message-ID: <396305910.05464@tsinghua.org.cn> (raw)

Hi,friends,

   I plug in 2GB DDR-1 in my MPC8360 board,there are two DIMM-184 slots,each
DIMM-184 slot hold 1GB.Could you tell me how to let the linux know about those
2GB?
   In uboot, I set up each DDR CS to visit 512MB, total 4 CS signal. DDR window
range is 2GB. I think the uboot has passed those DDR parameter to linux.
   I once did a test that config the bootargs with mem=512M, then the linux just
only find 512MB, but if I config the mem=2048M, the linux still find about 750MB.
   How to make the linux find the total 2GB memory?
   




>From: Scott Wood <scottwood@freescale.com>
>Reply-To: 
>To: vijay baskar <cn.vijaibaskar@gdatech.co.in>
>Subject: Re: The question about the high memory support on MPC8360?
>Date:Wed, 28 Nov 2007 10:57:38 -0600
>
>vijay baskar wrote:
>> Hi, "The kernel also allows hardcoded mapping of IO regions into its 
>> virtual address space through the io_block_mapping interface."
>> 
>> Can u tell me how this is in current arch/powerpc.
>
>Everything is explicitly ioremapped.
>
>> Also does it mean that whatever be the size of the ram > 768 MB there
>>  is not going to be much improvement in performance in kernel space 
>> irrespective of invoking CONFIG_HIGHMEM or not?
>
>Well, the kernel can use highmem for cache...  I'm not sure what you
>mean by "in kernel space".
>
>> Also do you think this low mem be enough if i have lots of kernel 
>> space processes each invoking lots of kmallocs.
>
>That depends on what you mean by "lots". :-)
>
>You'll have 768MB of lowmem, and kmallocs can only use lowmem.
>
>> Will there be bottle necks?? Also what alternative do we have if  low
>> mem of 768 MB is not enough??
>
>You'll need to change the user/kernel split, and deal with anything that 
>breaks in the process.
>
>Or get a 64-bit chip. :-)
>
>-Scott
> 

             reply	other threads:[~2007-11-29  3:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29  3:11 郭劲 [this message]
2007-11-29  7:29 ` The question about the high memory support on MPC8360? vijay baskar
2007-11-29 12:59   ` robert lazarski
2007-11-29 16:09     ` Dale Farnsworth
2007-11-29 19:41     ` Rune Torgersen
  -- strict thread matches above, loose matches on Subject: below --
2007-11-26  3:58 郭劲
2007-11-26  6:11 ` vijay baskar
2007-11-26 16:57   ` Scott Wood
2007-11-27  4:27     ` vijay baskar
2007-11-27 17:02       ` Scott Wood
2007-11-28  4:02         ` vijay baskar
2007-11-28 16:57           ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=396305910.05464@tsinghua.org.cn \
    --to=guojin02@tsinghua.org.cn \
    --cc=cn.vijaibaskar@gdatech.co.in \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.