mmap()-caching

Manuel Stühn freebsdnewbie at freenet.de
Sat May 16 09:48:31 UTC 2015


Hi list,

I'm trying to extend the TI-pru drivers' features on a Beaglebone Black. 
Due the long compile time of a complete kernel i removed the driver 
entry (device ti_pruss) from kernel-config and load it as kernel-module 
instead. I'd copied the files sys/arm/ti/ti_pruss.[sh] to a sperate 
folder and added this makefile:

% cat Makefile
.PATH: ${.CURDIR}

KMOD =   ti_pruss
SRCS =   ti_pruss.c
SRCS +=  bus_if.h device_if.h ofw_bus_if.h
CFLAGS += -DDEBUG

.include <bsd.kmod.mk>
%

It builds and loads fine, but its behavior is not exact the same as if 
it is compiled into the kernel statically.

The ti-pruss driver reveals the pru internals by implementing the mmap() 
stub and marks this area uncacheable. This works perfectly if this 
driver is compiled directly into the kernel! But when i use these very 
same files and build a kernel module instead, there seems to be caching 
active. I recognize this by using a ported version of prudebug[1] and 
singlestepping through pru-code. If there is caching active, single step 
does not result in a step.

I've put some debug-outputting to the mmap()-stub of the driver-module 
to print out the memory-attributes (vm_memattr_t *memattr); this output 
looks like:

ti_pruss_mmap: *memattr: 0x00000001

so to me it seems, that the VM_MEMATTR_UNCACHEABLE is set in *memattr.

How can i provide the same behavior for the module as for the built-in 
driver?

Thanks,

Manuel

[1] http://sourceforge.net/projects/prudebug/


More information about the freebsd-arm mailing list