**** BEGIN LOGGING AT Mon Mar 14 02:59:57 2022 Mar 14 09:33:41 Hi all, I was wondering if anyone could help me. I have a BeagleBone Green Wireless with Grove Base Cape v2. I was was working on cloud9 (I had run an apt-get upgrade a few minutes prior and was currently looking at directory contents) when suddenly the connection dropped and failed to reconnect. I noticed that the device is no longer listed under Mar 14 09:33:41 my laptops available wifi connections. I've tried unplugging the device and starting it again and double-checked the antennae were secure. It doesn't seem to work. Has anyone encountered a similar problem like this or could point me in the right direction? Mar 14 09:34:19 uhh, did the apt upgrade complete successfully? Mar 14 09:35:21 No Mar 14 09:36:35 The update returned a  Failed to fetch http://ppa.launchpad.net/deadsnakes/ppa/ubuntu/dists/jessie/main/binary-armhf/Packages 404 Not Found Mar 14 09:36:52 and when i tried to upgrade I had a bunch of errors Mar 14 09:36:55 jessie is very ancient and unmaintained Mar 14 09:37:16 wait, what's that weird path anyway Mar 14 09:38:06 and jessie is a debian dist, not ubuntu Mar 14 09:38:52 define "a bunch of errors" ? Mar 14 09:40:01 let me guess, it was a huge upgrade (lots and lots of packages) and you ran out of disk space during installation? Mar 14 09:40:34 dpkg: error processing archive /var/cache/apt/archives/bonescript_0.6.1-0rcnee1~bpo80+20170301_armhf.deb (--unpack): Mar 14 09:40:34  trying to overwrite '/lib/systemd/system/bonescript-autorun.service', which is also in package bb-bonescript-installer-beta 0.5.0~beta7-0rcnee1~bpo80+20160526+1 Mar 14 09:40:35 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Mar 14 09:40:48 Errors were encountered while processing: Mar 14 09:40:49  /var/cache/apt/archives/bonescript_0.6.1-0rcnee1~bpo80+20170301_armhf.deb Mar 14 09:40:49 E: Sub-process /usr/bin/dpkg returned an error code (1) Mar 14 09:40:57 please don't paste into chat Mar 14 09:41:01 use a paste service like pastebin Mar 14 09:41:11 Ah my bad Mar 14 09:41:19 sorry Mar 14 09:41:21 what image version is this? Mar 14 09:41:25 are you actually running jessie? Mar 14 09:42:40 it sounds like bonescript should have had Conflicts and Replaces bb-bonescript-installer-beta probably Mar 14 09:42:41 I think so - I ran lsb_release -a and it said I was running Debian GNU/Linux 8.11 (jessie) Mar 14 09:43:01 yeah that's really ancient and unmaintained Mar 14 09:43:24 Ah okay Mar 14 09:43:25 like, my suggestion would have been to backup any files of importance and just reflash the system to the latest image Mar 14 09:44:07 Okay great. I'll do that. Thanks for your help :) Mar 14 09:44:08 now that the system has been hosed by a failed upgrade... well my advice is still the same, except backing up files of importance has been made more difficult Mar 14 09:44:39 so hopefully you don't have any, but if you do you'll need to boot from sd card and mount the emmc to rescue files from it Mar 14 09:44:42 I haven't got anything important thankfully. Mar 14 09:44:46 that makes things easy Mar 14 09:45:19 download the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" from the Flasher Debian images section here https://beagleboard.org/latest-images Mar 14 09:46:49 write to SD card using Etcher, boot the beaglebone from it and it should automatically proceed to reflash the eMMC Mar 14 09:47:11 Great thank you. Will try that now Mar 14 09:47:33 since your current system is ancient, to get it to boot from the sd card you probably need to power on with the S2 button held down (the button closest to the μsd card slot), you can let go of the button once any led turns on Mar 14 09:48:42 (this is normally not required to boot from sd card, just when there's a serious mismatch between the system on sd card and the bootloader on eMMC) Mar 14 10:22:38 Hello hello, Mar 14 10:22:38 I wanted to ask if you still have beaglebone green wireless boards in stock and if not, when they should be available again. Mar 14 10:23:54 that's a question to ask distributors... this is a community chat Mar 14 10:25:37 👍 Mar 14 14:33:42 Hi, Some GPIO pins need to be exported for accessing. That can be done using "echo 'export' > ". I would like to export those pins during boot-up, Is any way to do it other than with a script ? Mar 14 14:46:05 Hi Stuck with IRQ vring not found on 5.10 kernel for pruss on Beaglebone AI Mar 14 14:47:02 bbai:~/pruFW# echo start > /sys/class/remoteproc/remoteproc6/state Mar 14 14:47:02 [ 653.889678] remoteproc remoteproc6: powering up 4b2b4000.pru Mar 14 14:47:03 [ 653.895629] remoteproc remoteproc6: Booting fw image am57xx-pru2_0-fw, size 65484 Mar 14 14:47:03 [ 653.903289] remoteproc remoteproc6: unsupported resource 5 Mar 14 14:47:03 [ 653.909027] pru-rproc 4b2b4000.pru: IRQ vring not found Mar 14 14:47:03 [ 653.914306] remoteproc remoteproc6: unable to get vring interrupt, status = -6 Mar 14 14:47:05 [ 653.921600] remoteproc remoteproc6: can't start rproc 4b2b4000.pru: -6 Mar 14 14:47:07 [ 653.928253] remoteproc remoteproc6: Boot failed: -6 Mar 14 14:47:09 -sh: echo: write error: No such device or address Mar 14 14:49:05 Tried to modify the DTS file based on Beagleboard kernel 4.14 with no luck. Mar 14 14:50:56 modified am57-pruss.dtsi based on kernel 5.16 to include pruss_intc so on but couldn't figure out the interrupt Mar 14 15:08:01 tigerxyz: normally all gpios are exported by default (if you're using cape-universal), if you're not using cape-universal then you can use an overlay to setup and export gpios Mar 14 15:09:06 tigerxyz: my overlay-utils project has an example: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi (note: overlay-utils uses different macros and makefile than bb.org-overlays) Mar 14 15:09:28 @zmatt : thanks Mar 14 15:13:27 AKN: it looks like am5729-beagleboneai.dts includes the wrong base dtsi Mar 14 15:13:44 AKN: replace #include "dra74x.dtsi" by #include "am5728.dtsi" Mar 14 15:14:38 Okay I tired include am5728.dtsi but pru firmware doesn't load up Mar 14 15:15:56 if that's true then it sounds like remoteproc-pru is somehow entirely broken on that kernel series Mar 14 15:16:00 rcn-ee: ping Mar 14 15:17:01 5.10+ ti changed the remote_proc again.. irq change.. Mar 14 15:18:09 v6.0.0+ is v5.10.x+ (and maybe mainline)... v5.9.0 and earlier is v4.14.x->5.4.x .. https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=summary Mar 14 15:18:37 okay, but how is that relevant? like, the relevant includes are part of mainline Mar 14 15:18:55 here's the commit with the changes needed. .. https://git.ti.com/gitweb?p=pru-software-support-package/pru-software-support-package.git;a=commit;h=868c247f89d7d0692752fd1278448b8b69aa959c Mar 14 15:19:04 or is it broken in mainline? Mar 14 15:19:26 so 5.10.x-ti should be really really close to what is in mainline today (v5.17.x)... Mar 14 15:20:11 ohhhh, they changed is in a way that requires the pru firmware to be changed? Mar 14 15:20:45 yeah I see now Mar 14 15:21:06 Sorry that I couldn't follow up Mar 14 15:21:22 other than that commit in that git repo, nothing else was really posted anywhere... Mar 14 15:23:17 rcn-ee: btw the bbai dts does need to be changed to #include "am5728.dtsi" instead of "dra74x.dtsi", just like am57xx-beagle-x15-common.dtsi does Mar 14 15:23:48 otherwise pruss never gets declared Mar 14 15:24:28 unless I'm blind Mar 14 15:25:00 considering the amount of pinmux changes i've had to do on the beaglebone-ai mainline dts to make it just boot...i don't think anyone's actually using mainline device-tree as is.. Mar 14 15:25:25 I'm referring to 5.10-ti Mar 14 15:26:13 i think it's the same in this too.. so am5728.dtsi brinds in dra74x.dtsi + am57-pruss.dtsi. so yeah i agree... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am5728.dtsi?h=v5.17-rc8 Mar 14 15:27:03 exactly Mar 14 15:27:18 AKN: short summary: that one line change (the #include) should be the only change needed in the dts Mar 14 15:27:34 AKN: the reason the pru firmware doesn't load is because TI made incompatible changes, the firmware needs to be updated Mar 14 15:27:40 and you'll be able to do a 'git pull' in a bout a minute.. to get it.. Mar 14 15:27:56 Okay than for compiling the PRU image I need to use new support package Mar 14 15:28:39 it looks like they changed all the examples, so you'll probably need to check what exactly they did and make a similar change in your own project Mar 14 15:29:07 AKN: both 5.9 and 6.0 are instalable in debian.. Mar 14 15:29:24 5.9 ? why 5.9 ? Mar 14 15:29:37 pushed... https://github.com/beagleboard/BeagleBoard-DeviceTrees/commits/v5.10.x-ti Mar 14 15:29:37 zmatt, rcn-ee: Thankyou Mar 14 15:29:47 some users are using remoteproc pre v5.10.x Mar 14 15:30:03 5.9 isn't even a -ti kernel, nor even LTS Mar 14 15:30:20 Sorry, that is "ti" pru software development numbres.. Mar 14 15:30:24 ahhhhh Mar 14 15:30:28 I was already confused Mar 14 15:31:27 AKN: sudo apt install ti-pru-software will bring in v6.0.1 of ti's git repo.. Mar 14 15:31:53 rcn-ee: if the changes are incompatible and kernel version dependent, shouldn't the package be explicitly versioned? Mar 14 15:32:01 like, ti-pru-software-v6 Mar 14 15:32:13 it is... i think i moved it to a different repo.. Mar 14 15:32:31 There we go... https://github.com/beagleboard/repos-armhf-ti-pru-software Mar 14 15:32:52 ti-pru-software-v6.0 -> replaces ti-pru-software Mar 14 15:33:11 ti-pru-software-v5.9 -> v4.14.x-ti -> 5.4.x-ti Mar 14 15:33:42 rcn-ee: Sure, Thank You. Mar 14 15:34:02 maybe put that in the package description? like "PRU Software Support Package for kernel versions ..." Mar 14 15:34:11 ps, everything is installed into a version folder structure... https://github.com/beagleboard/repos-armhf-ti-pru-software/blob/master/ti-pru-software-v5.9.x/suite/bullseye/debian/install Mar 14 15:34:29 so you can install both.. but then both include directores get exported to the enviroment.. Mar 14 15:34:49 I guess TI never got the memo of the kernel's "don't break underspace" policy? ;-) Mar 14 15:35:45 oh god... it's scary lately on un-released stuff.. they cleaned house a year and half ago... removing "remote" workers... Mar 14 15:36:15 they don't even have.. "don't break the release last month" policy.. Mar 14 15:36:43 lol Mar 14 15:37:19 we found a few random "git commits" not in git, in there Device Linux SDK Release binaries.. Mar 14 15:37:36 you know the *.bin you run to extract a sdk release.. Mar 14 15:37:46 maybe I should make an overlay to use uio-pruss on am57 and port libprussdrv, at least that's stable ;) Mar 14 15:38:29 actually, libprussdrv would probably work out of the box, but only for the first pruss instance Mar 14 15:38:32 uio is always stable... have you had to a chance to seee mainline change broke v5.4.x and later.. or are you still on v4.19.x for prodution? Mar 14 15:38:46 oh right, I should really do that Mar 14 15:38:53 we're still on v4.14 for production /o\ Mar 14 15:39:13 ah, your still good.. v4.14.x. is rock solid.. ;) Mar 14 15:40:13 I really should work on upgrading, and maybe see if any of the patches I've done might be suitable for mainline .. ( https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/local ) Mar 14 15:44:37 at the very least the one adding an eCAP clocksource driver should be mainlinable (giving the system time 10ns resolution, or 5ns when using the PRU eCAP, instead of 1/24 us resolution and slow clock drift due to the kernel using a fixed-point appropriation for the 1/24 ratio) **** ENDING LOGGING AT Tue Mar 15 02:59:56 2022