From owner-freebsd-arm@freebsd.org Mon Sep 3 18:09:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48DA7FF0997 for ; Mon, 3 Sep 2018 18:09:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1CC38EC99; Mon, 3 Sep 2018 18:09:16 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w83I98TM060839 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Sep 2018 11:09:08 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w83I98mH060838; Mon, 3 Sep 2018 11:09:08 -0700 (PDT) (envelope-from jmg) Date: Mon, 3 Sep 2018 11:09:08 -0700 From: John-Mark Gurney To: Ian Lepore Cc: Nicola Mingotti , freebsd-arm Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <20180903180908.GG45503@funkthat.com> Mail-Followup-To: Ian Lepore , Nicola Mingotti , freebsd-arm References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1535985010.9486.44.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 03 Sep 2018 11:09:08 -0700 (PDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 18:09:17 -0000 Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > On Mon, 2018-09-03 at 08:21 +0200, Nicola Mingotti wrote: > > > > On 08/30/18 17:38, Ian Lepore wrote: > > > > > > On Wed, 2018-08-29 at 23:40 +0200, Nicola Mingotti wrote: > > > > > > > > On 08/29/18 23:07, Ian Lepore wrote: > > > > > > > > > > On Wed, 2018-08-29 at 22:26 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > On 08/29/18 20:46, Ian Lepore wrote: > > > > > > > > > > > > > > On Wed, 2018-08-29 at 20:01 +0200, Nicola Mingotti wrote: > > > > > > > > > > > > > > > > Thank you for suggestion Russel, > > > > > > > > > > > > > > > > but unfortunately, at best of my knowldege, > > > > > > > > $> man 3 gpio_open > > > > > > > > and its shell command brother > > > > > > > > $> man 8 gpioctl > > > > > > > > > > > > > > > > are not appropriate, they are useful only if a pin > > > > > > > > has been configured as GPIO pin. > > > > > > > > > > > > > > > > The program i look for would be useful instead to > > > > > > > > esablish > > > > > > > > which physical pin has been configured as GPIO pin or > > > > > > > > PWM, PRU, I2C etc. > > > > > > > > > > > > > > > > I asked also in the Forum, but the only one aswering > > > > > > > > (@Phishry) has given me your same suggestion. > > > > > > > > > > > > > > > > If nobody knows of such a program i will start the > > > > > > > > implementation, > > > > > > > > maybe > > > > > > > > tomorrow. > > > > > > > > > > > > > > > > bye > > > > > > > > Nicola > > > > > > > > > > > > > > > Please bottom-post when replying to freebsd mailing lists. > > > > > > ok ! > > > > > > > > > > > > > > There is no interface defined for getting an fdt_pinctrl > > > > > > > driver > > > > > > > to > > > > > > > return info about the current configuration. Even if such > > > > > > > an > > > > > > > interface > > > > > > > existed, there would also need to be a new driver providing > > > > > > > a > > > > > > > cdev > > > > > > > so > > > > > > > that userland can access the information. > > > > > > ok, no interface. > > > > > > > > > > > > > > There is also nothing in freebsd equivelent to the linux > > > > > > > devmem2 > > > > > > > program. A driver would have to be written to provide > > > > > > > access to > > > > > > > device- > > > > > > > mapped memory before such a program could be written. You > > > > > > > can't > > > > > > > access > > > > > > > arm hardware registers via /dev/mem or /dev/kmem. > > > > > > > > > > > > > > -- Ian > > > > > > I just compiled devmem2 and it seems to work. I did silly > > > > > > modifications. > > > > > > The code is here: http://euriscom.it/data/dm2.c > > > > > > (forget the first comment lines, they are poor, I did not > > > > > > intend > > > > > > to > > > > > > share this, it is my working copy) > > > > > > > > > > > > if i run it: > > > > > > --------------------------------- > > > > > > #> ./dm2 0x44e10998 b > > > > > > /dev/mem opened. > > > > > > Memory mapped at address 0x20221000. > > > > > > Value at address 0x44E10998 (0x20221998): 0x5 > > > > > > --------------------------------- > > > > > > > > > > > > Whic corresponds to what i wrote in the DTO. > > > > > > ----- > > > > > >               pru_pru_pins: pinmux_pru_pru_pins { > > > > > >                          pinctrl-single,pins = < > > > > > >                              // 0x1a4 0x05   /* P9.27 > > > > > > pr1_pru0_pru_r30_5, > > > > > > Mode 5 output pull-down   */ > > > > > >                              0x19c 0x26   /* P9.28 > > > > > > pr1_pru0_pru_r31_3, > > > > > > Mode 6 input pull-down    */ > > > > > >                              0x198 0x05    /* PRU0-2 -- P9.30 > > > > > > -- > > > > > > pr1_pru0_pru_r30_2 ... se in MODE-5  */ > > > > > >                              >; > > > > > >                      }; > > > > > > ----- > > > > > > > > > > > > This is the only test i made but it seems improbable I got > > > > > > the > > > > > > same > > > > > > value by chance;) > > > > > > > > > > > > It goes without saying that I don't understand all what i > > > > > > wrote, > > > > > > so, i could be boldly wrong ;) > > > > > > > > > > > > If it turns out it works let me know, i can make the port. > > > > > > > > > > > > bye > > > > > > n. > > > > > You might accidentally get /dev/mem access to work, but it's > > > > > not by > > > > > design. The rules of the arm memory model forbid mapping the > > > > > same > > > > > physical memory to different virtual addresses using different > > > > > attributes (normal cacheable memory versus Device memory), and > > > > > I > > > > > don't > > > > > see anything in the arm devmem code that handles memory > > > > > attributes. > > > > > > > > > > -- Ian > > > > I would like to discuss more this thing but really, i am too > > > > ignorant > > > > on > > > > this subject. > > > > > > > > What i can say is this, I learnt to use devmem2 from D.Molloy > > > > book > > > > "Exploring BeagleBone", > > > > see pg. 218. The author says this way "bypasses the Linux OS". I > > > > used > > > > the thing > > > > in Linux, it works, as it seems to do in FreeBSD-12-APLHA. > > > > > > > > If can tell you also I remember i used it one day in FreeBSD- > > > > 11.1, > > > > it > > > > was working. > > > > > > > > I don't have the background to go deeper. > > > > > > > > If you can understand why it works and establish that it is > > > > realiable > > > > (even only for reading) let me (us) know ! ;) > > > > > > > > bye > > > > n. > > > > > > > I think it should be possible to do a bit of kernel work to change > > > it > > > from "works by accident" to "does the right thing", except I'm not > > > sure > > > it'll be possible to automatically detect when Device memory is > > > being > > > accessed/mapped. It may be necessary to use the mem(4) ioctls to > > > set > > > the region to MDF_UNCACHEABLE, or even better, define a new > > > MDF_MMIO > > > for mapping ranges of device registers that arm systems have to > > > treat > > > as memory type Device. I'll look into it when I have some time. > > > > > > -- Ian > > Hi, > > > > After a suggestion from @Phisfry on the forum I guess found a way > > to bypass the need of devmem2 to write my "pinfunc" utlity. > > > > I can read (all?) pin configurations from "ofwdump -a -p", indeed I > > see  > > blocks > > like this: > > ---------------------- > > #> ofwdump -a -p > > ---------- > >    Node 0x30f4: pinmux_ehrpwm0_AB_pins > >              phandle: > >                00 00 00 ce > >              pinctrl-single,pins: > >                00 00 01 54 00 00 00 03 00 00 01 50 00 00 00 03 > > ---------- > > > > So I hopefully wrote my script to parse "ofwdump" and what i got is > > this, > > > > -------------------------- > > #> pinfunc.rb > > HEADER   NAME            MODE       FUNCTION > > ... > > P.9.10   SYS_RESETn      1          - > > P.9.11   UART4_RXD       not-found > > P.9.12   GPIO1_28        not-found > > P.9.13   UART4_TXD       not-found > > P.9.14   EHRPWM1A        not-found > > P.9.15   GPIO1_16        not-found > > P.9.16   EHRPWM1B        not-found > > P.9.17   I2C1_SCL        not-found > > P.9.18   I2C1_SDA        not-found > > P.9.19   I2C2_SCL        3          I2C2_SCL > > P.9.20   I2C2_SDA        3          I2C2_SDA > > P.9.21   UART2_TXD       3          ehrpwm0B > > P.9.22   UART2_RXD       3          ehrpwm0A > > P.9.23   GPIO1_17        not-found > > P.9.24   UART1_TXD       not-found > > P.9.25   GPIO3_21        0          mcasp0_ahclkx > > P.9.26   UART1_RXD       not-found > > P.9.27   GPIO3_19        not-found > > P.9.28   SPI1_CS0        6          pr1_pru0_pru_r31_3 > > P.9.29   SPI1_D0         0          mcasp0_fsx > > P.9.30   SPI1_D1         6          pr1_pru0_pru_r31_2 > > P.9.31   SPI1_SCLK       0          mcasp0_aclkx > > P.9.32   VADC > > ... > > --------------------------- > > > > The only isssue seems to be that GPIO pins do not appear. > > I could fix the problem parsing the output of "gpioctl -f /dev/gpioX/ > > -l" > > > > But I have a couple of questions : > > 1] Is there somewhare written the GPIO pins configuration in > > "ofwdump" ? > > 2] If it is not written there, what is the reason ? > > 2.1] Where is the boot GPIO pins configuration written ? > > 2.2] I looked also in "dtc -I dtb -O dts /boot/dtb/am335x- > > boneblack.dtb  > > > > > > less" > > but at the best of my ability to read it I could not find the GPIOs  > > configuration. > > > > bye > > nico > > The pinctrl info in the fdt data is used to override pins from their > default settings that the chip powers on with. So you have to start > with empirical knowledge of that, and treat the fdt data as a set of > modifications to it. Obviously the pin defaults are different for every > soc. > > In theory, the pinctrl data is not static, it can be changed at > runtime. In practice, that rarely happens, and could only happen if the > node has multiple pinctrl-N properties so that the drivers can switch > between them. > > Rather than parsing the ascii output from ofwdump (a program that's > hard to love in any way), you'd probably be better off reading the > actual binary data (sysctl -b hw.fdt.dtb | yourprog), and parse it > using libfdt. Hmm, do we distribute libfdt? I think not. It should at > least be a port even if it's not licensed properly to be distributed > with the base system. This should work: sysctl -b hw.fdt.dtb | dtc -I dtb -O dts -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."