AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070926093444.4a4c6a50@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:#mh/Mailbox/sent	0	20070925165150.59e1b88c@ripper.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 26 Sep 2007 09:39:41 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: CF accesses in PROM
Message-ID: <20070926093941.5f93e1d5@ripper.onstor.net>
In-Reply-To: <20070925165150.59e1b88c@ripper.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@onstor-exch02.onstor.net>
	<20070925165150.59e1b88c@ripper.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 Tue, 25 Sep 2007 16:51:50 -0700 Andrew Sharp <andy.sharp@onstor.com>
wrote:

> 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.

OK, I get it now.  0xdc00.0000 is the phys and 400 is the offset from
there.  Check.

> > 0000.0800	 256	 CF Controller I/O socket B
> > Accessed at base of 0xdc000000; set in ExCA i/o 0
> 
> ditto of course

ditto

> > 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?

The code I'm looking at has mem_resource starting at physical
0x4000.0000, which I don't quite get, because it also defines these:

#define A_PHYS_LDTPCI_IO_MATCH_BYTES_32 (0x0040000000)
#define A_PHYS_LDTPCI_IO_MATCH_BITS_32  (0x0060000000)

#define A_PHYS_LDT_SPECIAL_MATCH_BYTES  (0x00D8000000)
#define A_PHYS_LDTPCI_IO_MATCH_BYTES    (0x00DC000000)
#define A_PHYS_LDTPCI_CFG_MATCH_BYTES   (0x00DE000000)
#define A_PHYS_LDT_SPECIAL_MATCH_BITS   (0x00F8000000)
#define A_PHYS_LDTPCI_IO_MATCH_BITS     (0x00FC000000)
#define A_PHYS_LDTPCI_CFG_MATCH_BITS    (0x00FE000000)

#define A_PHYS_PCI_FULLACCESS_BYTES     (0xF000000000)
#define A_PHYS_PCI_FULLACCESS_BITS      (0xF100000000)
#define A_PHYS_RESERVED                 (0xF200000000)
#define A_PHYS_RESERVED_SPECIAL_LDT     (0xFD00000000)

but no f8.0000.0000 ... except that it's inside A_PHYS_RESERVED

> > 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
> >  
