Hello all,
I’ve been using both fixed pinmux and pinmux helper entries in my device tree overlay successfully in Wheezy. However, while moving forward into Jessie I’ve discovered that the pinmux helper only generates the ‘state’ fd in /sys/devices/platform/ocp/ocp:P8_37_pinmux/state for non-lcd/hdmi pins. I observed this with cape-universala, cape-univ-hdmi, and my own cape so I looked for disparities between kernels.
It seems Robert’s 4.4.20-bone-rt kernel works just fine for all pins including hdmi pins. However the ti kernel that ships with the stable public images (2016-08-28, 2016-5-13) is missing pinmux functionality for all LCD/hdmi pins. I have checked with the following kernels:
not working: 4.4.9-ti-r25 4.4.20-ti-r43 4.7.3-bone2
working: 4.4.20-bone-rt-r13
Furthermore, normal fixed pinmux settings in overlay’s target = <&am33xx_pinmux> section, (like BB-UART5 for exmaple) do not seem to have an effect in these ti kernels either. So right now I can’t access anything between P8_27 and P8_46 without installing a new kernel.
Is there a workaround for this? I would like everything to work on the kernel in regular releases.
Thank you for any input.
Sure, the work around is don’t use those kernels.
william@beaglebone:~$ uname -r
4.4.14-ti-r34
william@beaglebone:~$ ls /sys/class/gpio
export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport
william@beaglebone:~$ sudo sh -c “echo ‘115’ > /sys/class/gpio/export”
[sudo] password for william:
william@beaglebone:~$ ls /sys/class/gpio/gpio115
active_low device direction edge power subsystem uevent value
william@beaglebone:~$ ls /sys/devices/platform/ocp/
40300000.ocmcram 48038000.mcasp 480c8000.mailbox 49000000.edma 56000000.sgx
40302000.ocmcram_nocache 4803c000.mcasp 480ca000.spinlock 49800000.tptc driver_override
44e07000.gpio 48042000.timer 4819c000.i2c 49900000.tptc modalias
44e09000.serial 48044000.timer 481a0000.spi 49a00000.tptc ocp:l4_wkup@44c00000
44e0b000.i2c 48046000.timer 481ac000.gpio 4a100000.ethernet of_node
44e35000.wdt 48048000.timer 481ae000.gpio 4a300000.pruss power
44e3e000.rtc 4804a000.timer 481d8000.mmc 4c000000.emif subsystem
47400000.usb 4804c000.gpio 48200000.interrupt-controller 53100000.sham uevent
48030000.spi 48060000.mmc 48310000.rng 53500000.aes
Is this a reason we can’t get it working in both?
Is this a reason we can’t get it working in both?
Are you speaking to me Jason ?
If so I’m not sure what the problem the OP is having. But I can say that “we” do not need to to any extra pin muxing with the 4.4.x kernels. We can just use sysfs to export the gpio’s we need, then set direction, and value. IF all we need is gpio.
Some of the things I have noticed about universal io. First, you can only have one overlay loaded that uses any pins it seems. Secondly of all the overlays I’ve tried to use, non of them let you mux everything. So thirdly, what happens is that you have to attempt to use two overlays that somehow overlap, but do not mux the same pins. . . For our own purposes this seemed impossible. So, I had to craft my own overlay base on two different universal io overlays. Which I needed to use all the epwmss pins as pwm, then around 25 other pins for gpio. 6 inputs, the rest all outputs.
The overlay univ-all that Robert created based on one of Charles’ universal io overlays seems to mux the most, and be useful. But again, for us, it wasn’t perfect. Not a complaint, just an observation. This is why I was working on universal-io single pin mux files. But after discussing that with Charles, it sounds like that would not be very useful. For most people.
Now I could personally create a universal-io overlay that would allow users to mux every_single_pin the way they see fit. But would my effort be wasted ? I do not know . . .
Oh, and right. I’m still not clear on if SPI can be muxed outside of the given board overlay file. While at the same time, it seems that universal io does not work correctly for at least one pin for the Bealebone green. I tried my best to isolate the problem as indicated in the post I made a few days ago. But am still not sure how to proceed further. It’s almost like the BBG has differnt circuitry, for that one pin - gpio1_16 which is tied through a resistor to gpio2_0 for the purpose of bringing emmc_cmd out externally according to a post made by Gerald in 2014.
While at the same time, it seems that universal io does not work correctly for at least one pin for the Bealebone green.
That is not correct. universal io, and I assume any device tree file will work fine for gpio1_16. What I meant to say is that while every other pin on a beaglebone green can be set as a gpio, using the sysfs libGPIO interface. pin gpio1_16 must first have a device tre overlay file loaded for it to function correctly.
What I’ve found that happens is that gpio1_16 seems to function correctly but does not properly report input values correctly. They’ll always read ‘0’ whether that pin is pulled high, or low - externally.
Alright, sorted it out. It looks like the pinmux helper entries for the hdmi pins are not present in the base am335x-boneblack.dtb but enabling am335x-boneblack-emmc-overlay.dtb in uEnv.txt enables pinmux for the hdmi pins. Thanks Jason for pointing me in the right direction!