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.
You need to make sure that caches are properly flushed / invalidated at the right points.
As far as USB is concerned, you might be lucky that your system usies a EHCI controller, so setting CONFIG_EHCI_DCACHE should help.
No, only OHCI.
Bad luck.
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?
Best regards,
Wolfgang Denk