Date: Sat, 16 May 2015 11:46:16 +0200 From: =?UTF-8?B?TWFudWVsIFN0w7xobg==?= <freebsdnewbie@freenet.de> To: freebsd-arm@FreeBSD.org Subject: mmap()-caching Message-ID: <555711E8.3020802@freenet.de>
next in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?555711E8.3020802>