[U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Ilya Yanok]

Dear Marek,

28.06.2012 19:41, Marek Vasut wrote:
>> Surely. (but that probably was an AM3517 with 64 byte cache line)
> m28 is imx28 with 32byte cacheline

You are lucky then. But some systems have bigger cacheline, right?

>>> patch) and loading from ext2 and vfat (worked).
>> This is just a coincedence ;)
> Not really, did you check mainline uboot and the fixes in those?

Surely I did. Let's take a look:

>         do {
>                 /* Invalidate dcache */
>                 invalidate_dcache_range((uint32_t)&qh_list,
>                         (uint32_t)&qh_list + sizeof(struct QH));
>                 invalidate_dcache_range((uint32_t)&qh,
>                         (uint32_t)&qh + sizeof(struct QH));
>                 invalidate_dcache_range((uint32_t)qtd,
>                         (uint32_t)qtd + sizeof(qtd));

These guys are 32-byte aligned, right? So the assumption is that 
cacheline is not greater than 32. Sounds like a bug to me (though could 
be fixed rather easily with USB_MINALIGN introduced by Tom).

>                 token = hc32_to_cpu(vtd->qt_token);
>                 if (!(token & 0x80))
>                         break;
>                 WATCHDOG_RESET();
>         } while (get_timer(ts) < timeout);
>
>         /* Invalidate the memory area occupied by buffer */
>         invalidate_dcache_range(((uint32_t)buffer & ~31),
>                 ((uint32_t)buffer & ~31) + roundup(length, 32));

That's worse. First of all, rounding is wrong: consider buffer=31, 
length=32. But that's easy to fix too. The bad part is that with 
writeback cache you can't just enlarge the range to cover the buffer and 
fit alignment requirements -- this can potentially destroy some changes 
that are in the same cache line but not yet stored to RAM.

Regards, Ilya.