Date: Mon, 03 Sep 2018 08:30:10 -0600 From: Ian Lepore <ian@freebsd.org> To: Nicola Mingotti <nmingotti@gmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <1535985010.9486.44.camel@freebsd.org> In-Reply-To: <ac59fc72-26e8-95c2-5d67-aed14ae27c87@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> <1535643488.33841.74.camel@freebsd.org> <ac59fc72-26e8-95c2-5d67-aed14ae27c87@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1535985010.9486.44.camel>