Unsolved problem with WB caches on ARMv6

Oleksandr Tymoshenko gonzo at bluezbox.com
Fri Dec 14 20:54:36 UTC 2012

On 12/9/2012 10:24 PM, Oleksandr Tymoshenko wrote:
> Hello,
> One of the long-time issues with FreeBSD/ARMv6 is that Write-Back cache
> mode does not work properly. On PandaBoard changing cache mode to WB from WT
> causesUSB glitches (starting from stalls  to network packets corruption) and random
> memory corruptions that manifest themselves as a userland programs crashes.
> gber@ tracked down one of the bugs several month ago, but it's still unusable
> at least on my setup.
> I spent some time debugging through busdma and USB code but failed to find
> anything fishy. PandaBoard's USB host controller is EHCI. QH and QTDs are
> flushed properly. Corruption pattern in packets is weird: it's not cacheline-size
> it's like chunk of data is just missing from bulk transfer DMA buffer. L2 cache
> is disabled.
> The issue is not reproducible in QEMU.
> Fix for arm/160431 applied to busdma-v6.c didn't help.
> I'm out of ideas for now. May be Ian or Alan will have some suggestions where to look?
> If you have setup with armv6 devices, I'd appreciate test results for this patch:
> http://people.freebsd.org/~gonzo/patches/armv6-wb.diff
> Just wondering if results differ  from platform to platform.
Following up on this one.

  For pandaboard it seems to be a bunch of problems, actually, not just one:

Issues with known fixes:
- Some additional pmap flushes/syncs, andrew@ is working on it.
- I-Cache should be synced in pmap_enter_locked (otherwise userland 
programs cash in random places)
- PL310 errata workaround wasn't functioning properly because DEBUG and 
CONTROL registers are
     not available for direct access in secureboot mode. So when I told 
it was disabled - actually it wasn't.

Still working on:

- Switching from WT to WB cache mode somehow affects EHCI internal works 
so occasionally parts
of bulk IN transfers are lost. Adding delay after setting IAAD flag 
cures corruption. It's definitely not
DMA/cache problem per se.

More information about the freebsd-arm mailing list