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