On Thu, Sep 20, 2018 at 2:26 PM TJF <jeli.freih...@gmail.com> wrote: > Hi Jason! > > We already had such questions regarding upstream Debian four years ago > in 2014. I'm still waiting for your answers. >
Guess I'll search for it. Found a bit of info on your site, but I'll try to go back and find the queries. Going back as far as I can, I found https://groups.google.com/d/msg/beagleboard/lzJge-08T9s/HnPTZ82nLCYJ. Looking newer than that, I see a lot of queries, but it seems to me Robert has been pretty good at answering. If you can provide any hints that will help my search and get you answers, I'd be appreciative. > > And you moved my project page > > > https://beagleboard.org/p/tjfr-wordpress-com/libpruio-0-2-fast-and-easy-d-a-i-o-b9f5c8 > > from wordpress.com to hackster.io, without asking for my agreement. > There was a mass migration from the old project pages to hackster.io via a script. The main purpose is to give a place for people to discover the projects and point them to the real source for details, rather than actually take the attention away. BTW, the projects were never on wordpress.com, they were on beagleboard.org, and wordpress.com was simply used as one of many OpenID provider options. Maintaining the editable pages on beagleboard.org itself had become a logistical nightmare as quality support for OpenID has waned at all the key service providers even as the technology itself had changed. My older support libraries could no longer support the handful of providers that still exist. I believe hackster.io has a method for offering a recourse, but, fundamentally, this is your information and you just need to be able to control it. Sorry for not keeping that access/control in your clear view. Seems you have found recourse here and now on this forum. I'm committed to making this right. I'll take it down or replace it with whatever you see fit in regards to your project. > More than six month I tried to get back access to my own webside, > before I gave up. I'm still not able to update the informations on that > page. > Sorry it was so hard to get my attention. I try to make myself available via http://beagleboard.org/about and some people grab my attention at times via #beagle on IRC, but e-mails frequently escape my view are are closer to blind luck if I actually see them. I promise this isn't personal, but I do get several hundred e-mails a day and I try to scan the subject lines as best I can. This project page can be put in your name if you create a hackster.io account... not sure if that is something you want to do. Again, I wanted it to all be OpenID so that you could maintain your own credentials/identity, but the support has become too hard for it. I will credit you and provide content however you see fit in regards to your project. > > So why should I answer your questions now? OK, other readers may be > interested in that topics as well and I wont operate at your level: > That seems a bit harsh. Helping the other readers is indeed the point, so glad we are at least of the same mind in that regard. > > > Am Donnerstag, 20. September 2018 18:14:53 UTC+2 schrieb Jason Kridner: >> >> Few feature queries: >> >> Does the current version support remote proc? >> > > Does rproc support libpruio requirements? rproc is designed for > entertainment: for playing music or for simple data logging tasks. In > contrast libpruio targets hard realtime requirements for closed loop > controllers. The rpmsg methods are simply too slow for libpruio. > rproc is really just about putting the kernel in charge of the PRUs, rather than leaving it up to userspace. It provides an ELF parser/loader and sysfs entries for starting/stopping the processor, among other processor abstractions. Memory (/dev/mem) mapping of PRU shared memories is still completely possible in an rproc environment. There is no explicit need to utilize rpmsg. Still, the permissions issues could be a bit different. With UIO, the memory mapping of the PRU is exposed explicitly for that peripheral and the permissions on access can be set for just that memory region. No one has yet created a UIO/memory driver that exposes the PRU shared memory while running the rproc driver, though nothing should prevent that. The Linux upstream maintainers seem to have a preference for rproc which is why I tend to recommend it. "Just works" is great, but "leverages community" is also great. > > >> Does it require superuser/root execution? >> > > Please read the descriptions again. It depends on the need for > pinmuxing and the system configuration. No pinmuxing -> no root > execution. In case of pinmuxing several methods are supported: > config-pin, universal device trees or LKM. The device tree solutions > (including config-pin) need root privileges. In contrast the new LKM > solution provides single source pinmuxing access from user space for > all members of system user group 'pruio'. > >> >> Is it in the main rcn-ee package feeds? >> >> Thought about getting into upstream Debian? >> > > libpruio is a hardware driver for AM335[89] CPUs, so we're talking > about Beaglebone Debian. Four years ago I asked for your help. Today I > found my own solution and do not care any longer about that issue. The > project is open source, so feel free to download the source tree and > build your packages for upstream Debian. Or just copy the already built > packages. The users would appreciate that, but they can handle Arend > Lammertinks PPA solution as well. > My neglect clearly touched a nerve. It was never intentional or personal. This announcement clued me into your continued development and support of this library. If existing users are happy, I'd love to see more Beagle users discover and make use of it. I know the project entry changed hosts without your knowledge, but my sniff test of packaging your library into Robert's package feeds without contacting you smelled a bit funny. If you don't mind and, as you seem to, agree it would be helpful to users, I can check if Robert will add it to https://github.com/beagleboard/repos. Seeing where we are at, we should probably get over that hurdle before trying to talk to upstream Debian maintainers. > > At least the LKM in upstream Debian would be a great help for the > users, since in case of PPA it needs dkms re-compilation for each > kernel update (and > 30 MB linux-headers in order to re-compile 4 kB > code to a binary that doesn't change). > I'll interpret this to mean the BeagleBone kernel images used in the Debian reference images. Having https://github.com/DTJF/libpruio/tree/master/src/lkm pre-built into the distributed kernels does indeed seem helpful. The config-pin setup should be fairly well-deployed now. I'm curious if the pinmux helpers will interfere with this module. Guess we can try. Thanks again for the cool project and hope the frustration subsides. > >> >> On Sep 20, 2018, at 6:24 AM, TJF <jeli.f...@gmail.com> wrote: >> >> >> >>> <http://www.google.com/url?q=http%3A%2F%2Fusers.freebasic-portal.de%2Ftjf%2FProjekte%2Flibpruio%2Fdoc%2Fhtml%2Fpruio_logo.png&sa=D&sntz=1&usg=AFQjCNGRecvlbz-UcGB92KG6AqZz9Za8Lg> >>> >> >> Major highlights: >> >> - PRUSS functions exported now >> - New examples pruss_add (interaction between ARM and PRU) >> >> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruAdd> >> - New example pruss_toggle (up to 100 MHz pin toggling) >> >> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle> >> >> Find >> >> - more info in the docs, >> >> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaChangelog.html> >> - the source tree on GitHub <https://github.com/DTJF/libpruio>, and >> - the install instructions (debian package >> >> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPreparation.html#SecDebPac> >> or self-compiled from source tree. >> >> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPreparation.html#SecSourceTree> >> ). >> >> -- >> 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 beagleboard...@googlegroups.com. >> >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/40e7169e-cd77-4180-9f9f-057ad534e10f%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/40e7169e-cd77-4180-9f9f-057ad534e10f%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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/76724c23-79da-45cf-8247-3b4c6f3026c6%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/76724c23-79da-45cf-8247-3b4c6f3026c6%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- https://beagleboard.org/about -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPme9tgfx1Lm675A63UcwXQdoAK8Mzq1Ox%2BV%3D0tYcxGvTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
