<Guest77>
But the "show-pins" script after fiddling and rebooting for quite a while now still states MUX_MODE0 and some vout... function for these pin (I assume vout... is some HDMI thing, right?)
<Guest77>
P8.31a 133 C8 0 slow vout1_d14
<Guest77>
P8.33a 132 C6 0 slow vout1_d1
<Guest77>
P8.43 121 F10 0 slow vout1_d2
<Guest77>
P8.44 122 G11 0 slow vout1_d3
<Guest77>
I tried to disable HDMI like on the BBBlack in /boot/uEnv.txt like so:
<Guest77>
disable_uboot_overlay_video=1
<Guest77>
disable_uboot_overlay_emmc=1
<Guest77>
But I dont know if this works the same on the AI and couldn't find anything anywhere else about it
m-atoms has quit [Ping timeout: 264 seconds]
m-atoms has joined #beagle
m-atoms has quit [Ping timeout: 245 seconds]
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
vd has quit [Quit: Ping timeout (120 seconds)]
thinkfat_ has quit [Ping timeout: 245 seconds]
thinkfat has joined #beagle
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #beagle
vd has joined #beagle
Guest77 has quit [Ping timeout: 256 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
waldo323__ has joined #beagle
waldo323_ has quit [Ping timeout: 264 seconds]
vagrantc has joined #beagle
ikarso has joined #beagle
vagrantc has quit [Quit: leaving]
giort has joined #beagle
giort has quit [Ping timeout: 250 seconds]
zjason` is now known as zjason
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
vd has quit [Ping timeout: 256 seconds]
Shadyman has quit [Quit: Leaving.]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
jduchniewicz has quit [Quit: Bridge terminating on SIGTERM]
RossSchulman[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
jkridner[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has joined #beagle
florian has joined #beagle
mvaittin has joined #beagle
RossSchulman[m] has joined #beagle
jkridner[m] has joined #beagle
jduchniewicz has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
otisolsen70 has joined #beagle
<set_>
Is /usr read only on the BBB.io images?
<zmatt>
no, though you shouldn't modify things in /usr (other than in /usr/local), those files are part of apt packages
<set_>
Okay.
<set_>
I have been readin' the FHS and I am trying to figure out where to put a binary.
<zmatt>
/usr/local/bin (or /usr/local/sbin for binaries that require root privileges)
<set_>
Right. Okay. What about non-root privileges?
<zmatt>
/usr/local/bin
<set_>
Oh. Okay.
<set_>
Hmm. So, /usr/local/bin/ should already have some binaries but the one I want to add should be symlinked, right?
<zmatt>
?
<set_>
Sorry.
<set_>
No issue. I am going to place the binary in /usr/local/bin.
<zmatt>
generally speaking you would not symlink, but it depends a bit on the circumstances
<set_>
Okay. it probably has nothing to do w/ my current config. of the binary.
<set_>
Well, we shall see. I put the binary in /usr/local/sbin/ and just rebooted the device, BBBlue!
<set_>
I tried /usr/local/bin/ but it says the device vanished. Ha.
<set_>
Yep. So... /usr/local/sbin/ is a winner!
<set_>
Thank you.
<zmatt>
ehm
<set_>
What?
<zmatt>
nothing you just said makes any sense
<set_>
Oh.
<set_>
Okay. Yay!
<set_>
We got to get you a new line! "This makes no sense, You are not making sense!"
<set_>
Ha. Come on, sir. Try, "You are blind to the fact!"
<zmatt>
the decision whether to put something in /usr/local/bin/ versus /usr/local/sbin/ should solely be decided based on whether the executable is intended to be used only by root (sbin) or any user (bin)
<set_>
Oh.
<zmatt>
the directories are on the same filesystem and have the same permissions, if you can put stuff into bin you can put it into sbin and vice versa
<set_>
Now, I understand. So, I guess I am using the binary, after sudo chmod 0755 arducopter, as user sudo.
<set_>
I understand.
<zmatt>
there's no such user
<set_>
Sorry.
<set_>
w/ root permissions.
<zmatt>
why are you using sudo to chmod it?
<zmatt>
that is weird by itself
<set_>
B/c...it does not work unless I use sudo for some reason.
<zmatt>
you've probably been using sudo way too much
<set_>
I tried w/out sudo permissions first.
<zmatt>
almost nothing requires sudo
<set_>
I barely use it b/c of you.
<zmatt>
have you built the binary using sudo or something?
<zmatt>
that's the only explanation I can think of
<set_>
Partially...
<set_>
Not the entire thing but portions.
<zmatt>
sudo should never be used when building something, ever, any time you do so is a mistake
<set_>
I had to use sudo python3 waf configure --board=blue ... and ...
<set_>
Oh. Okay.
<zmatt>
and now you've caused files to be created as root, causing permission errors later down to line
<zmatt>
*down the line
<set_>
Aw.
<set_>
Okay.
<set_>
Argh.
<zmatt>
so now you end up with permission errors later on "forcing" you to use sudo again, while the root cause (no pun intended) was using sudo at any point during the build process
<set_>
Ha.
<set_>
Right.
<set_>
But...in my defense here, python3 waf copter, this command would not run while cross compiling the binary to the BBBlue w/out sudo.
<set_>
I can use python2 but not python3 w/out sudo.
<zmatt>
cross compiling? sudo should _definitely_ never be used while cross-compiling, that makes even less sense
<set_>
Okay. This may be why I am having so many issues.
<set_>
Hmm.
<zmatt>
I have no idea what you're talking about but it doesn't make any sense
<set_>
Stop it. Try to understand.
<set_>
So...
<zmatt>
maybe if you have a concrete transcript of what you did and what error(s) you got
<zmatt>
I have little it'll start making sense if you're merely attempting to paraphrase these things
<zmatt>
*little hope
<set_>
Hmm. Okay. Let me put something together and if you remember today and this conversation, we can reconvene?
<set_>
Sorry. The build works. OH!
<set_>
I have something.
<set_>
Please hold.
<set_>
Would you like to see the entire prerequisites for installing and cross-compiling on Debian?
rcn-ee has quit [Remote host closed the connection]
vd has quit [Ping timeout: 256 seconds]
vd has joined #beagle
set_ has quit [Ping timeout: 252 seconds]
buzzmarshall has joined #beagle
Guest1522 has joined #beagle
rcn-ee has joined #beagle
<Guest1522>
Beaglebone ai. What's the correct branch to use from omap5-sgx-ddk-um-linux for kernel 4.19.94-ti-r68? I tried zeus after referencing the yocto releases, but it's compiled against glibc 2.29 which doesn't work on Buster.
<Guest1522>
ti-img-sgx/zeus/1.17.4948957 this one specifically
charlie5 has quit [Ping timeout: 265 seconds]
vagrantc has joined #beagle
waldo323_ has joined #beagle
waldo323__ has quit [Ping timeout: 246 seconds]
m-atoms has joined #beagle
<zmatt>
thud?
<zmatt>
ti-img-sgx/thud/1.17.4948957 has version references to glibc 2.28 but not 2.29
<zmatt>
(if the remote is called "origin" then both occurrences of remotes/ti/ need to be remotes/origin/ instead)
Guest1522 has quit [Quit: Client closed]
<tigert_xyz>
Hi, I am using config-pin P8.37 uart to configure uart pins. If I want to enable RTS/CTS for the port, do I have to configure rts pin as uart or as long as hardware wired, the system will automatically use the pin for rtc/stc?
<zmatt>
I seem to recall uart rts/cts modes for pins were glaringly absent in the modes defined by cape-universal (for use with config-pin), so it might be the case that an overlay would be required
<zmatt>
yeah, for P8_32 (uart 5 rts), config-pin only lists gpio modes and qep
<tigert_xyz>
So an overlay is needed in order to configure rts/cts?
<zmatt>
yeah
<tigert_xyz>
Can use help me check UART2 and UART4, for rts/cts pin configuration?
<zmatt>
uart 2 rts/cts conflicts with using uart 5
<tigert_xyz>
Well, if we use UART2, then uart5 will not be used
<tigert_xyz>
Or use UART2 without rts/cts and use UART5
<tigert_xyz>
these are .dtsi files. Do I need a compilation for cape-overlays? Currently I have no issues with configuring uart ports (Uart2/uart4/uart5), but I don't know steps for enabling rts/cts. It seems to me not an easy one.
<tigert_xyz>
Oh, there is dtsi-to-overlay bin file. Is that a command line util tool for configuring uart ports?
<zmatt>
use the makefile
<zmatt>
if you run "make" it will compile all the overlays
<zmatt>
note that my overlay-utils uses a somewhat different source format (and significantly different macros) than the bb.org-overlays repository
<zmatt>
you can also build an individual one with e.g. "make uart2-rtscts.dtbo"
<tigert_xyz>
Ok. I got it. It turns .dtsi into overlay file for configuring ports. Do you have rts/cts .dtsi or add one as example, I probably can modifiy based on you example
<zmatt>
I already did, that's what I just said: "now has overlays for uart2/4/5 with and without rtscts"
<tigert_xyz>
Thank you so much.
set_ has joined #beagle
<zmatt>
just added uart1 too
lucascastro has joined #beagle
CrazyEddy has quit [Ping timeout: 245 seconds]
Guest15 has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has quit [Ping timeout: 265 seconds]
set_ has quit [Ping timeout: 252 seconds]
giort has joined #beagle
giort has quit [Ping timeout: 252 seconds]
<Guest15>
ti-img-sgx/thud/1.17.4948957 doesn't work. Or rather OGLES2Water and eglinfo both faile to initialize egl.
<zmatt>
is the kernel driver loaded? has sgx been initialized successfully ? (sudo pvrsrvctl --start --no-module)
<Guest15>
[ 6.057053] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ]
<zmatt>
okay, so that's already a major step
<Guest15>
Yeah I thought everything was working, but my usual tests don't.
<Guest15>
For the older kernel I was using ti-img-sgx/rocko/1.14.3699939 as rcn-ee suggested.
<zmatt>
looks like it's also possible to avoid the need to symlink by setting an environment variable, LIBGL_DRIVERS_PATH=/usr/local/lib/arm-linux-gnueabihf/dri or whereever you installed pvr_dri.so
<zmatt>
it was able to open /etc/powervr.ini just fine
giort has joined #beagle
Guest24 has joined #beagle
Guest24 has quit [Client Quit]
<zmatt>
it can't find libPVROGL.so nor libPVROCL.so but neither of those are in the distribution so I'm assuming that's okay and can be ignored
<zmatt>
very odd
<zmatt>
try strace without the -e trace=file
<zmatt>
it'll be spammy but maybe there's something in there
<zmatt>
the fact that mesa proceeded to try to load other drivers suggests to me that pvr_dri.so returned a failure to initialize
Shadyman has joined #beagle
<zmatt>
or try moving your powervr.ini away, there is none in the distribution so maybe whatever you have in it confuses the new driver
<zmatt>
hmm, why doesn't strace know these syscalls
<zmatt>
yeah try without the /etc/powervr.ini
<zmatt>
ah strace doesn't know these ioctls because they're driver-specific ioctls, that's fair
<zmatt>
it could at least have rewritten _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c) as DRM_IOWR(DRM_COMMAND_BASE+0x00, 0x1c)
<zmatt>
(which in this case is DRM_IOCTL_PVR_SRVKM )
<zmatt>
it's also hilarious how often it reads powervr.ini ... I wonder if they have a function to get a single config variable, and they re-read the config file each time any piece of code wants to know any config var
<Guest15>
So, any clues as to the real problem?
<zmatt>
did you try without /etc/powervr.ini ?
<Guest15>
Yes, sorry no change.
<Guest15>
well it's not working. I can't say there's no change, but the error output (without strace) looks the same.
m-atoms has quit [Remote host closed the connection]
m-atoms has joined #beagle
<zmatt>
can you check the symlinks in /dev/dri/by-path/ to see which one links to ../renderD130
<zmatt>
is it the gpu or omapdrm ?
rcn-ee has quit [Quit: Leaving]
<zmatt>
must be the gpu
<Guest15>
card1 points to omapdrm, card0 points to etnaviv, and card2 points to 56000000.gpu-card
<Guest15>
platform-56000000.gpu-render goes with renderD130
<zmatt>
okay, gpu-render yeah
tbr has quit [Ping timeout: 250 seconds]
m-atoms has quit [Ping timeout: 252 seconds]
lucascastro has quit [Ping timeout: 250 seconds]
<zmatt>
wait what
<zmatt>
it's trying to use /dev/dri/card0
<Guest15>
what's platform-etnaviv-card?
<zmatt>
the 2d graphics accelerator
<Guest15>
I presume this wasn't changed between the 4.4 and 4.19 kernels?
<zmatt>
it should be using the omapdrm device
<zmatt>
the card numbers are unpredictable
<zmatt>
can vary per kernel, can vary per boot
<Guest15>
So how does eglinfo know? It doesn't seem to take any parameters
tbr has joined #beagle
<zmatt>
good question, it also opened card0 before even loading pvr_dri.so
<zmatt>
it never even gets around to doing anything with egl
giort has joined #beagle
<zmatt>
okay, so what eglinfo does, specifying GBM platform but not explicitly supplying a gbm device will cause mesa to open /dev/dri/card0 ... hardcoded, no lookup, no scan for sensible devices, no way to specify the device via an environment variable
<zmatt>
so combined with the fact that the numbering of /dev/dri/card* devices is random, that's pretty useless
<zmatt>
you can try rebooting and see if the card numbering is more favorable :P
<zmatt>
or use a DT overlay with &bb2d { status = "disabled"; }; to disable the 2d gpu and increase the probability that card0 is omapdrm
<zmatt>
but this is really just a bug in eglinfo, or one in mesa's behaviour for handling a NULL GBM device
giort has quit [Quit: giort]
<zmatt>
it should at least look for a device with modesetting support
<zmatt>
like I said, I don't think a properly written program would run into this problem
<zmatt>
like, does kmscube work?
<zmatt>
(not that what it's doing is something I'd consider "properly written", but at least it passes in an explicit gbm device)
<Guest15>
I rebooted a few times and the card numbering is always the same. Does it have anything to do with the kernel cmdline having video=HDMI-A-1:1024x768@60e
<zmatt>
no. I've seen card numbering change across reboots but I have to admit I don't remember what kernel version. the card numbering is of course not literally "random", just undefined, it is possible that the timing of things getting probed is such that it happens to always (or almost always) yield the same numbering
<zmatt>
still, anything that blindly assumes card0 is appropriate to use is broken
<zmatt>
and that's what eglinfo does
<Guest15>
kmscube doesn't compile./usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libgbm.so: undefined reference to `major'
<zmatt>
uhh what
<Guest15>
This was something I asked earlier, but got disconnected so I didn't see if there was an answer.
<zmatt>
didn't see that question
<Guest15>
I noticed that ti-img-sgx/thud/1.17.4948957 has libgbm.so.1.0.0, what's that all about?
<zmatt>
pretty sure major() is a macro
<zmatt>
the 1.17 drivers use a mesa-based frontend
<Guest15>
warning: libgbm.so.1, needed by /usr/local/lib/arm-linux-gnueabihf/libEGL.so, may conflict with libgbm.so.2
<Guest15>
that was further up.
<zmatt>
wait why is it trying to use libgbm.so.2, that doesn't exist in the 1.17 drivers
<Guest15>
Uh because I installed ti's libgbm like I did before...
<Guest15>
not supposed to?
<zmatt>
no
<zmatt>
it includes a libgbm
<Guest15>
well I went into the libgbm.git and make uninstall. now kmscube says: /usr/bin/ld: cannot find -lgbm
<zmatt>
you can't "uninstall" if it's overwritten stuff
<zmatt>
cleanly reinstall the sgx libs
<Guest15>
right. reinstalled the omap stuff
<Guest15>
kmscube compiles
<zmatt>
it's kinda funny and sad the repositories have "omap5" in the name yet they actually dropped support for the omap5
<Guest15>
kmscube -d /dev/dri/card2
<zmatt>
(even though it would have been easy to support since it's pretty much identical to the am572x as far as the gpu is concerned)
<zmatt>
it doesn't automatically find the right device?
<Guest15>
oops. card1... works. No it doesn't automatically find the write device
<Guest15>
ugh. right device.
<zmatt>
that's a step backwards... the old version did
<Guest15>
well it looks like it can display something to the screen which nothing else has done.
<zmatt>
yeah but having to specify the card manually is still broken
<Guest15>
speaking of, the DISPLAY variable need to be set for this? Or that only for X?
<zmatt>
that's X
<Guest15>
So does Qt stand a chance of working on top of EGL?
<zmatt>
btw to avoid depending on a card numbering, use the symlinks in /dev/dri/by-path/
<zmatt>
I'd assume so
<zmatt>
I think it also scans a bit more intelligently for an output device
<Guest15>
Ok I'll install qt then. That takes awhile...
<argonautx>
but somehow the bbb does not read from the sdcard
<zmatt>
try powering on with the S2 button held down (the button closest to the sd card slot), you can let go of the button once the power led turns on
<zmatt>
that will bypass the bootloader on eMMC and use the one on SD card instead
Guest15 has quit [Quit: Client closed]
<zmatt>
oh the page actually mentions holding the S2 button (although the "hold for at least 5 seconds" is complete nonsense, the state of the button is sampled about 20ms after the power led turns on, holding it any longer after that is pointless)
<Guest15>
I didn't see anything obvious, but I honestly don't know what I'm looking for.
<zmatt>
me neither but it's clearly not even trying so it might be a configuration issue
<argonautx>
zmatt: did it exact that way. holding the s2 button or boot button then connecting the device to power on, holding for about 20sek
<argonautx>
but no effect
<zmatt>
argonautx: like I said, there's no reason to hold it once the power led turns on
<zmatt>
so nothing happened other than the power led turning on? no led activity?
<argonautx>
only the power led lits on, I switch on the device by connecting to a USB power supply
<zmatt>
have you checked output on the serial console?
<argonautx>
no other LEDs
<argonautx>
not yet
<zmatt>
debugging boot issues without monitoring the serial console is a waste of time, since that's your primary source of information on what's going on during boot
<zmatt>
but if absolutely nothing happens then either bootrom doesn't consider your sd card to be bootable (i.e. you somehow incorrectly prepared the sd card) or the u-boot that's on it doesn't work (crashes or fails to load the linux system)
<zmatt>
Guest15: I don't have any personal experience with the 1.17 drivers and my experience with the sgx libs in general is many years old now so I don't really have ideas readily available... I guess try to enable more debug output from qt? I recall there are environment variables for that
<Guest15>
zmatt: I notice it's trying to open /dev/fb0. Is that the right device? would setting QT_QPA_EGLFS_FB help?
<zmatt>
I don't really understand why it's opening the legacy fbdev at all
<Guest15>
Apparently it's only to query sizes.
<zmatt>
yeah but that makes no sense to me, it should query that from the drm device it wants to use
CrazyEddy has joined #beagle
<zmatt>
what version of qt5 are you using?
<Guest15>
Using Qt version 5.11.3, whatever was in the repo
<Guest15>
This same build works with kernel 4.4 and associated sgx libs.
<zmatt>
do you have QT_QPA_EGLFS_INTEGRATION set? if so, to what?
<zmatt>
try setting it to eglfs_kms
<Guest15>
It's set to none, kms not supposed to work?
<zmatt>
?
<Guest15>
we had this conversation already, a couple of days ago
<Guest15>
you were surpised that export QT_QPA_EGLFS_INTEGRATION=none worked
<zmatt>
I still am yes
<zmatt>
and clearly it now doesn't :P
<zmatt>
so try eglfs_kms
<Guest15>
I did, it doesn't work either.
<zmatt>
does strace at least show stuff happening with /dev/dri/ devices?
<Guest15>
last time it was failing for a different reason though, something to do with gbm.
<zmatt>
argonautx: wait is this with S2 button held at power-on?
<zmatt>
it doesn't look like it is
<argonautx>
ahhh, .... sorry
<zmatt>
although that might not matter since it does look like it loaded the yocto system correctly
<zmatt>
I don't see any obvious problems
<zmatt>
like, this generally either means the kernel crashed early on or console output is somehow lost (e.g. due to wrong console= argument or missing driver) ... console=ttyS0,115200 should be correct. kernel misconfigured or misbuilt? dunno