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

Ilya Yanok
2012-06-30T15:51:53Z

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.