AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070925164841.11ab7f7d@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	BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 25 Sep 2007 16:51:50 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: CF accesses in PROM
Message-ID: <20070925165150.59e1b88c@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@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

You see?  You have to use the original email title if you want me to
remember it.  I only hash these things by title in my brain, there
isn't room to hash the contents as well.  That's the limits of a
walnut-sized brain.

On Sun, 23 Sep 2007 11:15:55 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Just wanted to let you know that we now have CF accesses working in
> PROM. This confirms that the hardware path to and from flash is ok and
> also incorporates all the address changes we had to make to support
> the CF from a SiByte.
>  
> We tried getting the CF to be configured as memory instead of i/o, but
> we hit some roadblocks with this.  For now, we are supporting the same
> scheme that we've used before on Bobcat when accessing CF, which is a
> mixture of i/o and memory accesses.  Here's the address map that we're
> using on PCI in PROM:
>  
>  
> Physical Address	 Size	 Function	 Notes	
> 0000.0400	 256	 CF Controller I/O socket A
> Accessed at base of 0xdc000000; set in ExCA i/o 0

uh, right off the bat we aren't communicating.  this thing is located
at phys 0x400???  i'm guessing that what you meant is some kind of
offset here?  this sounds like the register offset.
	
> 0000.0800	 256	 CF Controller I/O socket B
> Accessed at base of 0xdc000000; set in ExCA i/o 0

ditto of course
	
> 0001.0000	 64KB	 CF Controller I/O ExCA
> Accessed at base of 0xdc000000; uses base/index scheme

double ditto.  this one i remember from boobcat days.

> 0080.0000	 64KB	 CF Controller Memory	 Socket
> memory accesses (set in ExCA memory 0); accessed at base of
> 0xf8.0000.0000

whoa nellie, 0xf8.0000.0000?  we have 40 bit physical
addresses?  did you mean 0xf800.0000?

> 0081.0000	 64KB	 CF Controller Socket
> A / ExCA base	 Socket A memory accesses; ExCA mapped at 0x800
> offset; accessed at base of 0xf8.0000.0000

ditto on the nellie

> 0082.0000	 64KB	 CF Controller Socket B / ExCA
> base	 Socket B memory accesses; ExCA mapped at 0x800 offset;
> accessed at base of 0xf8.0000.0000	

> 1a00.0000	 16MB	 TXRX Shared Memory	 TXRX
> accesses this locally at 0x9000.0000	

i'm with ya here.

> 1b00.0000	 16MB	 FP Shared Memory	 FP accesses
> this locally at 0x9000.0000	

ok...

> 1f40.0000	 64KB	 BM FPGA	  	

hokee-dokee

> 6000.0000	 16MB	 SSC Shared Memory	 SSC accesses
> this locally at 0x8300.0000	

0x8300.0000?  you may have pasted the wrong number in here:

0x8000.0000 physical is 2nd 256MB of local mem.
0xffff.ffff.8000.0000 virtual is start of 1st 256MB of local mem


>  
>  
> Andy, let Linux take over and do whatever it likes.  We know that
> accesses to all the above paths work. 
>  
>  
> Brian
>  
