Date: Thu, 30 Aug 2018 09:38:08 -0600 From: Ian Lepore <ian@freebsd.org> To: Nicola Mingotti <nmingotti@gmail.com>, Russell Haley <russ.haley@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <1535643488.33841.74.camel@freebsd.org> In-Reply-To: <a2fe7129-054f-63dc-d6cd-d17288796b18@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1535643488.33841.74.camel>