We use an EBSA-285 with caching on. You have to be careful which
drivers you use and any references to DMA data must be protected by
cache flushes. Look at the tulip.c driver - you'll see an example of
all the cache flushes used. You'll need to modify any of your drivers
which use DMA to behave in a similar way. Basically, you need to flush
the cache immediately after setting up data structures read by the
device and you need to invalidate the cache before reading those data
structures.
-Jon
Excerpts from linux-arm: 9-Sep-99 EBSA285 and Cacheing by Dave [EMAIL PROTECTED]
> I'd like to address the issue of data caching on the ebsa285.
> (kernel is 2.2.10-rmk2)
>
> We have been running our ebsa285s with data caching off. With caching
disabled
> the stock ncr53c8xx SCSI driver works well and the lance ethernet
driver works
> nicely w/ a few changes. Everything falls apart, however, when we turn on
> data caching. The NCR scsi shuts its self down after detecting
> cache coherency problems, and the lance ethernet simply does not work.
>
> In a naive attempt to solve the problem we've tried several combinations of
> the following:
> 1.) There is a driver out there called bigphysmem; it
allocates a fixed
> chunks of memory at boot time and provides a malloc()
interface to it.
> We turn off caching on the sections managed by this driver.
> We modified the scsi and ether drivers to use the bigphysmem
malloc().
>
> 2.) we modified kmalloc et.al. to turn off caching on the
> returned pages.
>
> With any combination of these changes the kernel will boot
> and the drives work reasonably well, but not 100%.
>
> One class of problems seems to be that some file are corrupted.
> for example the shell complains when it tries to source in
> its config files:
>
> bash: .: /etc/profile.d/lang.sh: cannot execute binary file
>
> With caching turned off, the bigphysmem modified drivers
> work as expected (it boots w/ no errors).
>
>
> Finally to the questions:
> 1.) Is anybody actually running an ebsa285
> with caching enabled ?
>
> If so what type of changes are
> required to the drivers ?
>
> 2.) Are we way off base here ?
> Shouldn't the bigphysmem or changes to kmalloc()
> solve the problem ?
>
> What subtlety are we missing ?
>
>
>
> --
> [EMAIL PROTECTED]
> Inet Technologies Inc.
> Plano, Texas
> unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
