Debian Overlay / Pinmux not working?

Hey guys,

I have been fighting this for a few days now. But it seems to me that no matter what I do I cannot get the pinmux’ing to work when applying overlays in debian. I have tried 7.8 and 8.2 and either is really different.

I was looking around to see if I was the only one in this boat and it turns out I found a post on stack exchange that describes my issue perfectly.

Unfortunately the “answer” was to install angstrom. I was hoping someone on the list would have some secret answer as to why applying an overlay was not changing the pinmux’s?

I would very much like to stick with debian but if the answer is go back angstrom I guess I can live with that.

Thanks

That is strange because it seems to be working for everyone else. What is your kernel version?

If you are using kernel version 4.1 or higher, then do the following on your BBB

git clone https://github.com/RobertCNelson/bb.org-overlays.git

Follow the instructions readme.md file. My guess is you don’t have the correct Device Tree Compiler, but this repo will install the correct version.

Regards,
John

Yes I am running:

Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l GNU/Linux

I followed your instructions but still am at a loss. I was able to update the device tree compiler and the kernel which is now:

Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015 armv7l GNU/Linux

Perhaps describing my exact steps might shed some light on my screw up?

This is the device tree I am testing with:

/*
snip for space
*/
/dts-v1/;
/plugin/;

/{
compatible = “ti,beaglebone”, “ti,beaglebone-black”;
part-number = “EBB-GPIO-Example”;
version = “00A0”;

fragment@0 {
target = <&am33xx_pinmux>;

overlay {
ebb_example: EBB_GPIO_Example {
pinctrl-single,pins = <

/============= Inputs ================/
0x070 0x17 // P9_11 PINS$28 GPIO0_30 = 30 Input Mode7 pullup
0x078 0x17 // P9_12 PINS$30 GPIO1_28 = 60 Input Mode7 pullup
0x074 0x17 // P9_13 PINS$29 GPIO0_31 = 31 Input Mode7 pullup
0x048 0x17 // P9_14 PINS$18 GPIO1_18 = 50 Input Mode7 pullup
0x040 0x17 // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup
0x04c 0x17 // P9_16 PINS$19 GPIO1_19 = 51 Input Mode7 pullup
0x15c 0x17 // P9_17 PINS$87 GPIO0_5 = 5 Input Mode7 pullup
0x158 0x17 // P9_18 PINS$86 GPIO0_4 = 4 Input Mode7 pullup

/* OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down /
/
INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down */

;
};
};
};

fragment@1 {
target = <&ocp>;
overlay {
gpio_helper {
compatible = “gpio-of-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&ebb_example>;
};
};
};
};

I also removed ALL overlays from my system before doing this below.
Here is my output from slots and a python program to get the pins i wrote:

root ~/bbb_stuff # slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
9: P-O-L- 0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example

root ~/bbb_stuff # ./getpins

Unfortunately the “answer” was to install angstrom. I was hoping someone on the list would have some secret answer as to why applying an overlay was not changing the pinmux’s?

I would very much like to stick with debian but if the answer is go back angstrom I guess I can live with that.

Thanks

You do not have to go back to Angstrom, and if you ask me that is very counter productive. Read my guide here: http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

Do note, that the kernel I talk about at the beginning is just an example. You do not have to use the exact kernel I demonstrated. Any 4.x kernel should work with that guide.

William,

Thanks. This basically is exactly what I did reading johns reply. I guess my main disconnect here is. I can apply a device tree overlay that I make. I see it “applied” in dmesg and in slots. However the pinmux output from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 for their modes when I specifically set the dtc to 0x17.

I have not actually tried to use it as an input in code yet. Merely have been seeing that it is not “applying” what i thought it should. Perhaps I am looking at the wrong pinoutput?

for example P9_11’s offset is 0x70 and its PIN value is 28. So | grep 870

root ~/bb.org-overlays # cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 870
pin 28 (44e10870.0) 00000027 pinctrl-single

which is not 0x17?

I am being very wordy here just to make sure you guys know exactly what I am doing and my expectations.

So does anything I am doing look wrong?

Again thanks a bunch guys for the help. I have been at this for the better part of a week now and I agree William it’s a step in the WRONG direction going to Angstrom.

ril3y

Again thanks a bunch guys for the help. I have been at this for the better part of a week now and I agree William it’s a step in the WRONG direction going to Angstrom.

I agree, and in fact, I’ve been a supporter of Robert’s debian images since long before they were official. Well, actually early on, I built my own images based on his Debian on ARM guide.

William,

Thanks. This basically is exactly what I did reading johns reply. I guess my main disconnect here is. I can apply a device tree overlay that I make. I see it “applied” in dmesg and in slots. However the pinmux output from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 for their modes when I specifically set the dtc to 0x17.

Ok, so let me say first that I’m no expert.BUT I’ve seen similar to this when setting pin mode 0x7 on the USR LED “pins”. In the debugfs pins/ directory as you mention above. When checked, over other one’s pin mode would be 0x17 so in effect . . .

0x7, 0x17, 0x7, 0x17. It stands to reason, that this is by design. How or why, I’m not sure, but I’ve seen this many times over the last 3 or so years. I’ve never looked into it however. So, with that said, perhaps this is the same as your case. But of course, slightly different.

essentially, I think all that matter is the first 8 bits. Someone correct me here if I’m wrong.

essentially, I think all that matter is the first 8 bits. Someone correct me here if I’m wrong.

Never mind, my brain was off some where in la la land. Anyway . . . have you check to see what mux 0x27 means versus 0x17 ? For all I know the pull-up bit field could be shifted left one bit( left most nibble ), which is what the difference between 0x17, and 0x27 is.

GPIO MODE SETTINGS
Bit 6 Bit 5 Bit 4 Bit 3 Bit 2,1,0
Slew Control Receiver Active Pullup/Pulldown Enable Pullup/down Mux Mode
0 Fast 0 Disable 0 Pulldown select 0 Enabled 000 Mode 0 to
1 Enable 1 Pullup select 1 Disabled 111 Mode 7
e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down
e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down
TRM Table 9-60

From the table above, 0x27 in an input and 0x17 is an output. My guess is that there is some conflict that occurs and that is why the config isn’t set correctly. What does your overlay look like and what do you see when you install the overlay?

Regards,
John

One more thing, just defining pinmux in the overlay will have no effect. The pinmux will only be configured as part of installing the driver. Just before the kernel calls the driver probe function, it sets up the pinmux as defined by the pinctrl definition.

Regards,
John

His overlay is in the first post John.

Err sorry his second post.

Thanks William,

He uses the command:

echo EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots”

but I think he should be using the command:

sudo sh -c “echo 'EBB-GPIO-Example-00A0’ > /sys/devices/platform/bone_capemgr/slots”

Other than that, I don’t see why he has this problem.

Regards,
John

One is done as root, the other is not. I would guess he is probably logged in as root.

Riley, confirm device tree compiler version. As such. . .

$ dtc -v
Version: DTC 1.4.1-g5cadadd9

If it’s not version 1.4.1-, then you have the wrong version.

I don't have time to dig into the full details, but IIRC this has
popped up before. I don't think the gpio-of-helper driver actually
does anything (like setup the pinmux) if you're not actually
_exporting_ any gpios. But I could be wrong...it's been a while since
I crawled through the code.

Oh, and your pinmux settings don't match the comments. If you really
want inputs with the pullup enabled, the value to use is 0x37, *NOT*
0x17. It's important to enable the gpio receive buffer (bit 0x20) or
you won't be able to read the value on the GPIO pin (IIRC it will
always return zero). If you really want outputs and just didn't
update the comments, 0x17 is fine.

A good overview of GPIO’s and device tree overlays: http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/

Which is something I’ve been meaning to read myself for a long time . . .

I believe the pinmux gets setup in pinctrl_bind_pins() found in drivers/pinctrl.c.

pinctrl_bind_pins() gets called by really_probe(), line 291 of drivers/dd.c and then calls the gpio_of_helper_probe on line 316 or 320, so I don’t think this has anything to do with gpio-of-helper.c driver. Probably need to setup some debug statements in pinctrl_bind_pins() to see why this does not work.

Regards,
John

Here is what I get by following https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md, and modifying it to reflect one of the pins Riley is using. So, what I suggest is that Riley has an overlay loaded that has already claimed these pins. Either by experimenting previously with different values, and not unloading the previous overlay. Or An overlay unbeknownst to him. I’ll experiment now with changing up my overlay and see what happens. But the only other option really is that something on Riley’s system is broken.

/*

OK so I changed to this:

fragment@0 {
target = <&am33xx_pinmux>;
overlay {
pinctrl_test: pinctrl_test_7_pins {
pinctrl-single,pins = <
0x040 0x27 // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup

;
};
};
};

Compiled, copied, and then loaded the dtbo file. Then . . .

$ dmesg |grep pinctrl-test-7
[168784.685978] bone_capemgr bone_capemgr: part_number ‘pinctrl-test-7’, version ‘N/A’
[168784.706649] bone_capemgr bone_capemgr: slot #4: ‘Override Board Name,00A0,Override Manuf,pinctrl-test-7’
[168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo ‘pinctrl-test-7-00A0.dtbo’ loaded; overlay id #0
[169658.533949] bone_capemgr bone_capemgr: part_number ‘pinctrl-test-7’, version ‘N/A’
[169658.554579] bone_capemgr bone_capemgr: slot #5: ‘Override Board Name,00A0,Override Manuf,pinctrl-test-7’
[169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo ‘pinctrl-test-7-00A0.dtbo’ loaded; overlay id #1

This shows that both device tree overlays have been sucessfully loaded. Despite the fact that the previously overwritten overlay was never unloaded. Then . . .

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

So . . .
i$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
5: P-O-L- 1 Override Board Name,00A0,Override Manuf,pinctrl-test-7

oops, two overlays loaded lets see wha thappens when first one is unloaded.

$ sudo sh -c “echo ‘-4’ > /sys/devices/platform/bone_capemgr/slots”
$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
5: P-O-L- 1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Just as I thought, the original pinmux is persistent. So . . .
$ sudo sh -c “echo ‘-5’ > /sys/devices/platform/bone_capemgr/slots”
$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Ok just as I expected. pinmux’s are kept until explicitly changed. Let’s try loading it again.
$ sudo sh -c “echo ‘pinctrl-test-7’ > /sys/devices/platform/bone_capemgr/slots”
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 00000017 pinctrl-single

Whoopsy . . …