From owner-freebsd-arm@freebsd.org Mon Sep 3 06:21:48 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 55ADEFDF53B for ; Mon, 3 Sep 2018 06:21:48 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 C966576EAB; Mon, 3 Sep 2018 06:21:47 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id j25-v6so8008811wmc.1; Sun, 02 Sep 2018 23:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=rFd7ZQfcMf14IeLFVKbMTpb1Ak1BnpSu4tROgXnkPcA=; b=uAl3rT9jqs7etvwSdiLsA/iFgbMDFHnXdwntKEtwf01R9arUK0LgZ2UOJmvoq99IeJ tSJEvSd9BOS2D47cvWYHCSUqNS+EU/mp4q3qElatY8L180Qx4kQpE28LZPObGrVJ1wlU 2pVvGNMfwtZtBwvHrj1U3XzkZ1R/8y0hfeig5pCzsxNiQFB8I/a+uHtm+91yTDlAYEzg sbpQMlWMgd1M2MxJC+JjmTSszshuSe+2X3RU+bkZLdrkIzPWYnXpM1UyPJu6tkEGsJ5I 3eYUFoTxpINseZAWv/QHDaRlL2991f0ZW01Dnjylmf/DsQM0lG+YhanclbOORbFhyGcE +Igg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=rFd7ZQfcMf14IeLFVKbMTpb1Ak1BnpSu4tROgXnkPcA=; b=rwWIrhsyPD8u+NlkBxgya7Z9BfKJAzqWb/kw9wysQHaoCO9hjaP//kvkVsWSre1HUr x0FEqFMVp/O3i0ilRkp4aK6RTZAJuBomKglBpXojWnsdGDhjEdXcQZKBcGgEAQpahOcX reBN2S8wofYVZnpeG7xAMFAMjnh7u3tvKh4Q0h68rh8WxkPuOtzOZ2boqwpwGr+W4t/b dYWbxa+6ox4S0jNi57sE26qGaDxpXrh0zqCB+eYk47WQvT2yHfaCdxDL+lHMLITeLDpr LtpE7DI51G8bJuvxGVbkfKS02yaQMxnQa+DPkbFVcq37QKBU0K2wLTYsanMBHPfHKVSc m75w== X-Gm-Message-State: APzg51DYyK1ofwoHyRqz6fr956phzY9kEjegqIooan88CqN7bYhuf03W rae15P8enbCcUsfzkPm3Zas= X-Google-Smtp-Source: ANB0Vdb64B+yO1uU5z1DLkg++SIPEZLf1XKQyd6u20B7fa5tiMrQlvxH4pzMmPzXZWSD3nDEKPl15w== X-Received: by 2002:a1c:a187:: with SMTP id k129-v6mr4009490wme.111.1535955706747; Sun, 02 Sep 2018 23:21:46 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id e141-v6sm13447572wmd.32.2018.09.02.23.21.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Sep 2018 23:21:45 -0700 (PDT) Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Ian Lepore , Russell Haley Cc: freebsd-arm , "nmi >> Nicola Mingotti" 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> From: Nicola Mingotti Message-ID: Date: Mon, 3 Sep 2018 08:21:44 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1535643488.33841.74.camel@freebsd.org> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 06:21:48 -0000 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 -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider --------------------------