Where is /opt/scripts/tools/update_kernel.sh now (for installing libpruio)

General Discussion
1

I’m trying to install libpruio but have fallen at the first hurdle.

It uses /opt/scripts/tools/update_kernel.sh to install a ‘bone’ kernel instead of a ‘ti’ on and there is no longer a /opt/scripts/tools/update_kernel.sh. So what should I do?

2

Quick Edit, libpruio is installed with every image/kernel/release going back a few years. :wink:

It get’s installed with the meta-package: [ARMHF] Debian 10.x/11.x/12.x Kernel Updates

since you didn’t mention a specific verison, i’ll just use 5.10.x:

sudo apt update
sudo apt install bbb.io-kernel-5.10-bone

this runs:

Package: bbb.io-kernel-5.10-bone
Section: metapackages
Architecture: armhf
Pre-Depends: linux-image-5.10.199-bone77,
Depends: ${misc:Depends}, bbb.io-kernel-tasks (= ${source:Version})
Recommends: libpruio-modules-5.10.199-bone77
Description: BeagleBoard.org 5.10-bone for am335x
 This metapackage will install linux-image-5.10-bone for am335x in Debian.

Which pulls in libpruio-modules-5.10.199-bone77

Like i said, just used 5.10.x as an example…

Regards,

3

Thanks Robert, I have bbb.io-kernel-5.10-bone kernel installed now.

I’m still finding libpruio a bit of a handful but I’ll start another thread as it’s not directly got anything to do with the kernel installation now.

4

The

package provides the loadable kernel module (a helper for pin-muxing and PWM synchronisation) only. The binaries from libpruio are not included!

Regards

5

I’ve been looking into the documentation libpruio: Main Page as a result of your post Beaglebone Black PRU to ARM High Speed Data Transfer - #14 by DTJF …

Am I correct that there is not any discrete PRU programming in this paradigm, but that the ARM program (‘c’, python, basic?) invokes library code that run on the PRU?

There is not much that I’m sure about with your project, but I am sure that it is unlikely that I will endure the pain to build it. other than the above link, I read several topics outlining difficulty getting the environment set up.

My own bias is NOT to chase the latest images from the worthy @RobertCNelson but to stick with one that I am familiar with. Unless I need a new feature unavailable on an image that I am using, I’m content to stick with an older image. My BBBs are not near the perimeter of my network, and I don’t worry too much about them being compromised. This strategy also has flaws.

Have you considered posting an image that has libpruio set up and ready for your examples? I ask out of sincere ignorance, I don’t know whether posting an image is a good idea or not.

gomer

6

libpruio is an ordinary DLL (like GLib or cairo). You compile your code against that lib, running on the ARM. Depending on your API calls the lib loads and executes code on one PRU. The other PRU is free for your custom firmware. When full-configured, the lib can do even pin-muxing from user space (no cape-universal or config-pin necessary).

Me too! I did some packages for a while, but the kernel and the distro is changing too fast. I’m a developer, not a package manager. It takes too much time to hunt a moving target.

Years ago, I created an IMG for a user at the other side of the world. The upload (>300MB) took more than 27 hours and abandoned at 90+%, so I had to restart it. Sorry, my environment is not designed for that kind of work.

Regards

BTW: Does anybody know how to shrink a dd disk image to its minimal size (in order to burn the 2.5GB content from a 32GB card to lets say a 4 GB card)?