From owner-freebsd-arm@FreeBSD.ORG Fri Jan 16 18:13:43 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C672C44F for ; Fri, 16 Jan 2015 18:13:43 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B06E948 for ; Fri, 16 Jan 2015 18:13:43 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YCBOv-000Jp2-C6; Fri, 16 Jan 2015 18:13:41 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0GIDdN9001965; Fri, 16 Jan 2015 11:13:40 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19VlaTS/qWJISkYMaYrcEJ2 Message-ID: <1421432019.14601.302.camel@freebsd.org> Subject: Re: mmap-issue From: Ian Lepore To: Manuel =?ISO-8859-1?Q?St=FChn?= Date: Fri, 16 Jan 2015 11:13:39 -0700 In-Reply-To: <54B945FB.10609@freenet.de> References: <54B945FB.10609@freenet.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id t0GIDdN9001965 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: Fri, 16 Jan 2015 18:13:43 -0000 On Fri, 2015-01-16 at 18:10 +0100, Manuel St=FChn wrote: > Hi, >=20 > I'm seeing unexpected behavior using mmap( /dev/mem ) on my beaglebone=20 > black. It seems to me, that writing to/reading from this mapped pointer= =20 > does not immediatly take effect. The code looks like this: >=20 > #define GPIO1 0x4804C000 > #define CLR_REG 0x190 > #define SET_REG 0x194 > #define LED0 21 > #define LED1 22 > #define LED2 23 > #define LED3 24 >=20 > int fd =3D open( "/dev/mem", O_RDWR ); >=20 > int pagesize =3D getpagesize(); >=20 > volatile uint32_t* ptr =3D > mmap( 0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, GPIO1_ADDR )= ; >=20 > ptr[SET_REG] =3D LED0 << 1; >=20 >=20 > I mapped for testing purposes the AM335x-GPIO-registers from /dev/mem. > Writing into these mmap'ed registers for toggling some LEDs does not=20 > immediatly take effect. I have to call it several times to get one=20 > LED-toggle. Is there any data caching I'm missing? >=20 > Thanks for hints. 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. 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." -- Ian