linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: David Jander <david.jander@protonic.nl>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Memory map with "holes"...
Date: Tue, 12 Aug 2003 17:41:44 +0200	[thread overview]
Message-ID: <20030812154149.40702C59E4@atlas.denx.de> (raw)
In-Reply-To: Your message of "Tue, 12 Aug 2003 17:00:11 +0200." <200308121700.11708.david.jander@protonic.nl>


In message <200308121700.11708.david.jander@protonic.nl> you wrote:
>
> I wanted to connect the bank select lines BA0 and BA1 of the SDRAM
> chips to A6 and A5 respectively, and use only one CS (Chip-Select).

Arghhhh... don't do that.

> What I pretend to do is something like this:
> Memory mapped on CS0:
> Region                  What
> --------------------------------
> 0x00000000-0x007fffff   RAM
> 0x00800000-0x01ffffff   invalid
> 0x02000000-0x027fffff   RAM
> 0x02800000-0x03ffffff   invalid
> 0x04000000-0x047fffff   RAM
> 0x04800000-0x05ffffff   invalid
> 0x06000000-0x067fffff   RAM

You will not get lucky with such a design, for several reasons.

CS0 is the boot device. RAM will not work on CS0.

Second, you make your design unecessarily  complicated.  Attach  each
bank  of  RAM  to  nother CS, and let the memory controller map it as
needed.

> marked as "invalid" to be, well, invalid. With a MMU this should not
> matter, only the kernel must know what to do.
>
> For example I found in /arch/ppc/init.c, in the function
> set_phys_avail(), this piece of code:
>
> phys_avail.regions[0].address = PPC_MEMSTART; regions[0].size =
> phys_avail.total_memory; n_regions = 1;
>
> This looks fairly easy to modify, but I wonder why nobody seems to use
> more than one region in linux-ppc??

Why make a design more complicated than necessary?

> What's the policy? To not use this?
> Am I the only one who wants something like this?

>From what I've seen so far: yes. All boards I've seen allowed to  map
the system RAM as one contiguous area.

> Should I start implementing this myself on u-boot and linux-ppc ('cause I

Note that U-Boot does not use the MMU.

> should I better restrict my design to contiguous blocks of RAM only
> (this would make me waste 4 CS lines, and unnecessarily complex
> hardware)?

I would prefer such a design, but hey, I'm a software  developer  and
I'm  supposed  to  bring  up  requirements  that  make  life  it more
difficult to the hardware guys :-)

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It is easier to port a shell than a shell script."      - Larry Wall

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2003-08-12 15:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-12 12:32 Memory map with "holes" David Jander
2003-08-12 14:13 ` Wolfgang Denk
2003-08-12 15:00   ` David Jander
2003-08-12 15:41     ` Wolfgang Denk [this message]
     [not found] ` <3F391DA1.4040202@esteem.com>
2003-08-13  8:36   ` Memory map with "holes"... (slightly off-topic) David Jander
2002-02-15  7:31     ` Shall I use which IRQ as input parameter of this function? John Zhou
2003-08-13 17:01     ` Memory map with "holes"... (slightly off-topic) Conn Clark
  -- strict thread matches above, loose matches on Subject: below --
2003-08-12 19:36 Memory map with "holes" Conn Clark

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=20030812154149.40702C59E4@atlas.denx.de \
    --to=wd@denx.de \
    --cc=david.jander@protonic.nl \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).