Date: Wed, 29 Aug 2018 15:07:36 -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: <1535576856.33841.58.camel@freebsd.org> In-Reply-To: <daef5dda-d180-03dc-19d9-263da42e39a8@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1535576856.33841.58.camel>