Jump to content
43oh

BeagleBone Black - Using Devicetrees to expose GPIO pin functions


Recommended Posts

I've seen this link passed around on IRC:

http://hipstercircuits.com/adding-beaglebone-cape-support-to-a-kernel-with-device-tree-in-ubuntu/

 

 

That whole website/blog has some good information too - http://hipstercircuits.com/

 

This is mostly a placeholder to get the link out there, as I intend to do some experimentation with it soon and post my experiences.

Link to post
Share on other sites

Thanks! Wonder how much has been done since that post. Like the pwm_test driver... I wonder how many other drivers are currently half-assed. Will have to look & see.

 

One thing I'd like to do is crank out a full-page sheet (even if it's 11x17) with the full cheat sheet of the headers' pins and all available functions. The SRM has these, would prefer it in a more visually pleasing format though.

Link to post
Share on other sites

jadonk has a git hub too (or jkridner the owner of #beagle ) do you have his device tree stuff ? If nothing else his readme is very beautiful, if thats an indication of how well laid out his code is . . .*shrudder* i'll be awesome stuff.

 

@@spirilis here is the link https://github.com/jadonk/validation-scripts/tree/master/test-capemgr

Link to post
Share on other sites

So after reading a little bit it *seems* almost as if for say Debian, all the binaries are exactly the same as x86( or any other architecture platform ), The only difference is the DeviceTree overlay "drivers" are different ? That cant be right is it ? If it is that is truly awesome.

Link to post
Share on other sites

So after reading a little bit it *seems* almost as if for say Debian, all the binaries are exactly the same as x86( or any other architecture platform ), The only difference is the DeviceTree overlay "drivers" are different ? That cant be right is it ? If it is that is truly awesome.

 

Yeah I must have misunderstood what I was reading. According to what dpkg says about openssh-server it is still armhf. So perhaps what I was reading was saying the source is still the same, but compiled with a compiler for a different architecture.

 

 

root@arm:~# dpkg -l *ssh*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  libpam-ssh     <none>                    (no description available)
ii  libssh2-1:armh 1.4.2-1.1    armhf        SSH2 client-side library
ii  openssh-blackl 0.4.1+nmu1   all          list of default blacklisted OpenS
ii  openssh-blackl 0.4.1+nmu1   all          list of non-default blacklisted O
ii  openssh-client 1:6.0p1-4    armhf        secure shell (SSH) client, for se
ii  openssh-server 1:6.0p1-4    armhf        secure shell (SSH) server, for se
un  rssh           <none>                    (no description available)
un  ssh            <none>                    (no description available)
un  ssh-askpass    <none>                    (no description available)
un  ssh-client     <none>                    (no description available)
un  ssh-krb5       <none>                    (no description available)
un  ssh-nonfree    <none>                    (no description available)
un  ssh-server     <none>                    (no description available)
un  ssh-socks      <none>                    (no description available)
un  ssh2           <none>                    (no description available)
Link to post
Share on other sites
  • 3 weeks later...

fyi, jotting down notes here:

 

http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spruh73h -- AM3359 Technical Reference Manual, page 815 has the bitmap of the pinmux ctrl registers.  I printed that out for reference.  Page 758 has the list of conf_* canonical names for the pins but I think the main datasheet has the X_Y (e.g. 0_31) pin name associative reference.

 

 

These pinmux ctrl registers start at hex 0x800 above the Control Module base address, of 0x44E10000 ... how I found this, well the pinmux kernel debug dir has some 44e1 hex in its name so I went hunting--see page 155 for the ARM Cortex-A8 Memory Map, look down to the 0x44C0_0000 entry (L4_WKUP), click on the L4_WKUP link, takes you to page 157, scroll down to 0x44E10000 and you'll see that's a 128KB memory segment assigned to "Control Module"

 

This address scheme explains why the pinmux "pins" directory has some hex ID in its name:

root@beaglebone:~# ls -l /sys/kernel/debug/pinctrl/44e10800.pinmux/
total 0
-r--r--r-- 1 root root 0 Jan  1  1970 gpio-ranges
-r--r--r-- 1 root root 0 Jan  1  1970 pinconf-groups
-r--r--r-- 1 root root 0 Jan  1  1970 pinconf-pins
-r--r--r-- 1 root root 0 Jan  1  1970 pingroups
-r--r--r-- 1 root root 0 Jan  1  1970 pinmux-functions
-r--r--r-- 1 root root 0 Jan  1  1970 pinmux-pins
-r--r--r-- 1 root root 0 Jan  1  1970 pins

And when you create Device Tree Overlay source files, the "address" of the pin you're setting is an offset above that (0x44E10800).  The "pins" file in that directory shows you the current config register value for each one.

 

Ok so to change the pinmux settings you're changing 32-bit registers corresponding to each pin within the Control Module's conf_gpmc_* stack.

 

Man this shit makes me want to crawl back to the Renesas RX!!!!! :P

Link to post
Share on other sites

Yep AM3359 datasheet -- http://www.ti.com/lit/ds/symlink/am3359.pdf

 

Page 22 is where you start seeing the BGA balls with multiple options for the pinmux, down near the bottom, "PIN NAME" of ECAP0_IN_PWM0_OUT has several options in the "SIGNAL NAME" column including "gpio0_7" as its last option.

 

Looking back at the AM3359 Tech Reference Manual, page 760 shows a "conf_ecap0_in_pwm0_out" at 0x964.  So if you wanted to modify the pinmux settings for gpio0_7, you'd reference address (0x964-0x800) = 0x164 in your devicetree overlay.

 

I think I'm gonna print both of those tables out too...

Link to post
Share on other sites

Hm, no idea what I did wrong but I tried exposing two GPIO pins and turning them on in output mode to light an LED (passing through 4.7K resistor to GND; tested with 3.3V rail it lights, albeit dimly)

 

No output at all.

/* DTO for my red LED test */

/dts-v1/;
/plugin/;

/ {
	compatible = "ti,beaglebone", "ti,beaglebone-black";

	part-number = "redled-test-1";

	fragment@0 {
		target = <&am33xx_pinmux>;
		__overlay__ {
			redled: pinmux_redled {
				pinctrl-single,pins = <
							0x040 0x7  // Output GPIO1_16
							0x04c 0x7  // Output GPIO1_19
						      >;
			};
		};
	};

	fragment@1 {
		target = <&ocp>;
		__overlay__ {
			redled_helper {
				compatible = "bone-pinmux-helper";
				pinctrl-names = "default";
				pinctrl-0 = <&redled>;
				status = "okay";
			};
		};
	};
};

... Definitely loaded & the pinmux is correct:

root@beaglebone:~# cat $SLOTS
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 9: ff:P-O-L Override Board Name,00A0,Override Manuf,redled-test-1
pin 14 (44e10838) 00000027 pinctrl-single
pin 15 (44e1083c) 00000027 pinctrl-single
pin 16 (44e10840) 00000007 pinctrl-single
pin 17 (44e10844) 00000027 pinctrl-single
pin 18 (44e10848) 00000027 pinctrl-single
pin 19 (44e1084c) 00000007 pinctrl-single
pin 20 (44e10850) 00000017 pinctrl-single
pin 21 (44e10854) 00000007 pinctrl-single

(note pin 16, 19 at 840 and 84c are both '7' instead of '27')

 

I echo'd 16 and 19 to /sys/class/gpio/export so the sysfs dirs are exposed:

root@beaglebone:~# cat $GPIO
GPIOs 0-31, gpio:
 gpio-16  (sysfs               ) out hi
 gpio-19  (sysfs               ) out hi

GPIOs 32-63, gpio:
 gpio-52  (eMMC_RSTn           ) out lo
 gpio-53  (beaglebone:green:usr) out lo
 gpio-54  (beaglebone:green:usr) out lo
 gpio-55  (beaglebone:green:usr) out hi
 gpio-56  (beaglebone:green:usr) out lo
 gpio-59  (McASP Clock Enable P) out hi

GPIOs 64-95, gpio:

GPIOs 96-127, gpio:
root@beaglebone:~# ls -l /sys/class/gpio/gpio16
lrwxrwxrwx 1 root root 0 Jan  1 00:46 /sys/class/gpio/gpio16 -> ../../devices/virtual/gpio/gpio16
root@beaglebone:~# ls -l /sys/class/gpio/gpio19
lrwxrwxrwx 1 root root 0 Jan  1 00:47 /sys/class/gpio/gpio19 -> ../../devices/virtual/gpio/gpio19
root@beaglebone:/sys/class/gpio/gpio16# echo out > direction
root@beaglebone:/sys/class/gpio/gpio16# echo 1 > value

And no dice.  Nada.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...