ppc405 dma - vm - cache question

[gregory.menke at gsfc.nasa.gov]

Kate Feng writes:
 > 
 > gregory.menke wrote :
 > 
 > > Feng, Shuchen writes:
 > 
 > >> I do not know how well ethernet driver perform with non-cacheable
 > memory.
 > 
 > > Please ask this question more specifically.
 > 
 > Thanks.  It was not a question.  I meant I did not have to
 > write  the ethernet driver  accessing non-cacheable memory.
 > Thus I do not know the performance.

The ethernet hardware and packet buffers must be non-cached, else the
cache will interfere with reading and writing the registers as well as
the packet buffers.


 > >> I really do not have the datasheet for the RTEMS motorola_shared BSP.
 > >> It could be that the firmware of thoses supported board already
 > >> had the hardware snoop turned on.  It would be better if you can
 > >> find out how to turn the hardware snoop on for your board.
 > >>
 > 
 > >The motorola_shared bsp configures the system ram such that it can be
 > >the dma target or dma source, with a bus-mastering board on the
 > >backplane.  No additional hardware-level configuration is necessary
 > >unless you want the hardware to do something extra.  All PCI memory
 > >space is configured as non-cached, which I imagine is pretty much
 > >standard these days.  Nobody is putting system ram on the pci
 > >backplane.
 > 
 > I really never said that the system ram (SDRAM) is on the PCI backplane.
 > On my board, the 10/100MHZ ethernet driver (DMA) accessed the SDRAM,
 > which is cachable by CPU.   However, the firmware did not
 > turn on the hardware snoop.  For the PCI based 1GHZ ethernet, the
 > firmware had the hardware snoop turned on for  accessing the SDRAM.
 > 
 > 
 > However, I just found out from Gene that it's a custom board - no PCI involved.

Then there may well be additional bsp setup issues that you have to
address.  My first attempt to deal with it would be setting up a BAT
to point to the address space your card occupies and controlling cache
behavior along those lines.

Gregm