> Sorry, I'm still a bit lost here ;). > How do I see the PRUSS kernel patches that you have picked up?
Okay for v4.19.x & v4.20.x, i've picked up RFC 1: (I need to backport the am33xx-l4 dts changes to then backport RFC2..) https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.20/patch.sh#L382-L392 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss from : https://lkml.org/lkml/2018/11/22/948 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/remoteproc from : https://lkml.org/lkml/2018/11/26/319 and we needed: https://lkml.org/lkml/2018/12/2/361 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.20/patches/drivers/ti/pruss-from-v4.14.x-ti For 5.0.x/5.1.x: I've picked up RFC 2 directly from your git tree: https://github.com/rogerq/linux/commits/for-v5.1/pruss-2.0 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0/patches/drivers/ti/rogerq_pruss https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.0/patch.sh#L352-L379 > > >> All upstream PRUSS series that I posted will not work without changes in > >> the resource tables in pru-software-support packages. > >> > >> e.g. > >> https://github.com/rogerq/pru-software-support-package/commit/6346adba63c1e91414df8f3ea3cd73ccc40d0f2f > >> > >> If you can wait for 2 weeks then we could have something in > >> TI 2019 that should work smoothly. > > > > So around the time that your first RFC came out, we actually added > > that repo by default under /opt/source/ so users could test out your > > patchset on the beagle default images: > > > > https://github.com/RobertCNelson/omap-image-builder/commit/edd84bc5c2d925d67d00d0c2008f48cdd75e3e99 > > > > So any Stretch/Buster/Bionic image after Nov 24 2018, has your repo > > installed by default in the root file system. ;) > > OK. But I haven't fixed all examples as I wasn't sure if the changes that > I'm making will be accepted or not. I assumed that repo would be a work in progress, it was more to make it easy for pru users to give it a quick test and give some feedback > Suman has insisted that he wants to continue using the old resource table > format > for TI's 2019 release. > > What do you think is the best approach to take? I think what TI has been doing with pru-remoteproc just isn't working... To give you some perspective on what users of this forum have dealt with: TI's "changed" the pru-remoteproc interface/etc for end users in every TI kernel: From v3.14.x-ti, v4.1.x-ti, v4.4.x-ti, v4.9.x-ti, to v4.14.x-ti.. It's really Painful.. Whereas the uio interface is compatible all the way back to our ancient 3.8.x based kernel.. and yes the uio driver isn't perfect, secure, etc.. So yeah, we will make what every you guys do in v4.19.x-ti as the default for our "v4.19.x-ti" kernel, but just note, there is a big user base, that won't care and will just use the uio interface in real designs and products. Unless "SOMETHING" goes mainline, then the user base doesn't have to worry about it changing on every release. > I would suggest. > -Get PRUSS kernel drivers via ti-linux-4.19.y That's the default plan.. > -Switch pru-software-package to use > git://git.ti.com/pru-software-support-package/pru-software-support-package.git That also the default ;) It's actually packaged into a deb package.. using git of: df5794ce7611f8587950f491ef9bf11807e1d0cf https://github.com/rcn-ee/repos/blob/master/ti-pru-software-support-package/version.sh 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjT3PRvCd2eQS%2BLn%3DVedqFJChx6JcAZn3dDM5_YrwfSSg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
