So, there is another *possible* work around that you could try. Keep in mind that I have not tested this myself. But config-pin can load overlays too. So it is possible that you could do something like this:
config-pin overlay <your_overlay_name_ here> Then your overlay would have to exist in /lib/firmware, as I seem to recall that config-pin for some reason does not handle pathing well, or at all. Still, I kind of via that as a hack as well, and it is possible that if universala conflicts with any overlays you want to use. That you'll receive an "file already exists" error. One trick I could think of there is create a "blank" universala overlay file, or maybe just copy the contents of your existing overlay into a new universala, then compile it and replace the old one with your new one. . . . again, in my own mind, a HUGELY undesirable hack. Anyway. I commend Charles S. for the time he's spent on Universal IO, and I love the concept. But I kept running into problems using it in production systems. So I had to stop using it. It was constantly fighting me when all I really needed to do was get something done. The result I wound up with, was not using it . . . which is really unfortunate, but I mostly view it as a learning tool anyway. I learned a lot by reading through Charles' config-pin script, and overlays he created. You and I both are using similar kernels, I think the kernel I'm using is slightly newer, which also leaves me to believe that perhaps you're one image behind the one I'm currently testing on. I've found some issues with capemgr, that are minor if you know how to work around those issues, and you're very familiar with the beaglebone system in general. But . ..relaying this information would take a tremendous amount of effort for both of us . . . So my advice to you, for now would be to try and completely disable Universal IO, and load your overlays via uboot. Robert has made a couple of posts in the last week or so to a link on the elinux site that has instructions on how to do so. However, if you read the uEnv.txt file, you may be able to figure this out on your own. One thing I do not know for sure however, is how enabling specific board files the old way works when you're using uboot overlay loading. However, I do think there is a new method, commented out for disabling the eMMC too. On Wed, Apr 26, 2017 at 8:50 AM, ThomasL <[email protected]> wrote: > Edit: This was wrong. Using the config-pin scripts we got everything > working even at higher frequencies (30MHz). We are going to have a look at > the overlays later. > Op woensdag 26 april 2017 11:25:21 UTC+2 schreef ThomasL: >> >> >> Also, we presume that when using the cape-universala with pin config we >> are doing the toggles trough software with the bone-pinmux-helper instead >> of connecting register 30 to the output pads. We only get a toggle speed of >> around 2MHz which should be way higher if it was the PRU controlling the >> pin directly. >> >> >> -- > 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/d58b6891-5393-4a23-bf64-0636f03e0433%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/d58b6891-5393-4a23-bf64-0636f03e0433%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/msgid/beagleboard/CALHSORre7UBAGZMXn7J3np4znS_oJk0auM-J8EvLH-sEo5RaFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
