Guest77 has joined #beagle
<Guest77> Hejho! Can I ask anybody here a question about pin assignment on beaglebone AI?
<Guest77> I try to use the UART of the PRU's. This is how I tried to reconfigure the pins.
<Guest77> This is part of my device tree overlay:
<Guest77> &cape_pins_default {
<Guest77> pinctrl-single,pins = <
<Guest77> DRA7XX_CORE_IOPAD( 0x3614, PIN_OUTPUT | MUX_MODE10 ) // P8.31a PRU1 TX
<Guest77> DRA7XX_CORE_IOPAD( 0x3610, PIN_INPUT | MUX_MODE10 ) // P8.33a PRU1 RX
<Guest77> DRA7XX_CORE_IOPAD( 0x35E4, PIN_INPUT | MUX_MODE10 ) // P8.43 PRU0 UART RX
<Guest77> DRA7XX_CORE_IOPAD( 0x35E8, PIN_OUTPUT | MUX_MODE10 ) // P8.44 PRU0 UART TX
<Guest77> >;
<Guest77> };
<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 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/ 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_> 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?
<set_> It is part of the process.
<set_> I am almost done putting it together...
argonautx has joined #beagle
<set_> is a build process...
<set_> and then I upload and install the binary via this page:
<zmatt> "sudo pip3" .. there's your first problem
<zmatt> also that list of packages you installed with apt is wrong
<set_> Right. I have tried w/ pip3 only, i.e. w/out sudo.
<zmatt> you installed python2 packages instead of python3 packages
<set_> Hmm.
<set_> Okay.
<set_> Maybe I gave you the incorrect file. Let me check again. Sheesh.
<zmatt> python3 python3-dev python3-lxml python3-pip
<zmatt> (three of these are already installed by default btw, python3-lxml is the only one missing)
<set_> Right. I see what happened in the .sh file now. I saw " sudo pip3 " instead of pip3 for my pip install.
<zmatt> and you could also have installed future using apt (python3-future)
<set_> Oh!
<set_> Okay.
<set_> I had an issue w/ that too.
<set_> I have to use pip3 install future alone outside of the .sh file.
<zmatt> ??
<zmatt> you didn't run the .sh file itself with sudo did you?
<set_> No.
<set_> But...
<set_> I have to use sudo to change the file itself.
<set_> So. I can run the .sh file w/out sudo but I cannot change the file in nano/vi or whatever w/out sudo.
<zmatt> what? why? how did you create it?
<set_> It was already created. I just had to change a bunch b/c of using Debian and python3 instead of python2 and Ubuntu.
<zmatt> sounds like your root problem goes back even further
<set_> Right.
<zmatt> what do you mean "it was already created" ? where did it come from? how did you put it on your bbblue?
<set_> It was a file to cross-compile via Ubuntu to the BBBlue from ArduPilot people. And...I put it on the BBBlue w/ upload and rsync.
<zmatt> rsync with what arguments?
<zmatt> this script is kind of gross btw :P
<zmatt> also, I need to go
otisolsen70_ has joined #beagle
<set_> Dang.
<set_> Okay. NO issue.
<set_> Have fun.
otisolsen70 has quit [Ping timeout: 252 seconds]
otisolsen70_ has quit [Quit: Leaving]
Posterdati has quit [Quit: KVIrc 5.0.0 Aria]
nerdboy has quit [Ping timeout: 265 seconds]
vd has joined #beagle
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> ( arm-linux-gnueabihf-objdump -p targetfs/jacinto6evm/lib/*.so | grep GLIBC | sort -u )
charlie5 has joined #beagle
<zmatt> Guest1522: and this is the disgusting one-liner that produced that overview:
<zmatt> ;-)
tigert_xyz has joined #beagle
<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
florian has quit [Quit: Ex-Chat]
<zmatt> on sec
<zmatt> *one sec
<zmatt> tigert_xyz: my overlay-utils ( ) now has overlays for uart2/4/5 with and without rtscts
<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 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> try: strace -e trace=file -o strace.log eglinfo
lucascastro has joined #beagle
<zmatt> and see if the strace.log has anything suspicious (or share it via pastebin)
<zmatt> or maybe first check if all dependencies are available
<zmatt> (dunno if it's possible some shared library is being loaded dynamically and failing to due to deps)
<zmatt> though that too would show up in strace
<Guest15> so I install the sgx libs (and libgbm) into /usr/local/lib/arm-linux-gnueabihf
<zmatt> yeah that's my concern too
<zmatt> the pkgconfig files show that the libraries were built with --prefix=/usr and I'm wondering if that path might show up somewhere
lucascastro has quit [Ping timeout: 260 seconds]
<zmatt> and both contain the string "/usr/lib/dri"
<zmatt> as well as /usr/share/drirc.d
<Guest15> Here's the strace log
<zmatt> bingo
<zmatt> it tried to load /usr/lib/dri/
<Guest15> Missing package?
<zmatt> no
<zmatt> part of the files you installed
<zmatt> except the wrong place
lucascastro has joined #beagle
<zmatt> you could probably just add a symlink
<zmatt> pretty sure the debian mesa libs will look in /usr/lib/arm-linux-gnueabihf/dri/ instead of /usr/lib/dri/
<Guest15> I just tried to symlink the dri directory. Still fails for some other lib:,
lucascastro has quit [Remote host closed the connection]
<zmatt> it should be fine at long as it finds one, specifically
lucascastro has joined #beagle
<zmatt> it's just trying different fallbacks
Guest15 has quit [Quit: Client closed]
Guest15 has joined #beagle
<Guest15> Seems it can't find "/etc/powervr.ini" even though it exists.
<Guest15> 4 -rw-r--r-- 1 root root 67 Sep 29 18:22 /etc/powervr.ini
<zmatt> share strace log?
tigert_xyz has quit [Quit: Client closed]
<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
<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 nor 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 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
<zmatt> ah this is an old version google fonud, current version uses getPlatformDisplay(EGL_PLATFORM_GBM_MESA, EGL_DEFAULT_DISPLAY, NULL) apparently:
<zmatt> since I see in the strace log it prints "GBM platform:"
<zmatt> oh you didn't redirect the strace output to file, so the eglinfo output is all mixed up with the strace output
<zmatt> "If <native_display> is NULL, then the resultant EGLDisplay will be backed by some implementation-chosen GBM device."
<zmatt> so this might not be a problem for e.g. qt5
<zmatt> which probably passes an explicit display
<zmatt> but still
<Guest15> OGLES2Water also fails to run.
crazymax has joined #beagle
crazymax has quit [Changing host]
crazymax has joined #beagle
<zmatt> that seems to be completely unrelated
giort has quit [Quit: giort]
<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/ 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, what's that all about?
<zmatt> pretty sure major() is a macro
<zmatt> the 1.17 drivers use a mesa-based frontend
<Guest15> warning:, needed by /usr/local/lib/arm-linux-gnueabihf/, may conflict with
<Guest15> that was further up.
<zmatt> wait why is it trying to use, 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...
vd44 has joined #beagle
vd has quit [Ping timeout: 256 seconds]
m-atoms has joined #beagle
Guest15 has quit [Quit: Client closed]
giort has joined #beagle
set_ has joined #beagle
Guest15 has joined #beagle
giort has quit [Ping timeout: 245 seconds]
<argonautx> hi, I have a bbb, which doesn't accept a microSD card to load. I followed these instructions to build a yocto system:
<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 has joined #beagle
<Guest15> So qt isn't working. Could not initialize egl display. strace log here
<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.
<argonautx> this is what my seriel console tells me:
<Guest15> no mention of /dev/dri
<zmatt> argonautx: well, it loaded the kernel ;)
<argonautx> and there it stucks
<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
<argonautx> so this is after pressing the button:
<argonautx> it doesn't care about the ssd?
<zmatt> looks pretty broken
<zmatt> like, wtf is that crash
<zmatt> and it looks like it has no boot script? unless you accidently pressed a key while it said "Hit any key to stop autoboot"
<argonautx> I unplugged the device, pushed the button and plug it again
<zmatt> anyway, either you somehow didn't follow the instructions correctly, or the instructions are wrong. I don't know anything about yocto myself
<argonautx> while holding the button
<argonautx> it looks like if yocto doesn't even been read or is started at all
<zmatt> yes it seems to make no attempt at booting
<argonautx> Loading Environment from FAT... *** Warning - bad CRC, using default environment
<zmatt> so it's like both your u-boot and your linux system are somehow broken
<zmatt> yeah you can ignore that
<argonautx> okay
<argonautx> too bad, I thought this can be something I can start, no proper FAT partition
<zmatt> ?
<zmatt> ah no, it just tries to load a previously saved persistent environment
<zmatt> like, you can use that to override default environment vars
<zmatt> generally there's no reason to do that
<zmatt> and its warning that there's no saved environment is just a bit awkwardly phrased
<argonautx> so we have to U-Boot here, one from 2019.04 on the MMC2 and one from 2020.01 on the SD-card?
<zmatt> the 2019.04 is the one from eMMC yes, which is mmc1 misreported by u-boot as MMC2
<zmatt> (for historical reasons)
<argonautx> but both want to boot from MMC1 or eMMC
<zmatt> no
<zmatt> the "Trying to boot from MMC" message (from u-boot SPL) has the mmc number off-by-one in both cases
<zmatt> (bootrom loads SPL which loads the full u-boot which loads linux)
<zmatt> and that message is the only one that calls the SD card "MMC1" and eMMC "MMC2" ... later messages get the numbering correct, 0 = sd, 1 = eMMC
<zmatt> the u-boot that's on eMMC will try to boot linux from SD card before falling back to booting linux from eMMC
<argonautx> okay in this case both Uboots try to boot from the sd-card?
<zmatt> yes
<zmatt> well
<zmatt> the one on eMMC does, and looks to me like it does so successfully, except something goes wrong after it transfers execution to the kernel
<zmatt> while the u-boot on SD card doesn't seem to make any attempt to boot anything whatsoever
<zmatt> it's just throwing you into the shell
<zmatt> that crash log puzzles me too... there was no console output prior to that? it's so strange to have a crash log as the first message
<zmatt> (and why did it crash once but not a second time?)
<argonautx> on the console it starts all over again, in a loop