calculu5 has joined #beagle
calculus has quit [Ping timeout: 264 seconds]
GenTooMan has quit [Quit: Leaving]
calculus has joined #beagle
calculu5 has quit [Ping timeout: 264 seconds]
m-atoms has quit [Ping timeout: 252 seconds]
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #beagle
GenTooMan has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 264 seconds]
Guest60 has joined #beagle
Guest60 has quit [Client Quit]
vd has quit [Quit: Client closed]
vd has joined #beagle
waldo323_ has joined #beagle
waldo323__ has quit [Ping timeout: 264 seconds]
vd has quit [Quit: Client closed]
buzzmarshall has quit [Quit: Konversation terminated!]
ikarso has joined #beagle
Shadyman has quit [Remote host closed the connection]
giort has joined #beagle
giort has quit [Client Quit]
trinath has joined #beagle
<trinath> hi
trinath has quit [Remote host closed the connection]
trinath has joined #beagle
<trinath> hi
<trinath> Can i connect Mini PCIe or PCIe x1 to Beagle bone x15 expansion
trinathk has joined #beagle
<trinathk> hi
trinathk has quit [Remote host closed the connection]
<trinath> If anyone know, please comment
florian has joined #beagle
<trinath> Can i connect Mini PCIe or PCIe x1 to Beagle bone x15 expansion slot
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
<trinath> Ok bye
trinath has quit [Remote host closed the connection]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
starblue1 has quit [Ping timeout: 264 seconds]
starblue1 has joined #beagle
otisolsen70 has joined #beagle
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #beagle
<rcn-ee> zmatt, when you have a chance, your thoughts on: (systemd-networkd defaults)
<zmatt> so, if I understand correctly, by default systemd-networkd will use a pseudo-random mac address derived from the system's machine_id and identification of the interface, so that default may be perfectly fine
<zmatt> (for interfaces that do not have hardware-supplied or user-supplied mac address)
<rcn-ee> zmatt, 'same' address as we used before, it's just a mess of random shell scripts, i'll clean it up for bullseye..
<zmatt> if the mac address is set via the usb function configuration then I'm pretty sure systemd-networkd will not touch it (unless you explicitly override it using MACAddress, which would be a bad idea)
<zmatt> (and that's also the only way you can configure the remote mac address afaik)
<rcn-ee> So, i'm working on that usb stack still, the old script that setup's the dual interfaces is here: (we can specify both mac address on either side of the usb interface)
<zmatt> yeah, and doing it there is certainly better than doing it in a .network file
<rcn-ee> I really want to use the *.scheme file: but OS descriptos is broken on Windows 10 at the moment.. (this can also set the mac address on both sides..)
<rcn-ee> I;ll nuke: #MACAddress= from usb0/usb1*.network it was more of placeholder..
<zmatt> also, an argument could be made for setting update_config=1 in the wpa supplicant conf to open the possibility of making a friendly commandline tool for searching for and connecting to a wifi network (with update_config=0 it could still do that but it wouldn't be able to persist the settings)
<rcn-ee> zmatt, perfect, i didn't know that.. i'll change that.. i've really never used wpa supplicant con
<zmatt> I have some experience with scripting wpa_supplicant via dbus
<zmatt> (though unfortunately the dbus interface of wpa_supplicant is quite terrible)
<rcn-ee> zmatt, that would be helpful. ;) i kinda wish we could run this in a local server so users can directly edit it..
argonautx has joined #beagle
<zmatt> that seems unnecessarily annoying to use, compared to doing a scan, showing a list to select from, asking for password if necessary, and reporting whether it was able to connect successfully
<rcn-ee> something simple like that ^ would be nice.. ;)
vd has joined #beagle
<zmatt> I've written an incomplete but functional nodejs library for wpa-supplicant (example usage: ), but I'd need to ask my employer whether I can share it (and the dbus library it depends on)
<zmatt> oh ew I just looked at its (fairly old) code... I now wish I hadn't done that, lol
<zmatt> note btw that wpa_supplicant can also be configured fairly easily into AP mode
<zmatt> (you don't need hostapd for simple applications)
jkridner[m] has joined #beagle
buzzmarshall has joined #beagle
<rcn-ee> zmatt, i'm testing much simpler them my old mess.
<zmatt> yeah using an udev rule to create the interface is a good idea, although it should match on KERNEL=="wlan0", not KERNEL=="wlan*"
<rcn-ee> and on the "wl1835" module...
<rcn-ee> our bbai "cypress" needs a different mode.. but yeah, short and simple AP enablement..
<zmatt> and like I said, you don't need hostapd, wpa_supplicant can do the job
thinkfat has joined #beagle
<zmatt> hmm, how did multiple interface configuration work without using dbus...
thinkfat_ has quit [Ping timeout: 252 seconds]
<zmatt> oh right that requires a custom service file that specifies the config file per interface, *sigh*
<zmatt> I think AP mode using wpa_supplicant is something like this:
<rcn-ee> I'll give that a shot, that would make things very simple for users to configure
M-blaise has quit [Ping timeout: 246 seconds]
<zmatt> this is what I did
thinkfat has quit [Ping timeout: 252 seconds]
thinkfat has joined #beagle
florian has quit [Quit: Ex-Chat]
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
thinkfat has quit [Ping timeout: 252 seconds]
the_person48 has joined #beagle
<the_person48> hey guys, just a heads up, I updated the uboot loader and it fixed the problem with P8.03 not showing up in /dev/gpio
<the_person48> thanks for the help!
the_person48 has quit [Quit: Client closed]
charlie5 has quit [Ping timeout: 264 seconds]
charlie5 has joined #beagle
lucas_ is now known as lucascastro
argonautx has quit [Ping timeout: 252 seconds]
argonautx has joined #beagle
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
Guest1566 has joined #beagle
<Guest1566> beaglebone ai graphics drivers? Are they available anywhere?
<rcn-ee> Guest1566, 2d or 3d?
<Guest1566> 3d, the powervr drivers
<rcn-ee> Guest1566,;a=summary
behanw has quit [Quit: Connection closed for inactivity]
<Guest1566> are they available in binary form via apt-get like on the beaglebone black?
<rcn-ee> Guest1566, i never converted them..
<rcn-ee> Guest1566, the "deb" just basicliy ran the default Makefile:
<rcn-ee> Guest1566, jacinto6evm is build name for the bbai in that Makefile..
<Guest1566> Okay thanks. Those are the usermode drivers, how do I get the kernel mode driver? pvrsrvkm.ko I think
<Guest1566> As I recall on the beaglebone black, matching up the right user mode and kernel mode drivers was painful.
<rcn-ee> kernel module is pre-installed. ;)
<rcn-ee> are you using our debian image?
<rcn-ee> otherwise they are here:;a=summary
<Guest1566> Debian Buster IoT TIDL Image 2020-04-06
<Guest1566> debian@beaglebone:~$ lsmod | grep pvr
<Guest1566> debian@beaglebone:~$ dmesg | grep -i pvr
<Guest1566> debian@beaglebone:~$
<Guest1566> not preinstalled on this version?
<rcn-ee> "" auto installs the sgx module...
<rcn-ee> apt install ti-sgx-jacinto6evm-modules-`uname -r`
<rcn-ee> should install it..
argonautx has quit [Ping timeout: 260 seconds]
giort has joined #beagle
giort has quit [Client Quit]
vd has quit [Quit: Client closed]
<Guest1566> Okay had to depmod -a after installing the package to be able to modprobe the module. Now to get the user mode drivers working...
<Guest1566> After git clone git:// what branch to I check out?
<rcn-ee> which kernel v4.14. or v4.19?
<Guest1566> 4.14.108-ti-r131
<Guest1566> either or, I can switch to 4.19
<rcn-ee> 1.14.3699939
<rcn-ee> 4.19 was 1.17.4948957
<rcn-ee> i'd try: ti-img-sgx/rocko/1.14.3699939 first
<Guest1566> This repo has lots of those branches:
<Guest1566> remotes/origin/infoadas/1.14.3699939/k4.4
<Guest1566> remotes/origin/infoadas/1.14.3699939/next
<Guest1566> remotes/origin/ti-img-sgx/1.14.3699939
<Guest1566> remotes/origin/ti-img-sgx/1.14.3699939_k4.4
<Guest1566> remotes/origin/ti-img-sgx/1.14.3699939_k4.4_vision_sdk
<Guest1566> remotes/origin/ti-img-sgx/morty/1.14.3699939
<Guest1566> remotes/origin/ti-img-sgx/rocko/1.14.3699939
<rcn-ee> remotes/origin/ti-img-sgx/rocko/1.14.3699939
<Guest1566> I'll try rocko first, but is there any rhyme or reason to the strange naming?
<rcn-ee> rocko = yocto release cycle..
<rcn-ee> 1.14.3699939 is a random img drop..
<zmatt> I'm guessing the 3699939 is like an svn commit number or something like that
vd has joined #beagle
calculu5 has joined #beagle
calculus has quit [Ping timeout: 264 seconds]
<Guest1566> Thanks for the info. running eglinfo has errors though. I had to do the following first:
<Guest1566> apt-get install libgbm1
<Guest1566> ln -s /usr/lib/arm-linux-gnueabihf/ /usr/lib/arm-linux-gnueabihf/
<zmatt> that's a recipe for misery
<Guest1566> Which in particular?
<zmatt> you should not have any mesa packages installed
<zmatt> it'll just create conflicts
<zmatt> the reason the .so library version number is different from what it's expecting is because what it's expecting is not compatible
<Guest1566> so what is the proper way?
<zmatt> so, I haven't tried on the am572x, but here's a post I wrote getting the 1.14 drivers working on am335x: though this is quite old (kernel 4.9) and I haven't updated my repos since 2017, at least it shows the ingredients
<zmatt> but long story short, you need ti's libgbm
<Guest1566> Thanks for the link. Well read it, but the end result I'm looking for is Qt on top of EGL.
<zmatt> yeah that should just work
<zmatt> once you have the libraries working
giort has joined #beagle
<zmatt> (I had to patch qt5base to support the 16-bit framebuffer used on beaglebone black, but that problem doesn't exist on the bbai and I think qt5 has also been fixed anyway)
<Guest1566> I forgot to start the server: /usr/bin/pvrsrvctl --start --no-module. Now elginfo works using my symlinkged gbm.
<Guest1566> However, I want to address this missing
<zmatt> I'm surprised it works at all but maybe eglinfo doesn't result in any actual calls to libgbm
<Guest1566> The package I installed: buster/main armhf libgbm1 armhf 19.1.6-1rcnee2~buster+20200513
<Guest1566> Is not correct?
<Guest1566> Do I need to build instead?
<zmatt> hmm, oh it's a libgbm built by rcn rather than the mesa one?
<Guest1566> Seems to be.
<zmatt> Guest1566: it might be better to just use TI's rather than my forks thereof which haven't been updated in years
<rcn-ee> Guest1566, our hacked version should work..
<zmatt> it doesn't have the right .so version though
<zmatt> I have a vague recollection that TI switched back to using so.1 for the 1.17 drivers? I might misremember though
<zmatt> anyway, if this is a TI libgbm then it might works fine with a symlink
<rcn-ee> ian debugged it..
<rcn-ee> err damnit... i only built it for stretch..
<zmatt> so what's that package he installed?
<rcn-ee> mesa's version..
<rcn-ee> libgbm head is meas..
<Guest1566> How do I get the right libgbm2 then?
<zmatt> you could try mine
<zmatt> since you're using the same driver version as I used back in 2017
<rcn-ee> here's ti version...;a=summary
<zmatt> or that
<rcn-ee> zmatt, probally has build fixes..
<zmatt> looks like TI has two new commits since my fork
<rcn-ee> zmatt, am i doing this right... match my KERNELS and DRIVERS and it'll leave everything else alone?
<zmatt> their "Remove the unnecessary backends" sounds similar to my "remove unused crap"
<zmatt> and they added some new feature
<rcn-ee> "unnecessary" might be removing xorg support.. ;)
<zmatt> it never had xorg support
<rcn-ee> that too
<zmatt> regardless, that wouldn't be at this layer
<zmatt> this is lower-level
<zmatt> Guest1566: using TI's repo is probably the best choice
<zmatt> rcn-ee: uhhhhh
<zmatt> rcn-ee: line 3 doesn't do anything... it consists of match rules with no actions
<zmatt> also SUBSYSTEMS seems like a strange match criterium
<zmatt> that KERNELS seems wrong
<rcn-ee> i'd like to limit it to wl18xx_driver, added a new file to that gist..
<zmatt> not sure why yours is, on my bbbw here it's
<rcn-ee> 5.10.59-ti-r18.2
<rcn-ee> and the new sdhc driver after 5.5.x...
<zmatt> why not match SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan0", DRIVERS=="wl18xx_driver" ?
<rcn-ee> okay! that's why i asked .;)
<zmatt> especially since otherwise your rule will also match on your newly created ap%n interface
<zmatt> and I'd probably just write ap0 if matching specifically on wlan0 anyway
<zmatt> you'll want those specific names anyway for the wpa_supplicant .service file
<rcn-ee> okay, your last change tested on a two boards, wifi and non-wifi, next wpa settings. ;)
<zmatt> hmm, though if you're not going to have ap0 on every target with wifi that would complicate things
<rcn-ee> ap0 only showing up on wl18xx
<zmatt> you'd want ap0 to be handled by a different service... which doesn't preclude using wpa_supplicant (a separate process thereof) though it would prevent dbus-controllability of that second service
<rcn-ee> i need to match for wl18xx and brcmfmac.. wl18xx takes: "managed" brcmfmac takes "__ap"...
<zmatt> ah so ap0 will exist either way, the rule is just different?
<rcn-ee> exactly, just one variable.. i'm trying to specify the config option like you did with:
<Guest1566> So compiling that ti libgbm repo works with eglinfo. How would I *really* test it though?
<zmatt> kmscube (ti's branch thereof)
<rcn-ee> Guest1566, IMG's demo's should work too..
<zmatt> I vaguely recall at least one of those having never worked for me
<rcn-ee> Guest1566, they put this together:
giort has quit [Quit: giort]
Shadyman has joined #beagle
<rcn-ee> zmatt, can we trigger wpa_supplicant from: /etc/systemd/network/ ... if i enable it outright, it connects to wifi on a BBBW just fine, but on a non-wifi BBB we get to wait 2 minutes till wpa_supplicat times out..
<rcn-ee> i could add a depend on /sys/class/net/wlan0 for: /etc/systemd/system/ but that might be "too" hackisth?
<Guest1566> ./OGLES2Water: error while loading shared libraries:
<Guest1566> The libgbm I installed and compiled gave /usr/local/lib/
<Guest1566> The rcn libgbm1 package apparently is mesa. Though if I install it, the demo works.
<rcn-ee> cool
<Guest1566> Do I have a working set of libraries then?
<rcn-ee> for the AM57xx no...
<rcn-ee> my am335x one is here:
<Guest1566> So how do I get a working set of libraries for AM57xx?
otisolsen70 has quit [Ping timeout: 252 seconds]
<Guest1566> My qt app no worky either:
<Guest1566> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-debian'
<Guest1566> Could not initialize egl display
<Guest1566> Aborted
<zmatt> do not have _any_ mesa packages installed
<zmatt> you will get crashes
<zmatt> (that includes the libgbm1 package)
<Guest1566> No the problem this time is that qt packages install a whackload of stuff and one has overwritten one of the ti libs. I remember this problem from playing with the bbb back in June.
<Guest1566> It probably is a mesa package too. I'll have to check my notes.
<zmatt> back when I did this qt5 packages did not depend on mesa
<zmatt> or
<zmatt> oh
<zmatt> wait
<zmatt> they did, I created my own debian packages from the userspace libs
<zmatt> which provided the necessary dependencies for things like qt5
<zmatt> now I remember
<Guest1566> Last time (on the am335x) when I installed the user mode libraries using the 1.14.3699939_k4.4 branch it put the libs under /usr/local/lib/arm-linux-gnueabihf and then putting that at the top of the ldconfig conf file meant it would pick the ti libs first.
<Guest1566> However this time it appears the ti libs are installed under /usr/lib
GenTooMan has quit [Read error: No route to host]
GenTooMan has joined #beagle
<zmatt> rcn-ee: oh earlier I forgot the most important bit for wpa_supplicant AP mode: having mode=2 in the network block. also apparently ap_scan=2 is not appropriate anymore for the nl80211 driver
<zmatt> rcn-ee: and it turned out that setting up the access point via dbus instead of using a wpa_supplicant config file is also pretty easy:
<rcn-ee> ah perfect..
<rcn-ee> so i found a workaround for non-wifi devies:
<rcn-ee> patch "wpa" right now with:
<rcn-ee> that's crazy, not much needed for dbus..
<zmatt> so, that service file is annoying anyway since it is designed for having a separate wpa_supplicant process per interface (which is not compatible with using dbus) and does not enable dbus
<zmatt> yeah, and it's almost just as easy in C using libsystemd
<zmatt> having the wlan0 device pull in wpa supplicant is indeed a good idea
<zmatt> rcn-ee: that idea combined with a variant of my wpa_supplicant.service that sets up wlan0 using config file but also enables dbus:
<zmatt> (and then ap0 could pull in a service that enables the access point via dbus)
<zmatt> that way if ap0 never shows up, no problem
<rcn-ee> dbus is the -O right?
<zmatt> no
<zmatt> -u is dbus
<rcn-ee> ah!
<zmatt> I'm not 100% sure what the story behind the -O is... I think it ensures the config file cannot mess with where the legacy control sockets are created
<zmatt> it's been a while since I dug into this stuff
<rcn-ee> and wpa2.9 didn't have that enabled..
<zmatt> ?
<rcn-ee> So this is with dbus added..
<zmatt> debian ships with a wpa_supplicant.service file that's dbus-only (no config files) and a wpa_supplicant@.service template that's single-interface with config file and no dbus
<rcn-ee> and then with nl80211 and not nl80211 in bullseye..
<zmatt> no, don't use -u in the service template, that's a bad idea
<zmatt> since a template can be enabled for multiple interfaces, but that creates a wpa_supplicant process per interface and you can't have two dbus-enabled wpa_supplicant processes running
<zmatt> that's why I'm using (and suggesting) a custom wpa_supplicant.service
<rcn-ee> okay nuked that.
<zmatt> and I think nl80211 is the default
<zmatt> probably
<rcn-ee> for our wl18xx it is, the brcmfmac might not be... it's a mess..
<zmatt> I'm also not specifying the driver in CreateInterface in my shell script (even though I could) and it seems to do the right thing
<zmatt> brcmfmac seems to be nl80211 too based on a quick google?
<rcn-ee> it must be old android or really old drivers now..
buzzmarshall has quit [Quit: Konversation terminated!]
buzzmarshall has joined #beagle
<rcn-ee> zmatt, yeah this wlan0 config works perfect.. fire up a non-wifi, stick a usb-wifi, instantly connects to wlan0..
<rcn-ee> this will be the default wlan0 location: /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
<rcn-ee> i'll probally setup : /etc/wpa_supplicant/wpa_supplicant-ap0.conf for the ap..
<rcn-ee> that should be easy for end users to quickly tweak for their network preferences..
<zmatt> using a separate (non-dbus) process/service ?
<rcn-ee> yeah, either a dbus or not, something easy..
<zmatt> yeah, if separate processes are used (precluding having both dbus-controllable) then dbus control on wlan0 would be more useful than on ap0
<zmatt> or instead of using dbus I guess a config util could also use the legacy control socket (used e.g. by wpa_cli), but I don't know how that works
ikarso has quit [Quit: Connection closed for inactivity]
<Guest1566> Where can I find the correct libgbm1 source code for am57xx?
<zmatt> oh right
<zmatt> some libraries will be looking for libgbm1 rather than libgbm2
<zmatt> like, if you use standard debian packages for things like qt5
<zmatt> a symlink should deal with that
<zmatt> yeah that was the big annoyance with the version bump, it makes a hassle out of using precompiled binaries that were linked to
<zmatt> looks like what I did back in 2017 was patch the libgbm library version from 2 back to 1 (in both libgbm itself and the sgx libraries that reference it)
<zmatt> which is also gross, but I was too lazy to recompile qt5
<zmatt> I wonder why I didn't use a symlink... maybe I'm overestimating the intelligence of the dynamic linker, maybe it won't recognize the fact that it's the same library and end up loading two copies of libgbm into memory, which would be bad
<Guest1566> I'll try the simlink hack first I guess. I messed up my filesystem so I'm imaging a new card right now.