Date: Fri, 31 Aug 2018 14:34:46 +0200 From: Nicola Mingotti <nmingotti@gmail.com> To: Ian Lepore <ian@freebsd.org>, Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Nicola Mingotti <nmingotti@gmail.com> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <0245623d-20a9-c1a8-e8db-89c9cf2c181d@gmail.com> In-Reply-To: <1535643488.33841.74.camel@freebsd.org> References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <CABx9NuS%2B_HiUxReryc%2B5f7fYHq5OMK0FKBfEUWbRb88tOXjw7A@mail.gmail.com> <a9141acf-79dd-d702-ff35-d2a380f68e67@gmail.com> <1535568374.33841.47.camel@freebsd.org> <daef5dda-d180-03dc-19d9-263da42e39a8@gmail.com> <1535576856.33841.58.camel@freebsd.org> <a2fe7129-054f-63dc-d6cd-d17288796b18@gmail.com> <1535643488.33841.74.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 Great Ian, In the manwhile I will write the little application software I need, when you will consider the thing solved let me know, I will mark the application "safe" and most probably I will make the port, of devmem2 and my little utility. bye nico -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider --------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0245623d-20a9-c1a8-e8db-89c9cf2c181d>