[U-Boot] arm: Activating dcache breaks 'usb start' and 'tftpboot' on jadecpu

[Matthias Weißer]

Hello Wolfgang

Am 03.12.2010 16:33, schrieb Wolfgang Denk:
> Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
> 
> In message <4CF90819.7040904 at 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