From owner-freebsd-arm@FreeBSD.ORG Sun Jan 18 10:16:22 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2275ADD; Sun, 18 Jan 2015 10:16:22 +0000 (UTC) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.freenet.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E0FD760; Sun, 18 Jan 2015 10:16:22 +0000 (UTC) Received: from [195.4.92.142] (helo=mjail2.freenet.de) by mout0.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (port 25) (Exim 4.82 #2) id 1YCmu3-00011Y-VX; Sun, 18 Jan 2015 11:16:19 +0100 Received: from localhost ([::1]:59481 helo=mjail2.freenet.de) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.82 #2) id 1YCmu3-0000AL-RM; Sun, 18 Jan 2015 11:16:19 +0100 Received: from mx11.freenet.de ([195.4.92.21]:46318) by mjail2.freenet.de with esmtpa (ID freebsdnewbie@freenet.de) (Exim 4.82 #2) id 1YCmqe-0007HI-DF; Sun, 18 Jan 2015 11:12:48 +0100 Received: from p5ddd75b4.dip0.t-ipconnect.de ([93.221.117.180]:49482 helo=[127.0.0.1]) by mx11.freenet.de with esmtpsa (ID freebsdnewbie@freenet.de) (TLSv1.2:DHE-RSA-AES128-SHA:128) (port 587) (Exim 4.82 #2) id 1YCmqe-0003Y9-5i; Sun, 18 Jan 2015 11:12:48 +0100 Message-ID: <54BB871E.5050302@freenet.de> Date: Sun, 18 Jan 2015 11:12:46 +0100 From: =?windows-1252?Q?Manuel_St=FChn?= User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: mmap-issue References: <54B945FB.10609@freenet.de> <1421432019.14601.302.camel@freebsd.org> In-Reply-To: <1421432019.14601.302.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150117-1, 17.01.2015), Outbound message X-Antivirus-Status: Clean X-Originated-At: 93.221.117.180!49482 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 10:16:22 -0000 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.