A bit of additional information that I left out unintentionally. I think the debian image I am using is the first iamge where uboot overlay loading is enabled. So, if you decided to use uboot overlays you may have to go with a newer image.
The kernel im using is: *uname_r=4.4.55-ti-r94* And the image I used is: *bone-debian-8.7-console-armhf-2017-04-02-1gb.img.xz* Anything after this date I'm assuming has uboot overlay loading enabled. This is indeed a testing image, but so far aside from capemgr not working from the command line, and capmgr slots file not reporting what has been loaded. It seems to be very solid. I'm seriously considering putting this image to work in the field on 30ish live production systems. I'm that happy with it. On Wed, Apr 26, 2017 at 8:39 PM, William Hermans <[email protected]> wrote: > 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/ms >> gid/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/CALHSORqveprGOYaQzmHhRb24%2Bz-q9fPGz9C48RUr_-1Bpi6bwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
