00:47 <set_> Over a two year span, this TensorFlow biz has been killin' me from the inside out. Now, I think I may have it handled. Updates abound!

00:54 <set_> and all b/c of the new build image I found on the forums!

00:54 <set_> Bullseye!

01:03 <set_> Now, about this unloading and using the EVEs/DSPs w/ a tensorflow-lite model. Blah. Are people still researching these ideas?

01:11 <set_> Phew...I found a DSP(s) notation on the tensorflow site under MCU. Anyway, off to read more.

01:45 <set_> Hello...are the GSOC people done w/ their ideas involving the BBAI and tensorflow? I just went to elinux and it seems that people are not advancing their ports. Is this a fact?

02:11 <rcn-ee> set_, GSOC was over last month.

02:25 <set_> Oh. Okay.

02:31 <set_> What was the outcome on tensorflow w/ images and TFLite on the BBAI?

02:34 <set_> rcn-ee: I see you changed the 'RE:' section to my question. I am learning slowly how searching helps others. Everything 'RE:' may not be what people research when looking up specific chats on the forums.

02:35 <set_> Anyway...good news here! TFLite builds on the BBAI w/out cross-compiling. Cross-compiling works but I am not sure exactly how to port it yet.

02:36 <rcn-ee> RE: = Reply....

02:36 <set_> So...in hindsight. I will stop the 'RE:' in questions on the forums, try to build TF on the Debian machine I have, and try to use TFLite on the BBAI. After all that is done, posting.

02:36 <set_> oh.

02:36 <set_> I thought it meant regards.

02:37 <set_> or regarding.

02:55 <set_> anyway...consider it stopped, ceased, expelled, and halted. No more 'RE:'.

13:04 <set_> Aw. Done! Now...I need to learn to offload the computational power of the tensor to the other slave processors.

13:05 <set_> But first...I have to go. Blah. Duty calls. See you all soon!

15:21 <giort> Hello! In the BBB System Reference Manual, on page 68, at the Extension connectors (P8, P9) pinouts, there are 7 different modes listed. How are these modes selected? Im running the py-uio pru examples, and pulse-train apparently generates a square wave on pin 31 of p9. However I cannot measure this signal.

15:53 <zmatt> giort: config-pin P9_31 pruout

15:54 <zmatt> (the other way is using a DT overlay, but runtime configuration using config-pin is easier)

15:54 <zmatt> doing it from python is possible as well: https://pastebin.com/MKtWJ8G8

16:53 <giort> Thanks zmatt, this is way better than creating a DT overlay. Only problem is, that there is no file for pin 31...

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_20_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_23_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_21_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_24_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_22_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_27_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_26_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_30_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_41_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_42_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_91_pinmux

16:53 <giort> drwxrwxr-x 3 root gpio 0 Oct 8 13:15 ocp:P9_92_pinmux

16:54 <giort> (I thought it would send it in one message, I will use pastebin next time)

16:55 <rcn-ee> P9_31 needs audio disabled, edit /boot/uEnv.txt

17:02 <giort> #disable_uboot_overlay_audio=1, is this the correct line?

17:05 <giort> thanks rcn-ee, I figured it out

19:42 <shodan45> is there a tl;dr for what happened/is happening with a risc-v board?

19:43 <shodan45> it sounds like the original plan fell through?

19:58 <vagrantc> wouldn't be surprised if international parts shortages and supply chain issues have something to due with major delays...

20:06 <zmatt> it's not delayed, it fell through

20:06 <zmatt> at least the first plan

20:08 <zmatt> dunno if there anything new with risc-v in the pipeline

20:08 <zmatt> *there's

21:40 <shodan45> aww :(

21:41 <shodan45> the site says they "hope to have a new BeagleV™ community board available early Q1"

21:45 <rcn-ee> zmatt, i might be doing something too... insecure.. can i bug you for a moment.. (Setting up a MTP file daemon to share /opt/mpt, /boot/, /etc/wpa_supplicant/, and /etc/systemd/network/...) USEFUL or Dangerous? ;)

22:00 <rcn-ee> MTP config: https://github.com/rcn-ee/repos/blob/master/bb-usb-gadgets/suite/bullseye/debian/bbb-umtprd.conf#L16-L19

22:35 <zmatt> rcn-ee: and what exactly would that do to file ownership and permissions?

22:36 <zmatt> and yeah it sounds questionable for people to mess with those files if they're unable to do so via SSH

22:52 <rcn-ee> zmatt, MTP allows you to edit those files on both sides...

22:53 <rcn-ee> ownership and permissions stay the same (root)

22:54 <rcn-ee> right now, i can open, but can't "save" a file on top of it's self..

22:54 <rcn-ee> but i can rename...

22:58 <rcn-ee> Here's a WIP example image: https://rcn-ee.net/rootfs/debian-armhf/2021-10-08/ so MTP gives us the usefulness of the USB Flash drive, yet the possiblty to edit files..

23:07 <zmatt> I'm not convinced of the usefulness of either