On Mon, Sep 28, 2015 at 10:03 PM, William Hermans <[email protected]> wrote: >> actually PRU uio is only broken in ti's v4.1.x branch.. as the >> remoteproc_pruss driver isn't upstream yet, you can renable uio_prus >> in v4.1.x-bone/v4.2.x-bone/v4.3.x-bone i've intentionally disabled it >> in those branches just so users don't get to use to it.. > > > I'd like a say in that matter myself. e.g. distinctive *bone*, and *ti* > kernels. But I suppose that a kernel config option that can be changed later > to something else ?
*ti* = whatever ti.com want's to push, plus our overlay patches on top to make it useful. ;) *bone* = mainline + overlay... > Here is the problem I'm seeing with being forced to move to remoteproc. > Documentation on the web completely sucks. Essentially, it's limited to a > linux/Documentation/*.txt file. Which to me did not seem very informative. > For me though, I tend to understand better if there is a working example. > Setup, and all that. Then I can actually learn as I tinker with this > example, and read the documentation bit by bit. > > In the end, I think remoteproc seems like very cool software technology. > However, if there is limited to no documentation on the subject. Then it > pretty much is useless . . . I've already seen several blog posts concerning > the BBB, and remoteproc. They all seem to be in a holding pattern, because > they can not seem to get things rolling. > > At least with using the PRU the "old way" we actually have something to work > with . . . Which is why we still have Elias Bakken's pru patches from 3.8 still in the tree.. Regards, -- Robert Nelson https://rcn-ee.com/ -- 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]. For more options, visit https://groups.google.com/d/optout.
