From owner-freebsd-arm@freebsd.org Mon Sep 3 20:12:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D9A3FF4E44 for ; Mon, 3 Sep 2018 20:12:00 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C0FF74D1F; Mon, 3 Sep 2018 20:11:56 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id s12-v6so2230401wmc.0; Mon, 03 Sep 2018 13:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=pD/wUg7WxQKcDZVyRamGKJgi11boJH9tfqPDZEe34jA=; b=MFKxdafZmuXIXRlA/m843PaXXE9e2yBrmWgbN/QZY5COTMqRF2TibLqY4FaAY35ZIB Iu0vJ9eIwu0XxyPAlzLGpA3HE/u3kDVjqFKBNlw4Z/nqpQJ2OndOfF1//JS3s2cOTpx3 0OBmIaHntGD2qrlI/BT9wsjCsEWucUJnksd3OZse+3voG/hBb7FDQWNqzNqykXu+gShB XW4O9Kr80ZnvHrO9zoyLF90u4SjDKO04kFIbmkydBloU1CNxPGSy5mzWZmwcSVMNFdk4 f7X0O1sKRufr9yWJ4rnx8whVKE9lacCYRbn6aLryUa1KZRtgnEnoSzUycSr8mvmwTRQc B1OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pD/wUg7WxQKcDZVyRamGKJgi11boJH9tfqPDZEe34jA=; b=qqdFdIfX1KNHuEuyutcPCPS94DE8wgQsxmqw3SZWfJqHEU5a+Fr1F4dJ/FWB/iKUeL nR04ztnsrWCgWeWXZCdHsOu6pihnYSFqa/UuQq140uus5FcnRSPPaKBkrkeAG2kq7RGn vnrg8DdnTM2Iq3vPvwboCEx37bUTfnCSlSkEtsliSx2SKHOdTQxfX3kxgl3NOKjc/jae YF1Pbnls3RTVHjDs3QYjowLcD8Cbt83l7Eg8vmdxWcSsqjQnBIB85L3sMV43AUsAi4rW +vV8DkOt40/1c34qHxvCEmzFG+L6mHjFVv0x2fF5jI+9Pb9pVULFdIFcTICG0mlYB1/J 2RsA== X-Gm-Message-State: APzg51CBjoC+Gg0Nnd/qW3PLa9F4/K8iLN6sylNkDOxVoGbSDycUOdW+ fs74Ne++omXEznR8De+S46qTTLuD X-Google-Smtp-Source: ANB0VdZFLGknqPUXyXi3PqH2RRtu011EubHQsqNLhMvlTdgNBBGJxb8rvVIpdX3Y+IHiLjn873UTMA== X-Received: by 2002:a1c:80d8:: with SMTP id b207-v6mr580432wmd.146.1536005514550; Mon, 03 Sep 2018 13:11:54 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id q5-v6sm24605928wmd.29.2018.09.03.13.11.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 13:11:53 -0700 (PDT) Subject: Re: utility for pin in BBB: PX.Y --> pin_mode, pin_name To: Warner Losh , Ian Lepore , "freebsd-arm@freebsd.org" References: <4661fc41-935a-56d5-2cc2-125085daf30a@gmail.com> <1535568374.33841.47.camel@freebsd.org> <1535576856.33841.58.camel@freebsd.org> <1535643488.33841.74.camel@freebsd.org> <1535985010.9486.44.camel@freebsd.org> <20180903180908.GG45503@funkthat.com> From: Nicola Mingotti Message-ID: Date: Mon, 3 Sep 2018 22:11:51 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2018 20:12:00 -0000 On 09/03/18 20:16, Warner Losh wrote: > > > On Mon, Sep 3, 2018 at 12:10 PM John-Mark Gurney > 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 --------------------------