X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8005C.FD149F54@onstor-exch02.onstor.net>; Wed, 26 Sep 2007 08:47:56 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: CF accesses in PROM
Date: Wed, 26 Sep 2007 08:47:57 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E05B46E86@onstor-exch02.onstor.net>
In-Reply-To: <20070925165150.59e1b88c@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: CF accesses in PROM
Thread-Index: Acf/zwp8cfW0DJykR/KL3lq6UQJPQwAjPW3Q
References: <BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@onstor-exch02.onstor.net> <20070925165150.59e1b88c@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

Comments below...
=20

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Tuesday, September 25, 2007 4:52 PM
> To: Brian Stark
> Subject: Re: CF accesses in PROM
>=20
> You see?  You have to use the original email title if you=20
> want me to remember it.  I only hash these things by title in=20
> my brain, there isn't room to hash the contents as well. =20
> That's the limits of a walnut-sized brain.
>=20
> On Sun, 23 Sep 2007 11:15:55 -0700 "Brian Stark"
> <brian.stark@onstor.com> wrote:
>=20
> > Just wanted to let you know that we now have CF accesses working in=20
> > PROM. This confirms that the hardware path to and from=20
> flash is ok and=20
> > also incorporates all the address changes we had to make to support=20
> > the CF from a SiByte.
> > =20
> > We tried getting the CF to be configured as memory instead=20
> of i/o, but=20
> > we hit some roadblocks with this.  For now, we are=20
> supporting the same=20
> > scheme that we've used before on Bobcat when accessing CF,=20
> which is a=20
> > mixture of i/o and memory accesses.  Here's the address map=20
> that we're=20
> > using on PCI in PROM:
> > =20
> > =20
> > Physical Address	 Size	 Function	 Notes=09
> > 0000.0400	 256	 CF Controller I/O socket A
> > Accessed at base of 0xdc000000; set in ExCA i/o 0
>=20
> uh, right off the bat we aren't communicating.  this thing is=20
> located at phys 0x400???  i'm guessing that what you meant is=20
> some kind of offset here?  this sounds like the register offset.
> =09


This is the physical address on the PCI bus, not the one the CPU uses to
communicate with it.  As shown in the notes, the CPU gets there with
0xdc000000 + PCI physical address.


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

Same as above.


> =09
> > 0001.0000	 64KB	 CF Controller I/O ExCA
> > Accessed at base of 0xdc000000; uses base/index scheme
>=20
> double ditto.  this one i remember from boobcat days.

Same as above.  You can also use memory-mapped cycles to get to the ExCA
registers.


>=20
> > 0080.0000	 64KB	 CF Controller Memory	 Socket
> > memory accesses (set in ExCA memory 0); accessed at base of=20
> > 0xf8.0000.0000
>=20
> whoa nellie, 0xf8.0000.0000?  we have 40 bit physical=20
> addresses?  did you mean 0xf800.0000?

Yes, we have 40-bit physical addresses, and this is straight out of the
SiByte memory map.  This is one of the ranges we can use to get to PCI
bus via memory-mapped cycles.


>=20
> > 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
>=20
> ditto on the nellie
>=20
> > 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=09
>=20
> > 1a00.0000	 16MB	 TXRX Shared Memory	 TXRX
> > accesses this locally at 0x9000.0000=09
>=20
> i'm with ya here.
>=20
> > 1b00.0000	 16MB	 FP Shared Memory	 FP accesses
> > this locally at 0x9000.0000=09
>=20
> ok...
>=20
> > 1f40.0000	 64KB	 BM FPGA	  =09
>=20
> hokee-dokee

You can change this if you like by programming the BAR at 0x10 in config
space.


>=20
> > 6000.0000	 16MB	 SSC Shared Memory	 SSC accesses
> > this locally at 0x8300.0000=09
>=20
> 0x8300.0000?  you may have pasted the wrong number in here:
>=20
> 0x8000.0000 physical is 2nd 256MB of local mem.
> 0xffff.ffff.8000.0000 virtual is start of 1st 256MB of local mem
>=20
>=20

Nope, this is not a cut and paste error.  This is a physical address
inside the SiByte that points to the 2nd 256MB of memory.  The 1125
routes a PCI hit to its BAR at 6000.0000 to an internal 16MB of space,
and we currently have it pointed at physical 0x83000000.  We can
relocate this 16MB region if needed. =20

Don't confuse physical and virtual addresses at this point.  The
addresses that I've shown are all physical and correspond to the
hardwired SiByte memory map shown in the user's manual.  Sure, the CPU
core has to use virtual addressing to get there (kseg0/1, TLB, etc.).


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