RPXLite 823 PCMCIA troubles
Mark S. Mathews
mark at absoval.com
Fri Dec 3 17:32:42 EST 1999
Thanks Brian,
This suggestion is most definitely an important note for future reference.
Unfortunately, this card only supports 8-bit transfers and the troubles
were especially bad in the common memory region.
Thanks again,
-Mark
On Thu, 2 Dec 1999, Brian Kuschak wrote:
> Mark,
>
> One thing to note about PCMCIA I/O region accesses on
> the 823...
>
> If the access is to a 16-bit port, the PCMCIA
> controller needs to see an acknowledgement from the
> card on the IOIS16_B pin. However when the processor
> is configured for debugging (full trace, etc) this pin
> is unavailable. It's muxed with some other debug
> function (VFLS, I think?). Check your settings in the
> SIUMCR register. If the core never gets this
> acknowledge on the 16 bit access, it might generate a
> bus error, which would show up as a machine check.
>
> There are only two solutions for this hardware
> shortcoming. Either setup the SIUMCR to give up your
> trace capability (which isn't very useful w/ virtual
> memory anyway), or don't do 16-bit accesses in PCMCIA
> I/O space.
>
> Hope that helps.
> -Brian Kuschak
>
>
> --- "Mark S. Mathews" <mark at absoval.com> wrote:
> >
> > Howdy Folks,
> >
> > Ok, the wlan PCMCIA card is working....but only
> > after an ugly hack.
> > Basically, I modified
> > the MachineCheck function to ignore the exception
> > (just return) if the
> > faulting address (contents of DAR) falls in the
> > iomapped range we've
> > established for the PCMCIA card.
> >
> > Any opinions on our solution?
> >
> > I'd still like to know what's causing these
> > exceptions, but that's for
> > another day.
> >
> > -Mark
> >
> > On Tue, 30 Nov 1999, Dan Malek wrote:
> >
> > >
> > > Mark S. Mathews wrote:
> > >
> > >
> > > > Hmmmm. The way ours "works for awhile", I'm
> > wondering if there's a
> > > > problem w/ the way the 8xx is handling the WAIT#
> > when the MMU is enabled
> > > > (?)
> > >
> > > Shouldn't be the problem. The MMU appears (on
> > block diagrams
> > > anyway :-) to be far enough removed from the
> > memory controller
> > > for this to happen.
> > >
> > >
> > > > This is good to know. Our card supports I/O or
> > memory access to the
> > > > shared memory. We'll shift over to the I/O and
> > try that.
> > >
> > > The version I have running on my PowerBook only
> > uses I/O.....
> > > or am I mistaken?
> > >
> > >
> > > > We've been running _lots_ of experiments with
> > the timing settings. So far
> > > > 3,10,6 seems to work best....but it still fails.
> > >
> > > Thanks. I'll keep those numbers around.....there
> > are others
> > > I would rather see.....:-).
> > >
> > >
> > > > I've seen the 'guarded' thing around in the
> > sources, but I'm not sure what
> > > > it's all about. Guess I should look. ;-)
> > >
> > > I just fixed it. I'll send it to you privately as
> > well as
> > > post it on the ppc.kernel.org server. I hope it
> > corrects
> > > something.
> > >
> > >
> > >
> > > -- Dan
> > >
> >
> >
> > Mark S. Mathews
> >
> > AbsoluteValue Software Web:
> > http://www.absoval.com
> > P.O. Box 941149 e-mail: mark at absoval.com
> > Maitland, FL 32794-1149 Phone: 407.644.8582
> > USA Fax: 407.539.1294
> >
> >
> >
>
>
Mark S. Mathews
AbsoluteValue Software Web: http://www.absoval.com
P.O. Box 941149 e-mail: mark at absoval.com
Maitland, FL 32794-1149 Phone: 407.644.8582
USA Fax: 407.539.1294
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list