Skip site navigation (1)Skip section navigation (2)
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>