P9_29 & P9_31 have wrong gpio numbers
Closed this issue · 8 comments
Hello,
Thank you so much for putting this universal cape together. It has been a tremendous help to me in getting up to speed with device trees and beagle bone programming.
I'm new to this git stuff, so I'm not sure if this is the best way to report this error, but I thought I ought to give it a shot.
In my work I noticed that P9_29 and P9_31 were not being automatically exported the way the rest of the pins are. I found that in the cape-universal-00A0.dts file the gpio number assigned to these pins were short by 10... so
where P9_29 is supposed to have a "gpio4 25" it has a "gpio4 15"
and
where P9_31 is supposed to have a "gpio4 24" it has a "gpio4 14"
I have not been using config-pin, but I noticed in my grepping that the same error occurs in config-pin as well.
Correcting this things resolved the issue and the pins are now properly exported.
Thanks again!
Bill
The GPIO pin numbers (14 & 15) are correct. GPIO bank 3 (gpio4 in the 3.8 dts files) pins 24 and 25 are not physically connected to the BeagleBone P8/P9 headers. I have working capes that use these pins (the Probotix PBX-BB X-axis step/dir signals) so I am pretty sure the pin numbering is correct.
I suspect you were not seeing these pins exported because they were already claimed by the audio subsystem.
Well, you may be right about the audio sub systems. I am not familiar with
the audio subsystems.
But I don't think you are correct in your statement that pins gpio4_24 and
gpio4_25 are not connected to the P9 header...
If you make the changes I suggested then those pins get exported, and are
fully functional as both gpio pins and as pru pins. If you do not make
these changes, then they do not get exported and do not work.
Thanks again.
Bill
On Tue, Nov 18, 2014 at 5:50 AM, cdsteinkuehler notifications@github.com
wrote:
The GPIO pin numbers (14 & 15) are correct. GPIO bank 3 (gpio4 in the 3.8
dts files) pins 24 and 25 are not physically connected to the BeagleBone
P8/P9 headers. I have working capes that use these pins (the Probotix
PBX-BB X-axis step/dir signals) so I am pretty sure the pin numbering is
correct.I suspect you were not seeing these pins exported because they were
already claimed by the audio subsystem.—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Bill Gray
Velkess
415 407 7356
The BBB schematic shows P9.29 and P9.31 are connected to pins A13 and B13 on the AM335x. These are GPIO bank 3, I/Os 14 and 15. If you refer to the AM335x data-sheet, table 2-16, you will find that gpio3_24 and gpio3_25 are not even CONNECTED to package pins! On my system, the GPIO pins are properly exported as /sys/class/gpio/gpio110 and /gpio111. I have the HDMI "cape" disabled via uEnv.txt, so the HDMIN (no audio) cape is loaded along with cape-universal and the eMMC cape.
I honestly do not understand the issue you are having, and the existing code works for my testing of header pins P9.29 and P9.31. Please check the pin numbering and verify I'm looking at the same thing you are.
Hmmm...
Well, I'm certainly not trying to be a PITA here, and I have to admit that
you are talking over my head on this one. I'm really just trying to get up
to speed with things, and I am super grateful for all the work you have
done to help make that possible. Really, I'm very thankful.
Here is my story...
I also disabled HDMI in uEnv.txt. I then loaded cape-universal and
cape-univ-hdmi.
I noticed that P9_29 and P9_31 were not being exported, and started to poke
around.
Perhaps I should note that the BBBs that I am using are the latest Rev C
versions... I don't know if that makes a difference?
When I look at the header pinout charts on the Beaglebone 101 page...
http://beagleboard.org/Support/bone101
...I see that P9_29 is gpio_121 and P9_31 is gpio_120.
If I subtract (32x3) from 121, I get 25.
If I subtract (32x3) from 120, I get 24
When I plug these values into the cape-universal and re-compile everything
exports and works properly...?
I am just trying to help out by reporting a fix that worked for me... and
it does work for me. Why? I really don't know. I agree that it is weird
that something different is working for you.
Thanks again.
Bill
On Tue, Nov 18, 2014 at 7:03 AM, cdsteinkuehler notifications@github.com
wrote:
The BBB schematic shows P9.29 and P9.31 are connected to pins A13 and B13
on the AM335x. These are GPIO bank 3, I/Os 14 and 15. If you refer to the
AM335x data-sheet, table 2-16, you will find that gpio3_24 and gpio3_25 are
not even CONNECTED to package pins! On my system, the GPIO pins are
properly exported as /sys/class/gpio/gpio110 and /gpio111. I have the HDMI
"cape" disabled via uEnv.txt, so the HDMIN (no audio) cape is loaded along
with cape-universal and the eMMC cape.I honestly do not understand the issue you are having, and the existing
code works for my testing of header pins P9.29 and P9.31. Please check the
pin numbering and verify I'm looking at the same thing you are.—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Bill Gray
Velkess
415 407 7356
OK, either the bone-script documentation is wrong, or the kernel export numbering scheme has a discontinuity in the last gpio bank (GPIO pins 96-127). I'll ask about this on the BeagleBoard list.
If the issue is a discontinuity in kernel numbering, then my code would still work (it's generally writing directly to the GPIO registers, and the pinmux address values are correct), but scripts or things using the files exported in /sys/class/gpio would fail if they really should be gpio 120 & 121 instead of gpio 110 & 111.
It looks like this is a goof in the documentation on the Bone101 web page. See this thread in the BeagleBoard forum for details: https://groups.google.com/d/msg/beagleboard/kLqraF35aZw/F-Jiv5EdDSoJ
If you have actually hooked wires up to these pins and seen them twiddle using gpio 120 & 121, please report back with details of exactly what you did and how you tested. I'll see if I can reproduce here, but as far as I can tell, gpio 120 and 121 don't ever come off the die to physical package pins, and the pin numbering in the universal cape is correct.
@cdsteinkuehler You have done a great job by making this device-tree. I have created better and stable fork of BoneScript with your device trees. Check here: https://github.com/theoctal/octalbonescript
Looks like this was an issue with the Bone101 page and has been fixed upstream.