From owner-freebsd-arm@freebsd.org Mon Sep 3 18:16:38 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 DFAB7FF0D76 for ; Mon, 3 Sep 2018 18:16:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 813008F12B for ; Mon, 3 Sep 2018 18:16:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id j198-v6so11876485ita.0 for ; Mon, 03 Sep 2018 11:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0WzfTYg3yAOAOOCxqs97D1+MJ66p06HmDlOITSyP3AE=; b=ItEjqj8IfnLb7miso/r6l4nRcM+Kjfyse6OkBpj6jJDBqUiSV21cSEO6SBX7h8MGr8 JnpsvHHeWOiajQ7Bseyjmg3iNKtSOdUK3Suv8rkpbmkJ+B80+aFCVL81nmSyxLi7S699 +KUgAVEDzs+ssBVnWRfO4pUAV/zpnM54lFHocVF44mIfiN5RHTTV8W4aE7tSERbzl+r7 fy+IDmz2sXzmA5dlNqOTrR5UX5rZTJ+JAToSNe7lhwO5oVJuhknGvLy4Ikz40lxTrNDf /cs2sfNetQjGu0kMkTw4ibHwMKq4g0wYkxYXhSBMZl+s3QhyBBzsCp+R0bFRxxxMEbnJ TksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0WzfTYg3yAOAOOCxqs97D1+MJ66p06HmDlOITSyP3AE=; b=P+YqB2hD+Uk2ZOrSSuAUO1h5SgIqW0eaPQDJDh7yl0bqc1ilCSMFgbQEhBvbi59gZa ftKyoPwO/a0HDB3lb9I/s78tn7IJITLe1aUn2IfejGImLU04zWlmsuAatIu5gb5MV7n5 ld+aH0fpm01iCxw6PQv95Ywvim2su72Fgt3Lb0XT4YrVs6uDOgrJwzc+/vXhn9+S93Fw zwzhh7GxIRr3Orf24DxPqejTpDpf4CldIJ3HwjcLvuL4MNswVn6/FHaamg9OsZeDTVuZ tu/e1LuakKC+sBwpmN7+jNllptGYVxSdFtky6jZWtL5KBVijGMpYofG3rw2CHhhxBlrg Acqg== X-Gm-Message-State: APzg51DrLhoZsA35/Yk5ahAe1vFAmyl6GSoaB3a0g75XpeKruVJ4Ngrt b9QA1OhovKw1y2LbZfnUkHec13g+xH5Fucx88tkKig== X-Google-Smtp-Source: ANB0VdajGc5mROkIZVLKP/Aw2O1RE+8KSlPYq10ncxz1YTnCEwH8KHMzlZzrsOvjTKt+nPzSHh4J5tg8YR33a3OgCTs= X-Received: by 2002:a02:59cc:: with SMTP id v73-v6mr20917598jad.5.1535998596534; Mon, 03 Sep 2018 11:16:36 -0700 (PDT) MIME-Version: 1.0 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> <20180903180908.GG45503@funkthat.com> In-Reply-To: <20180903180908.GG45503@funkthat.com> From: Warner Losh Date: Mon, 3 Sep 2018 12:16:24 -0600 Message-ID: Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Ian Lepore , Nicola Mingotti , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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:16:38 -0000 On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney wrote: > 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 > It would, but then you'd be left parsing the output. And to know what's actually going on, you have to look at a bunch of nodes. It's a lot easier to thread that with libfdt than it is to roll your own code to do it. Warner