> On Jun 25, 2016, at 7:45 PM, Rick Mann <rm...@latencyzero.com> wrote: > > Doesn't it "discover" devices by looking at the device tree? Ideally, yes, but Robert said there is a conflict when both frameworks are built in the same kernel. Currently, both frameworks are not built into the kernel and both are configured as Loadable Modules. Also, it should be possible to have a separate Devicetree for each framework, but with the build conflict Robert is unable to do this at this time. My understanding is this is why the “bone” kernel exists. If Robert is able to resolve the build conflict, then is the “bone” kernel even necessary? Remember, the “ti” kernel is not just for the BBB, but also for the BeagleBoard-x15 so the RemoteProc/RPMSG is required to support the DSPs and CortexM4s, so kill the idea that RemoteProc/RPMSG is going away, it just isn’t. There is no pruss_uio equivalent for the DSPs or CortexM4s. Even more important, TI have even bigger processors that have 4 Cortex-A15 ARM cores and 8 DSPs and the same “ti” kernel is used for that processor.
Hopefully Robert can chime in on this issue and clear up this issue. Regards, John > >> On Jun 25, 2016, at 18:32 , John Syne <john3...@gmail.com> wrote: >> >> Think about what you are proposing. When the kernel loads, it discovers >> devices and then loads the appropriate drivers. Now what happens when it >> discovers the PRU, which driver does it load, PRUSS_UIO or RemoteProc? >> >> Regards, >> John >> >> >> >> >>> On Jun 25, 2016, at 6:11 PM, Rick Mann <rm...@latencyzero.com> wrote: >>> >>>> >>>> On Jun 25, 2016, at 14:44 , John Syne <john3...@gmail.com> wrote: >>>> >>>>> On Jun 25, 2016, at 2:20 PM, Rick Mann <rm...@latencyzero.com> wrote: >>>>> >>>>> >>>>>> On Jun 25, 2016, at 12:56 , John Syne <john3...@gmail.com> wrote: >>>>> >>>>>>> On Jun 25, 2016, at 11:56 AM, Jason Kridner <jkrid...@beagleboard.org> >>>>>>> wrote: >>>>>>> >>>>>>> I will work to enable uio_pruss functionality, and I think that is what >>>>>>> you want, not just getting remoteproc out. >>>>>> >>>>>> Please don’t do that. Robert Nelson has the “bone” kernel for this >>>>>> purpose which supports pruss_uio by default and does not have >>>>>> RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, >>>>>> with the RemoteProc/RPMSG installed by default and pruss_uio no >>>>>> installed. I believe the two frameworks conflict so it is not possible >>>>>> to have both installed. >>>>> >>>>> It sure seems to me that if both can exist in the source tree and be >>>>> selected at runtime with configuration (ideally via device tree, >>>>> switchable later by loading and unloading modules), that would be the >>>>> ideal solution. It sounds like John is saying this is technically not >>>>> possible, but I feel like it should be (it is just code, after all). >>>> If you read the discussion, TJF and William don’t want to build a custom >>>> kernel. So since you cannot have pruss_uio and RemoteProc/RPMSG, >>>> configured simultaneously, this is the dilemma we are facing. Currently >>>> Robert Nelson has configured the “bone” kernel to have pruss_uio dn the >>>> “ti” kernel to have RemoteProc/RPMSG. William is concerned that the “ti” >>>> kernel has more features than the “bone” kernel. Solution is to ask Robert >>>> Nelson to add the missing features to the “bone” kernel. >>> >>> I'm not sure specifically what's preventing the two from being configured >>> simultaneously, so long as both their code doesn't execute simultaneously. >>> It seems one or the other or both can be modified to coexist in the >>> configuration, and that may be the best way to ensure the kernel supports >>> all users. >>> >>> We have the source, it should be possible. The kernel can support multiple >>> ethernet drivers configured simultaneously, why not multiple PRU drivers? >>> >>> -- >>> Rick Mann >>> rm...@latencyzero.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 beagleboard+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beagleboard/19C6420A-AF09-4542-B907-AD54429E56B4%40latencyzero.com. >>> 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/B5C4860B-52F9-485A-B268-65674695A127%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > Rick Mann > rm...@latencyzero.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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/C7759943-C3C3-475D-97E2-A57995AABEE1%40latencyzero.com. > 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/3A1B151F-494F-4865-A69A-39D33CED0298%40gmail.com. For more options, visit https://groups.google.com/d/optout.
