DPRAM parameters for 860P

DPRAM parameters for 860P

[Subodh Nijsure]

Hello,

Currently the 2.4.2 code assumes that DPRAM is always 4KB has anybody
put together m8xx_cpm_dpalloc() that takes advantage of larger DPRAM on 860P?

->From arch/ppc/kernel/8xx_io/commproc.c

/* The dual ported RAM is multi-functional.  Some areas can be (and are
 * being) used for microcode.  There is an area that can only be used
 * as data ram for buffer descriptors, which is all we use right now.
 * Currently the first 512 and last 256 bytes are used for microcode.
 */
#define CPM_DATAONLY_BASE   ((uint)0x0800)
/*#define CPM_DATAONLY_SIZE ((uint)0x0700)*/

/* Above definition assumes we have 4KB DPRAM but 860P has 8KB, so
 * we experiment.  My RCCR , RMDS says DATA size of 0x3400 is safe
 */

#define CPM_DATAONLY_SIZE   ((uint)0x3400)
#define CPM_DP_NOSPACE      ((uint)0x7fffffff)



I have been running my system  with above configuration for couple of days
without any problems. Are there any side effects I should be aware of?

2. Anybody knows if  there a driver currently that uses the 8xx IDMA
to transfer data from a peripheral to CPU and back?

/Subodh Nijsure

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

Re: DPRAM parameters for 860P

[Dan Malek]

Subodh Nijsure wrote:

> Currently the 2.4.2 code assumes that DPRAM is always 4KB has anybody
> put together m8xx_cpm_dpalloc() that takes advantage of larger DPRAM on 860P?

Well, you have the code, it is pretty easy to change it.

The intention is to allow Linux to run on all variants, and there
is plenty of DPRAM to support this.  When I have done 860P projects,
they were custom platforms that required the use of the DPRAM for
special uses (like the ATM routing and scheduling tables).  You also
have to consider microcode patches and any constraints they may place
on the DPRAM.

Due to the flexibility of the CPM and all of the different variants,
I'm not sure I could (or want to) put together a configuration script
to cover all of this.  The kernel provides a starting point for everyone.
If we can find generally useful changes, that's fine, but I would like
to avoid the complexities of providing software useful to only one
person or platform.  It's pretty hard to test the effects of any
changes when you do this.

Thanks.


	-- Dan

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