P9_29 & P9_31 have wrong gpio numbers

[SwarfEye]

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

[cdsteinkuehler]

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.

[SwarfEye]

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 https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/18#issuecomment-63473110 .

Bill Gray Velkess 415 407 7356

[cdsteinkuehler]

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.

[SwarfEye]

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 https://github.com/cdsteinkuehler/beaglebone-universal-io/issues/18#issuecomment-63483630 .

Bill Gray Velkess 415 407 7356

[cdsteinkuehler]

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.

[cdsteinkuehler]

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.

[adityapatadia]

@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

[cdsteinkuehler]

Looks like this was an issue with the Bone101 page and has been fixed upstream.