Network buffers, MPC860 and data caching

[Charles-Antoine Gauthier]

Gunter Magin wrote:
> 
> Hi,
> 
> On Mon, Sep 25, 2000 at 04:24:56PM +0100, Nick.SIMON at syntegra.bt.co.uk wrote:
> > I'd like to use data caching to speed things up on my MPC860-based board.
> 
> This is a good idea. It will give you quite a boost, esp. in write-back mode.
> 
> > However, buffers used by the SCCs e.g. for network transmit & receive must
> > not be in cached memory.  To achieve this I intend to reserve a chunk of
> > memory which has caching turned off.  This means the network buffers have to
> > be allocated from this reserved memory.
> >
> > Does anyone know of a tidy way to take control of the network stack's buffer
> > allocation?
> 
> Have a look at Charles Gauthier's & Darlene Steward's MBX BSP in the
> current snapshot. It goes a different route: All RAM is cacheable,
> however, once CPM buffers (not only for network) are touched, explicit
> cache commands for the memory covered by the buffer are used:
> 
>    - on output buffers, caches are flushed after writing and before
>      setting the ready bit
>    - on read, the cache lines for the buffer are invalidated before
>      reading the buffer
> 
> Fiddling with the MMU on a 8xx is tricky, and general MMU support in RTEMS
> is only rudimentary. For all 8xx BSPs (eth_comm + MBX) static DTLB
> entries are used, which are loaded at BSP initialization (mmu_init()),
> and then left alone.
> 
> As all network buffers (cbuf and cclusters) are funneled through a common
> routine in the BSD stack, it is possible to modify the allocation to
> get memory from a uncachable region, once you manage to set it up and tell
> the MMU about that. A problem to solve is the page size, you will have to
> go to 512k instead of 8M, and that wastes a lot of DTLB entries.

For us, the issue was trying to avoid expensive TLB miss exceptions.
These are expensive in the PPC603 and derivatives, as they must be
serviced in software. 

> 
> Please note, that you probably will have to modify other device drivers as
> well.
> 
> gm

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada