00:01 <Guest89> Thank you for your help

00:01 <zmatt> Guest89: the powervr drivers are packaged separately from the kernel, so if you update only the kernel then you may need to separately install the driver package... though if the kernel gets updated by a simple apt upgrade but the powervr module doesn't then that does seem like a bit of an oversight

00:01 <zmatt> btw in the future don't copy-paste multi-line output into chat, it's rather spammy... use a paste service like pastebin.com to share text

00:03 <zmatt> you can revert to your previous kernel, or more generally switch to any installed kernel, by changing the uname_r variable in /boot/uEnv.txt

00:03 <static_rocket> @Guest89:libera.chat: you can just fetch the current installed version of the kernel (something like `apt list --installed | grep kernel`) and select the corresponding um/km packages from `apt search sgx`. unfortunately i don't remember the package names entirely and I tend to avoid using apt so take this with a grain of salt

00:05 <zmatt> try apt-cache search -n "ti-sgx-.*$(uname -r)"

00:05 <Guest89> Hey I am willing & eager to learn.  What should I use instead of apt?  Back in the day I just used the BSD ports tree and built things I don't know best practices anymore

00:05 <static_rocket> i dislike debian's approach of having multiple kernel modules installed at once. good when everything's upstreamed and living with the kernel but it's a right headache for those stubborn few that like to live outside of the kernel tree

00:06 <zmatt> Guest89: apt would generally be preferred

00:06 <zmatt> unless you have strong opinions and know what you're doing

00:06 <zmatt> :P

00:06 <static_rocket> and of course apt doesn't make that process any *easier*

00:07 <zmatt> static_rocket: not sure what you mean honestly

00:07 <zmatt> static_rocket: I maintain out-of-tree stuff (including a custom driver) in my own fork of rcn's kernel repo and use its scripts to build custom debian packages

00:08 <zmatt> debian also has a thing that can automatically recompile out-of-tree drivers from source code whenever the kernel is updated, I forgot what it's called

00:08 <static_rocket> goofy dependency chains, inability to create proper package links when things need to move in lockstep, inability to specify when a package provides the same functionality as another (unless this has changed. i stopped playing with debian > 5 years ago...)

00:10 <zmatt> I _think_ Provides: now works with real package names, iirc... this is something I also ran into in the past

00:10 <zmatt> (and not just virtual package names)

00:10 <zmatt> but don't hold me to that, maybe I misremember

00:11 <zmatt> Guest89: what hardware are you using, an ai64 ?

00:11 <static_rocket> ah, well that is a step forward. i understand why they don't like that. it is hacky, but it's better than relying on multiple maintainers to hash things out and agree on a virtual target

00:11 <Guest89> zmatt  AI64.

00:12 <zmatt> Guest89: hmm, the kernel package has a Recommends: for the corresponding ti-sgx modules package

00:13 <zmatt> so I think it should have gotten installed when updating bbb.io-kernel-5.10-ti-k3-j721e .. but it might depend on how apt is configured

00:14 <Guest89> I am running "out-of-the-box" basically, and im totally willing to wipe/reinstall.   I bought this as a play/learning platform

00:15 <zmatt> try sudo apt-get --install-recommendsx bbb.io-kernel-5.10-ti-k3-j721e

00:15 <zmatt> whoops

00:15 <zmatt> try sudo apt-get --install-recommends install bbb.io-kernel-5.10-ti-k3-j721e

00:17 <Alex_BB> dpkg: error processing archive /var/cache/apt/archives/ti-sgx-j721e-modules-5.10.168-ti-arm64-r103_1bullseye_arm64.deb (--unpack):

00:17 <Alex_BB>  trying to overwrite '/lib/modules/5.10.168-ti-arm64-r103/extra/j721e/pvrsrvkm.ko', which is also in package ti-sgx-23.1-j721e-modules-5.10.168-ti-arm64-r103 1bullseye

00:18 <Alex_BB> but I notice thats not the path it complains about: Failed to load /lib/modules/5.10.140-00001-g69e7a81501b2/extra/pvrsrvkm.ko: No such file or directory

00:18 <zmatt> uhhhhhh

00:18 <Alex_BB> I need to update pvrsctrl?

00:19 <zmatt> no, hold on lemme see what's going on here

00:19 <Alex_BB> ok.  afk for a min

00:21 <zmatt> Alex_BB: btw I don't think you normally should have to use pvrsrvctl at all

00:24 <zmatt> but it does seem like a particular ti-sgx modules package is already installed for your kernel... I don't really understand why that's not the same one as what's Recommended: by the kernel package, or what exactly these different versions are

00:25 <zmatt> those packages should definitely have Conflicts: directives on each other if they're mutually exclusive

00:27 <Alex_BB> It might have been installed by the Imagination University .run file.  I am willing to start over if there is another recommended path.   I am using the demo located here https://university.imgtec.com/teaching-download/

00:28 <zmatt> oh I don't know anything about that, I'd suggest making sure to use whatever exact image they're using / saying to use and not perform any installation steps other than what's stated by them

00:28 <zmatt> in general the powervr drivers are extremely fussy and fragile to get working

00:31 <Alex_BB> If you could point me to a "Getting started" guide that works?  I just want to see how this AI thing works, then I want to break down the tools that make it work to see how it works, and so on. My knowledge of things is so out of date I am basically a noob again.

00:33 <zmatt> I'm sorry, I haven't worked with any of this.. I don't even own an ai64 yet, and last time I did anything with powervr drivers was quite a few years ago on a beaglebone black

00:33 <zmatt> the AI stuff has nothing to do with the imgtec/powervr stuff though I think

00:38 <Alex_BB> No worries I appreaciate the help.  Especially if you don't own one yet.   This is my first SBC and my first arm based computer (well, I do own a PSOC microcontroller).  I saw some interviews that emphasize Beagle's commitment to open source so I purchased one. I think its far more interesting to see how things work when there are no binary

00:38 <Alex_BB> blobs... I can follow the logic.  I think I started off on the wrong path for my goals...

00:39 <zmatt> Alex_BB: heh, and then you picked powervr as one of the first things to experiment with, which is one of the few parts that requires binary blobs

00:39 <Alex_BB> lol I know.

00:40 <zmatt> there's definitely something wonky about the powervr package though, I should poke rcn-ee about this

00:42 <Alex_BB> Another related URL (from when I asked them about the error)  https://university.imgtec.com/forums/nc-sdk/ncsdk-installation-question-from-our-user-answered/#post-1426

00:43 <Alex_BB> The dmesg output is no longer relevent (When I finally found a sdcard that worked, I was able to use the full image not the stock image updated as per "getting started" instructions

00:44 <zmatt> instead of updating an image right after downloading you can also just grab the latest snapshot image from https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots-arm64/32318

00:48 <Alex_BB> I had to find a sdcard that the kernel would like first.  I was getting error -110 upon insertion.  I finally went to BestBuy and bought the oldest/slowest sdcard on the shelf and it worked.

00:48 <zmatt> uhh, normally any card should work

00:48 <zmatt> -110 means it wasn't getting any response from the card... any chance it was just making poor contact or something?

00:48 <Alex_BB> On the beagleboard forums others have the issue too... recommendation was "try another one"

00:49 <zmatt> oh weird

00:50 <Alex_BB> Something wierd  in the newest cards.  Maybe with the U with a 3 inside doesn't work. The one that works is U with a 1

00:50 <Alex_BB> And its almost sure to be a kernel issue, since uboot does get the process started

00:50 <zmatt> the only thing I can think is that maybe it's negotiating some bus transfer speed that doesn't actually work reliably... if that's the case then presumably the dts just needs to be fixed to mark that bus transfer speed as unsupported

00:52 <Alex_BB> Yeah I tried troubleshooting that for too long.  I found a kernel.org thread even and double checked the patch they used was in the kernel lol I am stubborn sometimes.

00:56 <zmatt> I'm still looking at the various ti-sgx packages for arm64... https://pastebin.com/raw/sTgjWb78 there seem to be four driver versions, one unversioned (in the package name anyway), a 1.15, a.18, and... 23.1 (typo for 1.23 ??)

00:57 <zmatt> but like... why does the unversioned one have no firmware package? I guess maybe it's included with the ddx-um (the userspace libs)

00:57 <zmatt> more importantly, why do 1.18 and 23.1 have no -ddx-um for j721e, only for am62

01:01 <zmatt> you definitely need matching sgx driver version for modules + ddx-um + firmware

01:02 <zmatt> and modules obviously also matching the kernel version

01:05 <Alex_BB> You have given me things to look at.  I will spend some time trying to understand them later.  I really appreciate the apt-cache command you told me about earlier.  My knowledge was literally at apt update; apt upgrade.

01:08 <Alex_BB> I will leave this open but I am going to watch some tv with mom for now....  For those lurking who may be interested in the SD Card issue, one that does not work is the Gamestop 64gb card.  The SanDisk Ultra Plus does work.

01:08 <zmatt> so I think you somehow ended up with mismatched packages.. though I also think that the packages themselves should prevent that from happening through the use of appropriate package constraints

01:10 <Alex_BB> I really appreciate the help zmatt and static_rocket.   Thank you both

01:11 <Alex_BB> It might have been the "AI Demo" package that is hacky it might have installed the mismatched package.

01:14 <Alex_BB> My next plan will be start over and I will start with the /opt AI demos.  I will also try them before apt upgrade, which did update the kernel. Then I will try the AI Demo, again before updateing on-board packages.  Basically try things a step at a time and see if its just not working or if the update breaks things.

01:14 <Alex_BB> Have a great afternoon and happy mothers day to any mothers out there.

17:54 <mattb0ne> does the beagle have any hw component that makes driving a stepper with a pulse strain easier

17:56 <mattb0ne> I was driving a stepper from python toggling a low high signal but I want to make a real fast pulse train from the PRU

19:36 <zmatt> PRU would be the most obvious choice yes

19:37 <zmatt> there's also hacks you could do with a PWM output, but that would be more complicated and less reliable than just using PRU

19:39 <zmatt> there's lots of ways to generate signals really, now that I think about it

19:53 <mattb0ne> just to be clear using the EHRPWM is using the PRU

21:39 <zmatt> didn't you stop using the encoder, hence you got a spare pru core?

21:40 <zmatt> otherwise it depends on the timing constraints whether or not you can successfully combine the tasks on one core

21:40 <zmatt> your pru core is currently mostly idle, waiting for the next load cell measurement