setting Beagle Bone pinmux directly

1,514 views
Skip to first unread message

jmelson

unread,
May 28, 2017, 7:19:24 PM5/28/17
to BeagleBoard

Since I can't get the devicetree working on the 4.4.62 kernel, I'm trying to set the GPIO pin configuration directly.  I did this on the Beagle Board a long time ago, and am trying to adapt that code.

So, I have this code :

  int fd = open("/dev/mem", O_RDWR | O_SYNC);
   volatile ulong *pinmux;
   pinmux = (ulong*) mmap(NULL, 0x2000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x44E10000);
   if (pinmux == MAP_FAILED) {
     printf("Pinmux Mapping failed\n");
     close(fd);
   }
   pinmux[0x0880/4] = 0x0f;            // P8.25  GPIO1.0 write, no pulls, mode 7
   pinmux[0x0884/4] = 0x0f;            // P8.24  GPIO1.1 write, no pulls, mode 7

and then try to write values to the set and clear registers :
   fd = open("/dev/mem", O_RDWR | O_SYNC);
 
  // GPIO Configuration: configure are input
   volatile ushort *gpios;
   gpios = (ushort*) mmap(NULL, 0x2000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x4804C000);
   if (gpios == MAP_FAILED) {
     printf("Gpios Mapping failed\n");
     close(fd);
   }
    gpios[gpios_clear] = 0xff;
    gpios[gpios_set] = j;


But I don't see any response.  More oddly, I don't see any change in
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins

Which lists the above pins as :
pin 32 (44e10880.0) 00000032 pinctrl-single
pin 33 (44e10884.0) 00000032 pinctrl-single

I think I am writing 0x0f to those registers, and I still see 0x32, which would indicate why the GPIOs are not getting through to the header pins.
If I read out the pinmux register in my program, it ALSO shows as 0x32, so apparently the write to that register is silently ignored.


Has anybody done this and know where I'm going wrong?

Thanks much,

Jon

William Hermans

unread,
May 28, 2017, 8:50:01 PM5/28/17
to beagl...@googlegroups.com
What I'd do in your shoes is just use the sysfs gpio file structure to set your pins how needed. You do not technically need to load anything from a device tree file if all you're using is GPIO. Well any hardware module really,if you know what you're doing, but many things are fairly complex.

Initially what you'll see with no device tree files loaded is this:

root@beaglebone:~# ls /sys/class/gpio/
export  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport


Here. the gpiochipxx entries are gpio banks, and the files export, and unexport are for enabling / disabling pins as GPIO. So for instance, if you need to use P8_12( I picked this pin because I'm fairly sure it's not used by any running peripherals ), you'll need to look up the GPIO # for P8_12, which is 44. Simply echo "44" to the export file like so:

root@beaglebone:~# echo '44' > /sys/class/gpio/export

Then you can see the sub directory for this pin is created:
root@beaglebone:~# ls /sys/class/gpio/
export  gpio44  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport


After that we can explore the gpio44 sub directory.
root@beaglebone:~# ls /sys/class/gpio/gpio44/
active_low  device  direction  edge  power  subsystem  uevent  value

  • active_low I believe is how you set your pin high / low logic. e.g. what state it is in by default(reverse logic, or not).
  • direction is the file you need to change in order to set the pin as input or output. values are limited to "in" or "out" I believe.
  • edge is the file you set low to high or high to low edge detect in. I do not remember all the values, but I think there are three one of which can be "both". Setting this file is required if you want to use any pin "event" monitoring.
  • value is the file you set high, or low for high, or low pin state. In the case of input, you can not change this file, but you can read from it. Valid values are 0, and 1 for output pins. Input are the same except of course you can not set the pin value, only read it.

Anyway, just google "how to  beaglebone GPIO" and you'll find a lot of info out there on the subject. Just experiment until you've got it, then create a shell script to run at boot, or write a C file to directly setup your pins on the fly. If you so wish.












jmelson

unread,
May 28, 2017, 9:24:47 PM5/28/17
to BeagleBoard


On Sunday, May 28, 2017 at 7:50:01 PM UTC-5, William Hermans wrote:



 
What I'd do in your shoes is just use the sysfs gpio file structure to set your pins how needed. You do not technically need to load anything from a device tree file if all you're using is GPIO. Well any hardware module really,if you know what you're doing, but many things are fairly complex.

I've tried this, too, and am not having much success with it.  I may be trying to use GPIOs that are reserved.  I will try it with a couple more pins and see if I can get anywhere.

Thanks,

Jon

jmelson

unread,
May 28, 2017, 10:25:54 PM5/28/17
to BeagleBoard
OK, GPIOs 45 to 47 are available and work.  So, far, none of the other GPIOs I've tried work, as they seem to be assigned to other mode selections.  The export and direction files don't seem to change the pinmux setting.

Is there some utility that can change the pinmux assignment, so I can set those pins to Mode 7?
Funny that GPIOs 45-47 don't show up as in mode 7 in /sys/kernel/debug/pinctrl/44e10800.pinmux
I don't understand how they can work if not in Mode 7.  Well, this is still all confusing.

Thanks,

Jon

jmelson

unread,
May 28, 2017, 11:35:56 PM5/28/17
to BeagleBoard
Charles Steinkuehler says the new kernels use memory management to lock access to the pinmux registers.  This certainly matches the symptoms I am getting.  Hopefully, he can tell me how to use config-pin to set it up.

Jon

William Hermans

unread,
May 29, 2017, 2:57:36 AM5/29/17
to beagl...@googlegroups.com
First, you disable universal IO, second, if you do not need hdmi, you disable hdmi video, and audio at boot. Through /boot.uEnv.txt. This will free up any pin that's not related to I2C-0, I2C-2, the eMMC, and possibly a few others I'm not thinking of off the top of my head.

On Sun, May 28, 2017 at 8:35 PM, jmelson <el...@pico-systems.com> wrote:
Charles Steinkuehler says the new kernels use memory management to lock access to the pinmux registers.  This certainly matches the symptoms I am getting.  Hopefully, he can tell me how to use config-pin to set it up.

Jon

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5365e3af-9f87-4632-8bc4-41371dc5be89%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
May 29, 2017, 3:00:34 AM5/29/17
to beagl...@googlegroups.com
That's /boot/uEnv.txt, typo above.

Greg

unread,
May 29, 2017, 9:07:14 PM5/29/17
to BeagleBoard
The kernel is doing what a kernel does, manager of the resources!
Try this in a terminal:

config-pin -h

Here's an example usage:

config-pin P9.14 low_pd

That set header pin P9.14 to a GPIO direction output and set to LOW and with pull-down resistor.
It works great!

Use this extremely useful spreadsheet for reference:

The file is pinmux.ods.

Regards,
Greg
Reply all
Reply to author
Forward
0 new messages