RPXLite 823 PCMCIA troubles

RPXLite 823 PCMCIA troubles

[Mark S. Mathews]

Howdy Folks,

We've been working with the embedded 2.2.13 kernel on an RPX-Lite CW with
a XPC823ZT66A processor running at the 50MHz/8MHz setting.  We have a
pcmcia wireless lan card that we're trying to get working, but our
accesses to the common memory regions of the card are twitchy.  We can run
with the card briefly, but eventually we wind up with a machine-check.

Over the past week or so we've tried just about every variation of
settings we can think of with only slightly varying results.  No matter
what we try, it always ends in a machine check.  The wireless driver code
runs well on the x86, our PowerBook, and on a different 860 based platform
(non-Linux, no MMU) so we're fairly confident it isn't the code.

I've attached an outline of our initialization procedure at the end of
this mail.  Are we missing something?

Here are some of the things we've varied:

- Address space allocations (region and size)
- Bus timings
- Adding/removing delays between accesses
- Using readb/writeb vs. direct access

Most of the time the failure occurs on a read.

One specific question...when setting up the PCMCIA bus timings, the 823
book lists the settings in units of "clock cycles".  Which clock?  We've
been assuming GCLKx or GCLKx_50 which are both 50MHz (hence 20ns cycle).

Many Thanks,
-Mark

-----------------------------------------------------------------
Here's the outline of our initialization procedure:

- Clear the pcmcia registers
	PORx = 0
	PBRx = 0
	PER = 0
	PSCR = 0
	PGCRA = 0
	PGCRB = 0

- Test PIPR for card presence, if found assume it's our card

- Turn on power
	PGCR[OE] = 1			; deassert Output Enable
	RPX_BSCR[PCVLTCTLx] = 0000	; Vcc=Vpp=GND
	(delay for settle)
	RPX_BSCR[PCVLTCTLx] = 0110	; Vcc=Vpp=5v
	(delay for settle)
	PGCR[RESET] = 1			; Assert reset pin
	(delay for 500 usec)
	PGCR[RESET] = 0			; deassert reset pin
	(delay for 500 usec)
	PGCR[OE] = 0			; assert Output Enable
	(delay for 300 usec)

- Map card Attribute memory
	PBR1 = 0xe4000000
	POR1[BSIZE] = 01000		; 32K bank size
	POR1[PSLOT] = 1			; slot B
	remap_base = ioremap(PBR1)	; returns 0xc4000000
	POR1[PRS] = 010			; Attribute mem
	POR1[PSL] = 01001		; 9 clock cycles
	POR1[PSST] = 0100		; 4 clock cycles
	POR1[PSHT] = 0010		; 2 clock cycles
	POR1[PV] = 1			; this bank is valid

- Set pcmcia config index in option register at Attrib+0x800
	remap_base[0x800] = 01000001	; index 1 and level mode interrupts
					; enables card for mem+io

- Map card IO memory
	PBR0 = 0xe0000000
	POR0[BSIZE] = 01101		; 512 bytes bank size
	POR0[PSLOT] = 1			; slot B
	remap_base = ioremap(PBR0)	; returns 0xc4009000
	POR0[PRS] = 011			; IO space
	POR0[PSL] = 01001		; 9 clock cycles
	POR0[PSST] = 0100		; 4 clock cycles
	POR0[PSHT] = 0010		; 2 clock cycles
	POR0[PV] = 1			; this bank is valid

- Map card Common memory
	PBR2 = 0xe8000000
	POR2[BSIZE] = 01000		; 32K bank size
	POR2[PSLOT] = 1			; slot B
	remap_base = ioremap(PBR2)	; returns 0xc400b000
	POR2[PRS] = 000			; Common memory space
	POR2[PSL] = 01001		; 9 clock cycles
	POR2[PSST] = 0100		; 4 clock cycles
	POR2[PSHT] = 0010		; 2 clock cycles
	POR2[PV] = 1			; this bank is valid

- Setup interrupt
	(card specific)
	clear on-card interrupt status
	disable card generated interrupts
	(8xx specific)
	PER |= BIT24			; enable RDY/IRQ#
	PSCR = 0xffffffffff		; clear any pending
	PGCR |= BIT6			; set 8xx interrupt level 

	request_8xxirq( 13, &func, 0, "am930", NULL);
					; This func sets up SIMASK and SIPEND,
					;  right?

- Driver now waits for something to do....


Mark S. Mathews

AbsoluteValue Software     Web:    http://www.absoval.com
P.O. Box 941149            e-mail: mark@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/

Re: RPXLite 823 PCMCIA troubles

[Dan Malek]

Mark S. Mathews wrote:
> 
> Howdy Folks,
> 
> We've been working with the embedded 2.2.13 kernel on an RPX-Lite CW with
> a XPC823ZT66A processor running at the 50MHz/8MHz setting.


It's not only the RPX Lite.....I have a variety of 8xx boards
and when I have trouble like this with a particular card, it
occurs in all of the boards.


> ............ but our
> accesses to the common memory regions of the card are twitchy.


Same thing I have seen.  The I/O and attribute regions seem
to work OK, but memory regions don't.....on more than one
type of card.


> .....but eventually we wind up with a machine-check.

Which points to some kind of bus timing or protocol problem.


> runs well on the x86, our PowerBook, and on a different 860 based platform
> (non-Linux, no MMU) so we're fairly confident it isn't the code.

Well now, that's interesting (the no MMU, not the non-Linux
part :-).  With the MMU disabled, the accesses behave as guarded.
This is something I have not properly implemented on the 8xx,
and with my somewhat sloppy use of eieio() and synchronization,
I am always waiting for this to come back and haunt me.  Notice
how I buried this important fact in this paragraph.  I will now
properly implement this (yet tonight).  Tell me the kernel version
you are using and I will send some updates for your testing.


How does someone (like me :-) determine what a PCMCIA interface
in something like a PowerBook uses for bus timing?


> One specific question...when setting up the PCMCIA bus timings, the 823
> book lists the settings in units of "clock cycles".  Which clock?


It is the CLKOUT (system/bus) clock.  On the 66MHz processor,
this better be 33 MHz (processor clock / 2).  For 50 MHz or
less, the CLKOUT is the processor clock.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Mark S. Mathews]

Hey Dan,

On Tue, 30 Nov 1999, Dan Malek wrote:

> Mark S. Mathews wrote:

> > We've been working with the embedded 2.2.13 kernel on an RPX-Lite CW with
> > a XPC823ZT66A processor running at the 50MHz/8MHz setting.
> 
> 
> It's not only the RPX Lite.....I have a variety of 8xx boards
> and when I have trouble like this with a particular card, it
> occurs in all of the boards.

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

> 
> 
> > ............ but our
> > accesses to the common memory regions of the card are twitchy.
> 
> 
> Same thing I have seen.  The I/O and attribute regions seem
> to work OK, but memory regions don't.....on more than one
> type of card.

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.


> > .....but eventually we wind up with a machine-check.
> 
> Which points to some kind of bus timing or protocol problem.

We've been running _lots_ of experiments with the timing settings.  So far
3,10,6 seems to work best....but it still fails.


> > runs well on the x86, our PowerBook, and on a different 860 based platform
> > (non-Linux, no MMU) so we're fairly confident it isn't the code.
> 
> Well now, that's interesting (the no MMU, not the non-Linux
> part :-).  With the MMU disabled, the accesses behave as guarded.

I've seen the 'guarded' thing around in the sources, but I'm not sure what
it's all about.  Guess I should look. ;-)

> This is something I have not properly implemented on the 8xx,
> and with my somewhat sloppy use of eieio() and synchronization,
> I am always waiting for this to come back and haunt me.  Notice
> how I buried this important fact in this paragraph.  I will now
> properly implement this (yet tonight).  Tell me the kernel version
> you are using and I will send some updates for your testing.

embedded kernel 2.2.13


> How does someone (like me :-) determine what a PCMCIA interface
> in something like a PowerBook uses for bus timing?

I'm not really sure.  Have to ask David, it's probably buried in pcmcia-cs
somewhere.


> > One specific question...when setting up the PCMCIA bus timings, the 823
> > book lists the settings in units of "clock cycles".  Which clock?
> 
> It is the CLKOUT (system/bus) clock.  On the 66MHz processor,
> this better be 33 MHz (processor clock / 2).  For 50 MHz or
> less, the CLKOUT is the processor clock.

BIG help!  Thanks a million.

We'll keep trying and let you know.

-Mark

Mark S. Mathews

AbsoluteValue Software     Web:    http://www.absoval.com
P.O. Box 941149            e-mail: mark@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/

Re: RPXLite 823 PCMCIA troubles

[Dan Malek]

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

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Mark S. Mathews]

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

Re: RPXLite 823 PCMCIA troubles

[Dan Malek]

Mark S. Mathews wrote:


> Ok, the wlan PCMCIA card is working....but only after an ugly hack.

That would imply there is some kind of bus timing problem.
Let's go off-line and talk about this.  It is a tedious job
to attach a logic analyzer and look at this stuff, but from
my past I have seen some pretty weird external bus cycles
associated with TLB faults and it is the only way to see
what is really happening.

There are other interesting things we could do here, like
pin static TLB entries......

By the way, excellent work!  No more pleading ignorance as in
past messages :-).


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Alan Mimms]

Effectively, guarded means "don't prefetch" for code fetches.  It also means that
no speculative data fetches will be performed to a guarded space.  Speculative
data fetches occur when the processor is speculatively executing a chunk of code
as a result of a predicted branch whose condition is not yet known to be as
predicted.  Setting the guarded attribute on an area prevents such speculation.
This issue probably is nearly moot on the nearly non-superscalar (dumb as a rock)
8xx processors, but is MUCH more important (i.e., VITAL) on the 82xx processors
with the 603ish core and on all "real" PowerPC processors.

a

"Mark S. Mathews" wrote:

> Hey Dan,
>
> On Tue, 30 Nov 1999, Dan Malek wrote:
>
> > Mark S. Mathews wrote:
>
> > > We've been working with the embedded 2.2.13 kernel on an RPX-Lite CW with
> > > a XPC823ZT66A processor running at the 50MHz/8MHz setting.
> >
> >
> > It's not only the RPX Lite.....I have a variety of 8xx boards
> > and when I have trouble like this with a particular card, it
> > occurs in all of the boards.
>
> 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
> (?)
>
> >
> >
> > > ............ but our
> > > accesses to the common memory regions of the card are twitchy.
> >
> >
> > Same thing I have seen.  The I/O and attribute regions seem
> > to work OK, but memory regions don't.....on more than one
> > type of card.
>
> 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.
>
> > > .....but eventually we wind up with a machine-check.
> >
> > Which points to some kind of bus timing or protocol problem.
>
> We've been running _lots_ of experiments with the timing settings.  So far
> 3,10,6 seems to work best....but it still fails.
>
> > > runs well on the x86, our PowerBook, and on a different 860 based platform
> > > (non-Linux, no MMU) so we're fairly confident it isn't the code.
> >
> > Well now, that's interesting (the no MMU, not the non-Linux
> > part :-).  With the MMU disabled, the accesses behave as guarded.
>
> I've seen the 'guarded' thing around in the sources, but I'm not sure what
> it's all about.  Guess I should look. ;-)
>
> > This is something I have not properly implemented on the 8xx,
> > and with my somewhat sloppy use of eieio() and synchronization,
> > I am always waiting for this to come back and haunt me.  Notice
> > how I buried this important fact in this paragraph.  I will now
> > properly implement this (yet tonight).  Tell me the kernel version
> > you are using and I will send some updates for your testing.
>
> embedded kernel 2.2.13
>
> > How does someone (like me :-) determine what a PCMCIA interface
> > in something like a PowerBook uses for bus timing?
>
> I'm not really sure.  Have to ask David, it's probably buried in pcmcia-cs
> somewhere.
>
> > > One specific question...when setting up the PCMCIA bus timings, the 823
> > > book lists the settings in units of "clock cycles".  Which clock?
> >
> > It is the CLKOUT (system/bus) clock.  On the 66MHz processor,
> > this better be 33 MHz (processor clock / 2).  For 50 MHz or
> > less, the CLKOUT is the processor clock.
>
> BIG help!  Thanks a million.
>
> We'll keep trying and let you know.
>
> -Mark
>
> Mark S. Mathews
>
> AbsoluteValue Software     Web:   http://www.absoval.com
> P.O. Box 941149            e-mail: mark@absoval.com
> Maitland, FL 32794-1149    Phone:  407.644.8582
> USA                        Fax:    407.539.1294

--
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Dan Malek]

Alan Mimms wrote:


> This issue probably is nearly moot on the nearly non-superscalar (dumb as a rock)
> 8xx processors, but is MUCH more important (i.e., VITAL) on the 82xx processors
> with the 603ish core and on all "real" PowerPC processors.

In defense of the 8xx, it isn't as dumb as some people believe.
It is a PPC core that performs a number of performance enhancements,
including branch folding and speculative loads.  Not to the extent
of a superscalar (and the 603 isn't a shining star compared to
other PPCs, either), but they still happen and you have to be
careful of them just like any other PPC.

Designing a system using a "it doesn't happen as often" requirement
is a very poor engineering practice.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Alan Mimms]

Sorry to have implied that it is OK to code as if it won't happen on 8xx processors.
I have personally been bitten by 8xx code written by others with lots of missing
EIEIOs.  I would NEVER recommend any coding practice that left off the proper guarded
characteristic on pages or left out the necessary EIEIOs between necessarily
sequential operations and the necessary cache flushing and SYNCs before DMAs.

Upon rereading what I had written, it does appear I was suggesting this type of coding
is optional, which IT MOST POINTEDLY IS NOT.

Thanks for amplifying, Dan.

a

Dan Malek wrote:

> Alan Mimms wrote:
>
> > This issue probably is nearly moot on the nearly non-superscalar (dumb as a rock)
> > 8xx processors, but is MUCH more important (i.e., VITAL) on the 82xx processors
> > with the 603ish core and on all "real" PowerPC processors.
>
> In defense of the 8xx, it isn't as dumb as some people believe.
> It is a PPC core that performs a number of performance enhancements,
> including branch folding and speculative loads.  Not to the extent
> of a superscalar (and the 603 isn't a shining star compared to
> other PPCs, either), but they still happen and you have to be
> careful of them just like any other PPC.
>
> Designing a system using a "it doesn't happen as often" requirement
> is a very poor engineering practice.
>
>         -- Dan

--
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RPXLite 823 PCMCIA troubles

[Brian Kuschak]

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

Re: RPXLite 823 PCMCIA troubles

[Mark S. Mathews]

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