So this is probably more of an oversight than a bug. But when loading *some* overlays via config-pin overlay <overlay>, *AFTER* already having loaded an overlay through /boot/uEnv.txt. At least one pin will still continue function correctly( electrically ) but the file that indicates the actual value of the pin will not update correctly. As an GPI( input ). Which has nothing to do with a conflict in overlays, as I have a custom overlay that initializes several GPIO pins, as well as a few PWM pins. Plus I am loading BB-ADC-00A0.dtbo, and BB-W1-P8.26-00A0.dtbo, Where BB-W1-P8.26-00A0.dtbo is an adaption of the stock overlay BB-W1-P9.12-00A0.dtbo.
None of the above overlays describe, or use any of the same pins. So there can not be a conflict between overlays in that regard. The fix I found for this problem, was to load all the overlays through /boot/uEnv.txt. Through cape_enable=bone_capemgr.enable_partno= The pin in question that we're having issues with is P8.16. Which if memory serves me correctly is also tied to another processor pad/pin through a zero ohm resistor. Before, all the GPI's would read correctly through the value file using a shell script. While this one pin would always read 0. Now, the pin value file works correctly. @Robert, Has the ability to load multiple overlays through uboot been implemented yet ? -- 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/0dc4c9de-50d2-4d76-aacd-0bb3943ea467%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
