mmap-issue

[Manuel Stühn]

Am 16.01.2015 um 19:13 schrieb Ian Lepore:
> My gut-level reply is "Don't try to access hardware registers like that,
> you're only going to run into problems" (as you already have).  But I've
> just been informed that linux allows such things.  It seems crazy to me
> to allow userland access to the same hardware that freebsd drivers are
> trying to work with.
>
> So I think the right answer is that you should investigate using gpioctl
> and libgpio and the /dev/gpiocN devices.

Please don't misunderstand me, i'm used to use drivers (if there are any 
drivers) for a certain hardware. How could i possibly test, if the value 
is really written through directly? Reading it back in the program would 
have delivered me the cached value. This mmap-call was made to test if 
the value I wrote to the hardware gets written directly and drives the 
LED accordingly. I did this to prove my theory that the mmap-call is 
somehow/-where cached (what i did not expect because MAP_SHARED was 
set). The Linux-behavior was more what i did expect.

> The direct answer to the problem you're seeing is probably that you need
> to flush the L2 cache write buffers to ensure that the writes make it
> all the way to the hardware, and there is no userland API for doing
> that.  You may also be running into a problem related to an ARM
> restriction that a given physical address must not be mapped twice using
> different memory attributes, and those address ranges are already mapped
> by the kernel as Device memory, so remapping them as Normal memory
> via /dev/mem may result in the dreaded "undefined behavior."
>

What about making a kernel driver which itself maps the according memory 
and provides it by implementing the mmap-stub? Would this be a proper 
way? But also in this case, caching is obstructive.