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