> > 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. On Sat, Sep 10, 2016 at 8:55 PM, William Hermans <[email protected]> wrote: > 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. > > On Sat, Sep 10, 2016 at 8:45 PM, William Hermans <[email protected]> > wrote: > >> 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 . . . >> >> On Sat, Sep 10, 2016 at 3:00 PM, Jason Kridner <[email protected]> >> wrote: >> >>> Is this a reason we can't get it working in both? >>> >>> On Sep 10, 2016, at 2:11 PM, William Hermans <[email protected]> wrote: >>> >>> 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 >>> >>> >>> On Sat, Sep 10, 2016 at 4:53 AM, JStrawson <[email protected]> wrote: >>> >>>> 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. >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/beagleboard/5e320958-e343-4e96-b347-8c7814365e2f%40googlegroups.com >>>> <https://groups.google.com/d/msgid/beagleboard/5e320958-e343-4e96-b347-8c7814365e2f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOO >>> QaTYepNxA%40mail.gmail.com >>> <https://groups.google.com/d/msgid/beagleboard/CALHSORrDg9MzH89n_RD%2B-n-zV4QtSR_WTeqBcsDOOQaTYepNxA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/beagleboard/9AFE7358-5E36-4A9C-8974-19668C3C6114%40gmail.com >>> <https://groups.google.com/d/msgid/beagleboard/9AFE7358-5E36-4A9C-8974-19668C3C6114%40gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoqjJuR%2BWYvHq3CVonve3zaM354Hwoo%2BV%2Bgd7VrtHH12A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
