All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] How to Handel Non-Continuous Memory Regions
Date: Fri, 25 Jul 2008 07:40:35 -0400	[thread overview]
Message-ID: <4889BBB3.2060709@ge.com> (raw)
In-Reply-To: <c13b1cfc0807250354k50394033lf0f46f678fc1872@mail.gmail.com>

Stuart Wood wrote:
> Wolfgamg
> 
> 
>> What has the MMU to do with it?
>>
>> Just program your memory controller such that the 4 banks form a
>> contiguous region.
> 
> The memory controller unfortunatly can  not map the SDRAM banks as
> contiguous region. That IS the main problem. For the SDRAM I'm using
> It ends up giving me region sizes of 8MBytes.
> 
> U-Boot runs in the first region, and we down load into the second region.
> If the down load is larger than the region size it gets corrupted.

IOW, your hardware sucks.  Not the first time *that* has happened.

> So the thought is to enable the MMU to do the address translation.
> Or is there another way to handle this?

No.

Wait, there is half a way.  If your SDRAM banks are not fully decoded 
(and they most likely are *not*), if you use the address last "copy" of 
the first bank and the first "copy" of the second bank, you will have 
two bank's worth of contiguous memory.

> It appears to happen when the image size becomes larger then a bank of
>> SDRAM. I've got a 32 MByte SDRAM
>> that appears as 4 banks of 8 MBytes.
>> 
>> The system is using u-boot 1.1.3 and we will move to 1.3.3 soon.
>> The memory regions are broken up like this.
>> 
>> 0xE0000000 - 0xE07FFFFF
>> 0xE1000000 - 0xE17FFFFF
>> 0xE4000000 - 0xE47FFFFF
>> 0xE5000000 - 0xE57FFFFF

So you should be able to use
   0xE0800000..0xE0FFFFFF - 2nd "copy" of the first bank
   0xE1000000..0xE17FFFFF - 1st "copy" of the second bank
you will double your available consecutive memory.  You can do the same 
thing with the third and fourth banks of memory, but you will still have 
a gap between the first pair and second pair.  This will reduce your 
four fragments / three holes to two fragments / one hole.  Solved half 
your problem anyway.
   0xE4800000..0xE4FFFFFF - 2nd "copy" of the first bank
   0xE5000000..0xE57FFFFF - 1st "copy" of the second bank

HTH,
gvb

  reply	other threads:[~2008-07-25 11:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-24 14:56 [U-Boot-Users] How to Handel Non-Continuous Memory Regions Stuart Wood
2008-07-24 15:50 ` Ricardo
2008-07-24 20:30   ` Stuart Wood
2008-07-24 20:33     ` Ricardo
2008-07-25  4:28     ` Wolfgang Denk
2008-07-25 10:54       ` Stuart Wood
2008-07-25 11:40         ` Jerry Van Baren [this message]
2008-07-25 11:44           ` Jerry Van Baren
2008-07-25 12:23             ` Stuart Wood
2008-07-25  4:28 ` Wolfgang Denk

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=4889BBB3.2060709@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /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.