Date: Sun, 18 Jan 2015 11:12:46 +0100 From: =?windows-1252?Q?Manuel_St=FChn?= <freebsdnewbie@freenet.de> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: mmap-issue Message-ID: <54BB871E.5050302@freenet.de> In-Reply-To: <1421432019.14601.302.camel@freebsd.org> References: <54B945FB.10609@freenet.de> <1421432019.14601.302.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54BB871E.5050302>