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/
next prev parent 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).