Hello Wolfgang
Am 03.12.2010 16:33, schrieb Wolfgang Denk:
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
In message 4CF90819.7040904@arcor.de you wrote:
Has anyone an explanation for this behavior? Is anyone out there having dcache running on an ARM926 and working usb/tftpboot?
Many drivers have not been written to work with enabled caches.
What is the reason that special handling is needed when dcache is enabled? If a driver doesn't use any DMA there should be no need as the dcache is only enabled for the RAM and not for any memory mapped IO if I understand the code in arch/arm/lib/cache-cp15.c right.
On ARM, device write accesses are typically just store instructions (in C: assignments to a volatile pointer). With caches on, these accesses will be - guess what? cached, i. e. they are NOT written to
the device, at least not immediately. And if you repeatedly read a register (like when polling for some status bit to change) these accesses will be cached, too.
I understand this behavior. But it is only true if the memory area in question is marked as cacheable.
As the memory mapped network controller (SMSC9221) is not cached it shouldn't be a problem or do I miss something here?
You said you had enabled the data cache, so why do you think these accesses are not cached?
Please see arch/arm/lib/cache-cp15.c The code there creates 4096 page table entries (1MB each) for the whole 4GB address space and initializes each entry in a way that it is not cacheable (mmu_setup():71). It then changes the page table entries which are pointing to a RAM area to make these, and only these, cacheable (dram_bank_mmu_setup():57).
If the whole address space would be cached I would expect that even writing to NOR flash fails as the write accesses wouldn't reach the flash chip. But that works perfect on both of my systems.
Thanks Matthias Weißer