Question about memory mapping in ARM processor based SoC

Hello,

I am working on embedded application development for ARM926EJ
processor based SoC.
As per my product specification, there are 2 SDRAM memory banks which
can address 128 MB SDRAM each.
So the there could be overall 256MB SDRAM in the system.

The board that I have has 128 MB of SDRAM as per the specification.
So I suppose there is only one memory bank used with 128 MB memory.

I have written following sample code to run on this system:

int main (void)
{
     int *pv = (int *) 0x03FFFFF0;

     for (int i=0; i<16; i++)
     {
         *pv = i;
          pv++;
     }
}

I am loading the binary code at 0x0 location in the RAM and executing
it.

The loop in above code works fine till it writes in the memory
location 0x03FFFFFF.
But when the loop starts writes at address 0x04000000 (64 MB memory
location), it starts writing at location 0x0, and the code of my
application is overwritten.

My question is: is it possible that the memory location above 64MB is
again mapped to location 0?
If this is true, how is it possible? and how can I solve this
problem?

Is it possible that there is 64 MB RAM in bank 0 and another 64 MB
memory in bank 1?
If yes, then how can I access the RAM in bank 1?

Please have a look at this problem. If you need any more information,
I would like to give it.

Thanks in advance.

On Feb 17, 5:27 am, "Bhavik" <bhavik.pa...@gmail.com> wrote:

> I am working on embedded application development for ARM926EJ
> processor based SoC.
> As per my product specification, there are 2 SDRAM memory banks which
> can address 128 MB SDRAM each.
> So the there could be overall 256MB SDRAM in the system.
>
> The board that I have has 128 MB of SDRAM as per the specification.
> So I suppose there is only one memory bank used with 128 MB memory.
>
> ... snip ...
>
> The loop in above code works fine till it writes in the memory
> location 0x03FFFFFF.
> But when the loop starts writes at address 0x04000000 (64 MB memory
> location), it starts writing at location 0x0, and the code of my
> application is overwritten.
>
> My question is: is it possible that the memory location above 64MB is
> again mapped to location 0?
> If this is true, how is it possible? and how can I solve this
> problem?
>
> Is it possible that there is 64 MB RAM in bank 0 and another 64 MB
> memory in bank 1?
> If yes, then how can I access the RAM in bank 1?
>
> Please have a look at this problem. If you need any more information,
> I would like to give it.

It appears that your board has 2 banks of 64MB each. Do you have a
datasheet/user guide of the board, explaining the memory map ? The
second bank may be addressed at 08000000, or perhaps even higher. Once
you know where the 2nd bank starts, you can use the ARM926 MMU to map
it at another virtual address.

Hi Thanks for the reply.

It seems you are right. The memory map is as following:

0x0 - 0x7FF FFFF: SDRAM chip select 0
0x800 0000 - 0xFFF FFFF: SDRAM chip select 1

And my board has 64 MB RAM mapped from 0x0 to 0x400 0000 in bank 0.
And another 64 MB RAM is mapped from 0x800 0000 to 0xB00 0000 in bank
1.

The remaining address space in both banks do not map to any memory.

So how can I use ARM926 MMU to map the 64 MB RAM in second bank to
locations in bank 0 after 64 MB, so that I can virtually have
contiguous 128 MB of memory.

Can you please point out some sample code?

Thanks again.

>
> It appears that your board has 2 banks of 64MB each. Do you have a
> datasheet/user guide of the board, explaining the memory map ? The
> second bank may be addressed at 08000000, or perhaps even higher. Once
> you know where the 2nd bank starts, you can use the ARM926 MMU to map
> it at another virtual address.

"Bhavik" <bhavik.patel@gmail.com> wrote in message 
news:1171881330.210115.75720@h3g2000cwc.googlegroups.com...
> Hi Thanks for the reply.
>
>>
>> It appears that your board has 2 banks of 64MB each. Do you have a
>> datasheet/user guide of the board, explaining the memory map ? The
>> second bank may be addressed at 08000000, or perhaps even higher. Once
>> you know where the 2nd bank starts, you can use the ARM926 MMU to map
>> it at another virtual address.
> It seems you are right. The memory map is as following:
>
> 0x0 - 0x7FF FFFF: SDRAM chip select 0
> 0x800 0000 - 0xFFF FFFF: SDRAM chip select 1
>
> And my board has 64 MB RAM mapped from 0x0 to 0x400 0000 in bank 0.
> And another 64 MB RAM is mapped from 0x800 0000 to 0xB00 0000 in bank
> 1.
>
> The remaining address space in both banks do not map to any memory.
>
> So how can I use ARM926 MMU to map the 64 MB RAM in second bank to
> locations in bank 0 after 64 MB, so that I can virtually have
> contiguous 128 MB of memory.
>
> Can you please point out some sample code?

Top posting fixed (but missing attribution).

Even without an MMU you can make the memory contiguous by treating first 
block as 0x0400 0000 - 0x07FF FFFF and the second block as 0x0800 0000 - 
0x0BFF FFFF. This presumes that a 64MB memory appears twice in th CS.

Peter 

Bhavik <bhavik.patel@gmail.com> wrote:
> Hi Thanks for the reply.
> 
> It seems you are right. The memory map is as following:
> 
> 0x0 - 0x7FF FFFF: SDRAM chip select 0
> 0x800 0000 - 0xFFF FFFF: SDRAM chip select 1
> 
> And my board has 64 MB RAM mapped from 0x0 to 0x400 0000 in bank 0.
> And another 64 MB RAM is mapped from 0x800 0000 to 0xB00 0000 in bank
> 1.
> 
> The remaining address space in both banks do not map to any memory.
> 
> So how can I use ARM926 MMU to map the 64 MB RAM in second bank to
> locations in bank 0 after 64 MB, so that I can virtually have
> contiguous 128 MB of memory.

Instead of fiddling with the MMU, you could also use the top mirror of
bank 0 together with bank 1 as one contiguous area.

-- 
:wq
^X^Cy^K^X^C^C^C^C

On Feb 19, 11:43 am, "Peter Dickerson"
<firstname.lastn...@REMOVE.tesco.net> wrote:
> "Bhavik" <bhavik.pa...@gmail.com> wrote in message
>
> news:1171881330.210115.75720@h3g2000cwc.googlegroups.com...
>
>
>
> > Hi Thanks for the reply.
>
> >> It appears that your board has 2 banks of 64MB each. Do you have a
> >> datasheet/user guide of the board, explaining the memory map ? The
> >> second bank may be addressed at 08000000, or perhaps even higher. Once
> >> you know where the 2nd bank starts, you can use the ARM926 MMU to map
> >> it at another virtual address.
> > It seems you are right. The memory map is as following:
>
> > 0x0 - 0x7FF FFFF: SDRAM chip select 0
> > 0x800 0000 - 0xFFF FFFF: SDRAM chip select 1
>
> > And my board has 64 MB RAM mapped from 0x0 to 0x400 0000 in bank 0.
> > And another 64 MB RAM is mapped from 0x800 0000 to 0xB00 0000 in bank
> > 1.
>
> > The remaining address space in both banks do not map to any memory.
>
> > So how can I use ARM926 MMU to map the 64 MB RAM in second bank to
> > locations in bank 0 after 64 MB, so that I can virtually have
> > contiguous 128 MB of memory.
>
> > Can you please point out some sample code?
>
> Top posting fixed (but missing attribution).
>
> Even without an MMU you can make the memory contiguous by treating first
> block as 0x0400 0000 - 0x07FF FFFF and the second block as 0x0800 0000 -
> 0x0BFF FFFF. This presumes that a 64MB memory appears twice in th CS.

Good suggestion. However, presumably OP wants to enable the ARM926 D-
cache on the SDRAM at some point in time, and this also requires
enabling the MMU, so he may as well use the MMU to fix the memory
hole.

The easiest way to enable MMU is to use an OS that comes with MMU
support.

If you want to build your own, check out the ARM926 reference manual:
http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf . Chapter 3 describes the
MMU. To get started quickly, just build a page table with 4096
"section" entries. Each section entry maps 1MB of memory. Place this
table somewhere in memory.

After you've build the page table (check alignment), you could run
something like the following code to enable it (r0 points to page
table). See chapter 2 for a description of all the CP 15 registers.

; drain write buffer
        mov     r1, #0
        mcr     p15, 0, r1, c7, c10, 4

; flush TLB's
        mcr     p15, 0, r1, c8, c7, 0

; load translation table base register
        mcr     p15, 0, r0, c2, c0, 0

; load default domain access control
        mov     r0, #0xffffffff
        mcr     p15, 0, r0, c3, c0, 0

; set I-cache / D-cache bits, enable MMU
        mrc     p15, 0, r0, c1, c0, 0
        orr     r0, r0, #0x5000
        orr     r0, r0, #0x007d
        mcr     p15, 0, r0, c1, c0, 0

Bhavik wrote:
> 
> It seems you are right. The memory map is as following:
> 
> 0x0 - 0x7FF FFFF: SDRAM chip select 0
> 0x800 0000 - 0xFFF FFFF: SDRAM chip select 1
... snip ...

Please do not top-post, and do not snip attributions for quoted
material.  Your answer belongs after, or intermixed with, the
material you quote, after snipping anything immaterial to your
reply.  The attributions are the initial lines that say "joe
wrote:".  See the following links:

-- 
Some informative links:
  <http://www.catb.org/~esr/faqs/smart-questions.html>
  <http://www.caliburn.nl/topposting.html>
  <http://www.netmeister.org/news/learn2quote.html>
  <http://cfaj.freeshell.org/google/>  (taming google)
  <http://members.fortunecity.com/nnqweb/>  (newusers)

On Feb 19, 4:23 pm, "Arlet" <usene...@c-scape.nl> wrote:
> On Feb 19, 11:43 am, "Peter Dickerson"
>
>
>
> <firstname.lastn...@REMOVE.tesco.net> wrote:
> > "Bhavik" <bhavik.pa...@gmail.com> wrote in message
>
> >news:1171881330.210115.75720@h3g2000cwc.googlegroups.com...
>
> > > Hi Thanks for the reply.
>
> > >> It appears that your board has 2 banks of 64MB each. Do you have a
> > >> datasheet/user guide of the board, explaining the memory map ? The
> > >> second bank may be addressed at 08000000, or perhaps even higher. Once
> > >> you know where the 2nd bank starts, you can use the ARM926 MMU to map
> > >> it at another virtual address.
> > > It seems you are right. The memory map is as following:
>
> > > 0x0 - 0x7FF FFFF: SDRAM chip select 0
> > > 0x800 0000 - 0xFFF FFFF: SDRAM chip select 1
>
> > > And my board has 64 MB RAM mapped from 0x0 to 0x400 0000 in bank 0.
> > > And another 64 MB RAM is mapped from 0x800 0000 to 0xB00 0000 in bank
> > > 1.
>
> > > The remaining address space in both banks do not map to any memory.
>
> > > So how can I use ARM926 MMU to map the 64 MB RAM in second bank to
> > > locations in bank 0 after 64 MB, so that I can virtually have
> > > contiguous 128 MB of memory.
>
> > > Can you please point out some sample code?
>
> > Top posting fixed (but missing attribution).
>
> > Even without an MMU you can make the memory contiguous by treating first
> > block as 0x0400 0000 - 0x07FF FFFF and the second block as 0x0800 0000 -
> > 0x0BFF FFFF. This presumes that a 64MB memory appears twice in th CS.
>
> Good suggestion. However, presumably OP wants to enable the ARM926 D-
> cache on the SDRAM at some point in time, and this also requires
> enabling the MMU, so he may as well use the MMU to fix the memory
> hole.
>
> The easiest way to enable MMU is to use an OS that comes with MMU
> support.
>
> If you want to build your own, check out the ARM926 reference manual:http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf. Chapter 3 describes the
> MMU. To get started quickly, just build a page table with 4096
> "section" entries. Each section entry maps 1MB of memory. Place this
> table somewhere in memory.
>
> After you've build the page table (check alignment), you could run
> something like the following code to enable it (r0 points to page
> table). See chapter 2 for a description of all the CP 15 registers.
>
> ; drain write buffer
>         mov     r1, #0
>         mcr     p15, 0, r1, c7, c10, 4
>
> ; flush TLB's
>         mcr     p15, 0, r1, c8, c7, 0
>
> ; load translation table base register
>         mcr     p15, 0, r0, c2, c0, 0
>
> ; load default domain access control
>         mov     r0, #0xffffffff
>         mcr     p15, 0, r0, c3, c0, 0
>
> ; set I-cache / D-cache bits, enable MMU
>         mrc     p15, 0, r0, c1, c0, 0
>         orr     r0, r0, #0x5000
>         orr     r0, r0, #0x007d
>         mcr     p15, 0, r0, c1, c0, 0

Thanks all for your answers. I now understand the way to overcome the
problem with hole in memory.
But I don't know why these holes are kept in the memory.

For example, in my system the address range 0x0 - 0x03FFFFFF is mapped
to actual 64MB physical memory in bank 0.
And the address range 0x04000000 -  0x07FFFFFF is actually mirrored
from 0x0 - 0x03FFFFFF.

The same kind of thing happens in another 64 MB memory in bank 1.
The adress range 0x08000000 - 0x0BFFFFFF is mapped to actual 64 MB
physical memory.
And the address range 0x0C000000 - 0x0FFFFFFF i mirrored from
0x08000000 - 0x0BFFFFFF.

I don't know why the memory system is designed this way.
Isn't it possible to have the whole 128 MB in either bank0 or bank1?

Thanks once again.

On Feb 20, 8:10 am, "Bhavik" <bhavik.pa...@gmail.com> wrote:

> Thanks all for your answers. I now understand the way to overcome the
> problem with hole in memory. But I don't know why these holes are kept
> in the memory.
>
> For example, in my system the address range 0x0 - 0x03FFFFFF is mapped
> to actual 64MB physical memory in bank 0. And the address range
> 0x04000000 -  0x07FFFFFF is actually mirrored from 0x0 - 0x03FFFFFF.

The 'mirroring' (or 'aliasing' as it is commonly called), is just
logical result when the top address lines are not connected, such as
when you use a smaller device.

> I don't know why the memory system is designed this way. Isn't it possible
> to have the whole 128 MB in either bank0 or bank1?

Sure, but if you want to design a system that supports two memory
chips, it is easier to use memory bank with fixed sizes. Naturally,
the memory bank needs to be large enough to accommodate the biggest
physical device that's supported, so when you install a smaller
device, you'll see the aliasing effects.

Since your device already has an MMU, and can handle these memory
holes without any performance loss, there was no need for the IC
designer to insert extra logic to make the memory mapping
configurable.