utility for pin in BBB: PX.Y --> pin_mode, pin_name
Nicola Mingotti
nmingotti at gmail.com
Mon Sep 3 20:12:00 UTC 2018
On 09/03/18 20:16, Warner Losh wrote:
>
>
> On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney <jmg at funkthat.com
> <mailto:jmg at 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
Thank you all for your comments and suggestions,
these are the opinion I maturated.
1] parsing "sysctl -b hw.fdt.dtb | dtc -I dtb -O dts"
is a bit easier than parsing |"ofwdump -a -p"
anyhow, as far as i could esablish, all the interesting parts are, in
both cases, just after
"pinctrl-single,pins:" string. I already parsed and "deciphered" those
blocks, no problem.
2] The problem for me remains only for gpio pins. From Ian answer I see
they come configured by defualt on the chip. That is why they are not in
the DTB.
3] libft. could be interesting to bypass the parsing, but since it
is not in a port I guess I understand I shoud compile the base-system to
have it.
=> 3 problems arise: first, I never compiled the base-system since now;)
second,
it would be not much practical to recompile the base for each machine in
which
I want to use my utility and last, other people could not use it without
compiling base.
In conclusion i will do as follow:
I will finish my utility parsing text repr. of the DTB and using
"gpioctl" + and maps like this one:
https://vadl.github.io/images/bbb/P8Header.png
I will give you the script link when it is finished. In a second moment
I can rewrite it in C, for now, with all the parsing stuff, it is far better
to start with a scripting language Ruby.
bye
nico
|
--
--------------------------
Dr. Nicola Mingotti
R&D - Borghi Srl
CTO - BondInsider
--------------------------
More information about the freebsd-arm
mailing list