Date: Mon, 3 Sep 2018 12:16:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org>, Nicola Mingotti <nmingotti@gmail.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name Message-ID: <CANCZdfp3OwGfd3QGM4E52Asapae6NiLsi7PQ6hjNNdzPU1GT0w@mail.gmail.com> In-Reply-To: <20180903180908.GG45503@funkthat.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> <1535985010.9486.44.camel@freebsd.org> <20180903180908.GG45503@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney <jmg@funkthat.com> wrote: > Ian Lepore wrote this message on Mon, Sep 03, 2018 at 08:30 -0600: > > 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. > > This should work: > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts > It would, but then you'd be left parsing the output. And to know what's actually going on, you have to look at a bunch of nodes. It's a lot easier to thread that with libfdt than it is to roll your own code to do it. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp3OwGfd3QGM4E52Asapae6NiLsi7PQ6hjNNdzPU1GT0w>