AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070314181155.15df5ee6@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.stark@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E02D8F79F@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Mar 2007 18:12:19 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: memory map madness
Message-ID: <20070314181219.0c1d8913@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02D8F79F@onstor-exch02.onstor.net>
References: <20070314131829.514b95c7@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E02D8F746@onstor-exch02.onstor.net>
	<20070314173541.0d9e29f6@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E02D8F79F@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 14 Mar 2007 17:47:28 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> That's right, we aren't using the same physical address for local
> memory right now.  And the spaces you noted for the 512MB of local
> memory are correct.  Sorry that the 256MB regions aren't contiguous.
> Blame the PMC mapping registers for this.

Yeah, I get this part, lately.  It doesn't matter to me or the Linux
kernel if it's contiguous, especially since each chunk is going to a
different core.  Of course, if it was all in kseg0 that would save
having to use the TLB a little bit but who cares.

> In an attempt to clear any confusion, let me address one of the
> questions in your previous email.  From the point of view of the PMC,
> SysAD and local memory are considered peripherals.  The CPU cores
> access these peripherals with a virtual address that is then
> converted to a physical address.  This physical address is then
> mapped by internal registers to one of these peripherals, and it
> could then be remapped to a different physical address.  This is
> often done to meet addressing requirements of one of the chips
> attached to the same bus (e.g. Marvell).

mapped by internal registers to one of these peripherals ... what
internal registers are these?  I don't know of any magical internal
registers in the RM9K that can deduce via mental telepathy which
peripheral you meant when you issued an address that mapped to
4000.0000 v. another address that maps to the same physical address.
Unless I'm missing something, like an uncached TLB mapping that
resolves to physical address 4000.0000 somehow goes somewhere different
from a cached TLB mapping that also resolves to physical 4000.0000.
I hurt my brain just thinking that up.

> So, while you're correct that the CPU cores can't deal with
> peripherals at the same physical address, it has no notion of the
> remapping that can happen.  This remapping can result in two
> peripherals having the same physical address from an overall system
> perspective, but since the peripherals are isolated from each other
> by the internal remappers, this doesn't matter.  From the perspective
> of the CPU cores, these peripherals must live at different virtual
> and physical addresses (which they do).

Where are these internal remappers?  I think I'm more confused now than
before, if possible.

> Hope I didn't confuse you any more.  If I did, then just read the
> first paragraph in this reply again since we aren't using that upper
> 512MB of space anyway!

Okay.  I'll do a tlb_flush and reread the first paragraph.

> 
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Wednesday, March 14, 2007 5:36 PM
> > To: Brian Stark
> > Subject: Re: memory map madness
> > 
> > On Wed, 14 Mar 2007 16:38:42 -0700 "Brian Stark"
> > <brian.stark@onstor.com> wrote:
> > 
> > > Andy,
> > 
> > > I see your confusion about how there appears to be a 
> > physical address 
> > > conflict between the Marvell and local memory.  Keep in mind that 
> > > after all of the address translation and remapping stages 
> > inside the 
> > > PMC, it's possible that different peripherals, such as 
> > SysAD and local 
> > > memory, actually show the same physical address.  Since these 
> > > peripherals are isolated from each other, this is ok.  
> > Plus, we don't 
> > > actually use the virtual regions at 20000000 and 30000000 as
> > > noted above.
> > 
> > Nevermind that previous reply of mine, I was still suffering 
> > some confusion.  Basically, I take it that we aren't using 
> > the phys 4000.0000 address for local memory right now, we are 
> > using phys 0 thru (1000.0000 - 1) and 2000.0000 thru 
> > (3000.0000 - 1) for local memory, right?
> > 
> > Cheers,
> > 
> > a
> > 
> > > Brian
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Andy Sharp
> > > > Sent: Wednesday, March 14, 2007 1:18 PM
> > > > To: Brian Stark
> > > > Subject: memory map madness
> > > > 
> > > > Hi Brian,
> > > > 
> > > > I'm apparently having trouble reading the memory map pdf's.
> > > > 
> > > > Bobcat\ Memory\ Map\ 3.pdf lists two different things at phys
> > > > 0x4000.000: 256MB of local memory, and 256MB of Marvell memory.
> > > > 
> > > > 
> > > > Bobcat\ Memory\ Map.pdf lists the marvell memory as starting at 
> > > > 0x5000.0000
> > > > 
> > > > What's the real and true story of the memory map?
> > > > 
> > > > Cheers,
> > > > 
> > > > a
> > > > 
> > 
