**** BEGIN LOGGING AT Wed Sep 29 02:59:56 2021 Sep 29 13:00:29 Is /usr read only on the BBB.io images? Sep 29 13:04:33 no, though you shouldn't modify things in /usr (other than in /usr/local), those files are part of apt packages Sep 29 13:07:14 Okay. Sep 29 13:07:40 I have been readin' the FHS and I am trying to figure out where to put a binary. Sep 29 13:08:25 /usr/local/bin (or /usr/local/sbin for binaries that require root privileges) Sep 29 13:08:54 Right. Okay. What about non-root privileges? Sep 29 13:09:07 /usr/local/bin Sep 29 13:09:12 Oh. Okay. Sep 29 13:09:55 Hmm. So, /usr/local/bin/ should already have some binaries but the one I want to add should be symlinked, right? Sep 29 13:10:03 ? Sep 29 13:10:10 Sorry. Sep 29 13:10:36 No issue. I am going to place the binary in /usr/local/bin. Sep 29 13:10:47 generally speaking you would not symlink, but it depends a bit on the circumstances Sep 29 13:11:21 Okay. it probably has nothing to do w/ my current config. of the binary. Sep 29 13:23:16 Well, we shall see. I put the binary in /usr/local/sbin/ and just rebooted the device, BBBlue! Sep 29 13:23:58 I tried /usr/local/bin/ but it says the device vanished. Ha. Sep 29 13:25:48 Yep. So... /usr/local/sbin/ is a winner! Sep 29 13:25:52 Thank you. Sep 29 13:25:58 ehm Sep 29 13:26:15 What? Sep 29 13:26:42 nothing you just said makes any sense Sep 29 13:26:51 Oh. Sep 29 13:26:54 Okay. Yay! Sep 29 13:27:22 We got to get you a new line! "This makes no sense, You are not making sense!" Sep 29 13:27:37 Ha. Come on, sir. Try, "You are blind to the fact!" Sep 29 13:27:45 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) Sep 29 13:27:57 Oh. Sep 29 13:28:34 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 Sep 29 13:28:34 Now, I understand. So, I guess I am using the binary, after sudo chmod 0755 arducopter, as user sudo. Sep 29 13:28:46 I understand. Sep 29 13:28:48 there's no such user Sep 29 13:28:53 Sorry. Sep 29 13:29:00 w/ root permissions. Sep 29 13:29:01 why are you using sudo to chmod it? Sep 29 13:29:09 that is weird by itself Sep 29 13:29:19 B/c...it does not work unless I use sudo for some reason. Sep 29 13:29:27 you've probably been using sudo way too much Sep 29 13:29:32 I tried w/out sudo permissions first. Sep 29 13:29:33 almost nothing requires sudo Sep 29 13:29:36 I barely use it b/c of you. Sep 29 13:29:45 have you built the binary using sudo or something? Sep 29 13:29:53 that's the only explanation I can think of Sep 29 13:29:57 Partially... Sep 29 13:30:04 Not the entire thing but portions. Sep 29 13:30:31 sudo should never be used when building something, ever, any time you do so is a mistake Sep 29 13:30:50 I had to use sudo python3 waf configure --board=blue ... and ... Sep 29 13:30:52 Oh. Okay. Sep 29 13:31:05 and now you've caused files to be created as root, causing permission errors later down to line Sep 29 13:31:08 *down the line Sep 29 13:31:14 Aw. Sep 29 13:31:16 Okay. Sep 29 13:31:20 Argh. Sep 29 13:31:53 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 Sep 29 13:32:02 Ha. Sep 29 13:32:07 Right. Sep 29 13:32:53 But...in my defense here, python3 waf copter, this command would not run while cross compiling the binary to the BBBlue w/out sudo. Sep 29 13:33:26 I can use python2 but not python3 w/out sudo. Sep 29 13:33:29 cross compiling? sudo should _definitely_ never be used while cross-compiling, that makes even less sense Sep 29 13:33:45 Okay. This may be why I am having so many issues. Sep 29 13:33:49 Hmm. Sep 29 13:33:55 I have no idea what you're talking about but it doesn't make any sense Sep 29 13:34:07 Stop it. Try to understand. Sep 29 13:34:12 So... Sep 29 13:34:32 maybe if you have a concrete transcript of what you did and what error(s) you got Sep 29 13:35:05 I have little it'll start making sense if you're merely attempting to paraphrase these things Sep 29 13:35:09 *little hope Sep 29 13:35:25 Hmm. Okay. Let me put something together and if you remember today and this conversation, we can reconvene? Sep 29 13:35:41 Sorry. The build works. OH! Sep 29 13:35:46 I have something. Sep 29 13:36:28 Please hold. Sep 29 13:41:01 Would you like to see the entire prerequisites for installing and cross-compiling on Debian? Sep 29 13:41:10 It is part of the process. Sep 29 13:41:21 I am almost done putting it together... Sep 29 13:44:48 https://pastebin.com/WgPR44px is a build process... Sep 29 13:45:41 and then I upload and install the binary via this page: https://github.com/ArduPilot/ardupilot/blob/master/BUILD.md Sep 29 13:51:22 "sudo pip3" .. there's your first problem Sep 29 13:51:41 also that list of packages you installed with apt is wrong Sep 29 13:51:42 Right. I have tried w/ pip3 only, i.e. w/out sudo. Sep 29 13:51:49 you installed python2 packages instead of python3 packages Sep 29 13:51:56 Hmm. Sep 29 13:51:58 Okay. Sep 29 13:52:21 Maybe I gave you the incorrect file. Let me check again. Sheesh. Sep 29 13:52:41 python3 python3-dev python3-lxml python3-pip Sep 29 13:53:05 (three of these are already installed by default btw, python3-lxml is the only one missing) Sep 29 13:53:46 Right. I see what happened in the .sh file now. I saw " sudo pip3 " instead of pip3 for my pip install. Sep 29 13:53:58 and you could also have installed future using apt (python3-future) Sep 29 13:54:05 Oh! Sep 29 13:54:07 Okay. Sep 29 13:54:14 I had an issue w/ that too. Sep 29 13:54:31 I have to use pip3 install future alone outside of the .sh file. Sep 29 13:54:59 ?? Sep 29 13:55:07 you didn't run the .sh file itself with sudo did you? Sep 29 13:55:13 No. Sep 29 13:55:15 But... Sep 29 13:55:25 I have to use sudo to change the file itself. Sep 29 13:55:51 So. I can run the .sh file w/out sudo but I cannot change the file in nano/vi or whatever w/out sudo. Sep 29 13:56:01 what? why? how did you create it? Sep 29 13:56:32 It was already created. I just had to change a bunch b/c of using Debian and python3 instead of python2 and Ubuntu. Sep 29 13:56:35 sounds like your root problem goes back even further Sep 29 13:56:41 Right. Sep 29 13:56:55 what do you mean "it was already created" ? where did it come from? how did you put it on your bbblue? Sep 29 13:57:38 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. Sep 29 13:58:18 rsync with what arguments? Sep 29 13:59:31 this script is kind of gross btw :P Sep 29 13:59:36 also, I need to go Sep 29 14:01:20 https://pastebin.com/ki15bswU Sep 29 14:01:26 Dang. Sep 29 14:01:28 Okay. NO issue. Sep 29 14:01:31 Have fun. Sep 29 16:31:26 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. Sep 29 16:32:06 ti-img-sgx/zeus/1.17.4948957 this one specifically Sep 29 17:18:27 thud? Sep 29 17:19:53 ti-img-sgx/thud/1.17.4948957 has version references to glibc 2.28 but not 2.29 Sep 29 17:20:11 ( arm-linux-gnueabihf-objdump -p targetfs/jacinto6evm/lib/*.so | grep GLIBC | sort -u ) Sep 29 17:41:40 Guest1522: https://pastebin.com/raw/p7fKeASv Sep 29 17:42:58 Guest1522: and this is the disgusting one-liner that produced that overview: https://pastebin.com/zhXktSqE Sep 29 17:43:01 ;-) Sep 29 17:43:49 (if the remote is called "origin" then both occurrences of remotes/ti/ need to be remotes/origin/ instead) Sep 29 17:45:46 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? Sep 29 17:47:21 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 Sep 29 17:49:28 yeah, for P8_32 (uart 5 rts), config-pin only lists gpio modes and qep Sep 29 17:50:27 So an overlay is needed in order to configure rts/cts? Sep 29 17:51:11 yeah Sep 29 17:51:52 Can use help me check UART2 and UART4, for rts/cts pin configuration? Sep 29 17:52:41 uart 2 rts/cts conflicts with using uart 5 Sep 29 17:53:37 Well, if we use UART2, then uart5 will not be used Sep 29 17:54:16 Or use UART2 without rts/cts and use UART5 Sep 29 17:56:27 on sec Sep 29 17:56:29 *one sec Sep 29 18:05:36 tigert_xyz: my overlay-utils ( https://github.com/mvduin/overlay-utils ) now has overlays for uart2/4/5 with and without rtscts Sep 29 18:08:42 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. Sep 29 18:11:03 Oh, there is dtsi-to-overlay bin file. Is that a command line util tool for configuring uart ports? Sep 29 18:12:22 use the makefile Sep 29 18:12:33 if you run "make" it will compile all the overlays Sep 29 18:12:55 note that my overlay-utils uses a somewhat different source format (and significantly different macros) than the bb.org-overlays repository Sep 29 18:13:34 you can also build an individual one with e.g. "make uart2-rtscts.dtbo" Sep 29 18:13:52 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 Sep 29 18:14:43 I already did, that's what I just said: "now has overlays for uart2/4/5 with and without rtscts" Sep 29 18:15:22 Thank you so much. Sep 29 18:16:41 just added uart1 too Sep 29 19:52:34 ti-img-sgx/thud/1.17.4948957 doesn't work. Or rather OGLES2Water and eglinfo both faile to initialize egl. Sep 29 19:54:50 is the kernel driver loaded? has sgx been initialized successfully ? (sudo pvrsrvctl --start --no-module) Sep 29 19:55:21 [ 6.057053] PVR_K: UM DDK-(4948957) and KM DDK-(4948957) match. [ OK ] Sep 29 19:56:22 okay, so that's already a major step Sep 29 19:56:45 Yeah I thought everything was working, but my usual tests don't. Sep 29 19:57:28 For the older kernel I was using ti-img-sgx/rocko/1.14.3699939 as rcn-ee suggested. Sep 29 20:01:35 try: strace -e trace=file -o strace.log eglinfo Sep 29 20:01:51 and see if the strace.log has anything suspicious (or share it via pastebin) Sep 29 20:04:32 or maybe first check if all dependencies are available Sep 29 20:05:37 (dunno if it's possible some shared library is being loaded dynamically and failing to due to deps) Sep 29 20:05:43 though that too would show up in strace Sep 29 20:07:14 so I install the sgx libs (and libgbm) into /usr/local/lib/arm-linux-gnueabihf Sep 29 20:07:26 yeah that's my concern too Sep 29 20:08:01 the pkgconfig files show that the libraries were built with --prefix=/usr and I'm wondering if that path might show up somewhere Sep 29 20:09:12 libEGL.so and libgbm.so both contain the string "/usr/lib/dri" Sep 29 20:09:59 as well as /usr/share/drirc.d Sep 29 20:10:00 Here's the strace log https://pastebin.com/16ti3R3u Sep 29 20:10:29 bingo Sep 29 20:10:35 it tried to load /usr/lib/dri/pvr_dri.so Sep 29 20:11:48 Missing package? Sep 29 20:12:08 no Sep 29 20:12:13 part of the files you installed Sep 29 20:12:16 except the wrong place Sep 29 20:18:56 you could probably just add a symlink Sep 29 20:19:22 pretty sure the debian mesa libs will look in /usr/lib/arm-linux-gnueabihf/dri/ instead of /usr/lib/dri/ Sep 29 20:20:40 I just tried to symlink the dri directory. Still fails for some other lib: kms_swrast_dri.so, Sep 29 20:21:07 it should be fine at long as it finds one, specifically pvr_dri.so Sep 29 20:21:16 it's just trying different fallbacks Sep 29 20:22:37 Seems it can't find "/etc/powervr.ini" even though it exists. Sep 29 20:22:40 4 -rw-r--r-- 1 root root 67 Sep 29 18:22 /etc/powervr.ini Sep 29 20:22:46 share strace log? Sep 29 20:24:16 https://pastebin.com/gQp0TgWG Sep 29 20:24:58 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 Sep 29 20:25:34 it was able to open /etc/powervr.ini just fine Sep 29 20:30:19 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 Sep 29 20:31:02 very odd Sep 29 20:31:18 try strace without the -e trace=file Sep 29 20:31:21 it'll be spammy but maybe there's something in there Sep 29 20:32:12 the fact that mesa proceeded to try to load other drivers suggests to me that pvr_dri.so returned a failure to initialize Sep 29 20:32:54 or try moving your powervr.ini away, there is none in the distribution so maybe whatever you have in it confuses the new driver Sep 29 20:35:42 https://pastebin.com/S6pBY4Qn Sep 29 20:36:21 hmm, why doesn't strace know these syscalls Sep 29 20:37:04 yeah try without the /etc/powervr.ini Sep 29 20:41:26 ah strace doesn't know these ioctls because they're driver-specific ioctls, that's fair Sep 29 20:47:10 it could at least have rewritten _IOC(_IOC_WRITE, 0x64, 0x40, 0x1c) as DRM_IOWR(DRM_COMMAND_BASE+0x00, 0x1c) Sep 29 20:47:54 (which in this case is DRM_IOCTL_PVR_SRVKM ) Sep 29 20:52:25 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 Sep 29 20:53:28 So, any clues as to the real problem? Sep 29 20:53:40 did you try without /etc/powervr.ini ? Sep 29 20:53:47 Yes, sorry no change. Sep 29 20:54:22 well it's not working. I can't say there's no change, but the error output (without strace) looks the same. Sep 29 20:59:24 can you check the symlinks in /dev/dri/by-path/ to see which one links to ../renderD130 Sep 29 20:59:45 is it the gpu or omapdrm ? Sep 29 21:00:48 must be the gpu Sep 29 21:01:51 card1 points to omapdrm, card0 points to etnaviv, and card2 points to 56000000.gpu-card Sep 29 21:02:15 platform-56000000.gpu-render goes with renderD130 Sep 29 21:02:21 okay, gpu-render yeah Sep 29 21:10:29 wait what Sep 29 21:11:01 it's trying to use /dev/dri/card0 Sep 29 21:12:09 what's platform-etnaviv-card? Sep 29 21:12:21 the 2d graphics accelerator Sep 29 21:12:44 I presume this wasn't changed between the 4.4 and 4.19 kernels? Sep 29 21:12:47 it should be using the omapdrm device Sep 29 21:12:57 the card numbers are unpredictable Sep 29 21:13:05 can vary per kernel, can vary per boot Sep 29 21:13:24 So how does eglinfo know? It doesn't seem to take any parameters Sep 29 21:14:40 good question, it also opened card0 before even loading pvr_dri.so Sep 29 21:15:17 eglinfo opens the "default display": https://gitlab.freedesktop.org/mesa/demos/blob/f091f8a2c98a87f9681e802c72ba692b927eb9e7/src/egl/opengl/eglinfo.c#L191 Sep 29 21:16:59 ah this is an old version google fonud, current version uses getPlatformDisplay(EGL_PLATFORM_GBM_MESA, EGL_DEFAULT_DISPLAY, NULL) apparently: https://gitlab.freedesktop.org/mesa/demos/-/blob/main/src/egl/opengl/eglinfo.c#L308-310 Sep 29 21:17:07 since I see in the strace log it prints "GBM platform:" Sep 29 21:17:45 oh you didn't redirect the strace output to file, so the eglinfo output is all mixed up with the strace output Sep 29 21:19:03 "If is NULL, then the resultant EGLDisplay will be backed by some implementation-chosen GBM device." Sep 29 21:19:34 so this might not be a problem for e.g. qt5 Sep 29 21:20:03 which probably passes an explicit display Sep 29 21:20:07 but still Sep 29 21:28:57 OGLES2Water also fails to run. https://pastebin.com/uRfCvEjw Sep 29 21:37:43 that seems to be completely unrelated Sep 29 21:38:27 it never even gets around to doing anything with egl Sep 29 21:43:48 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 Sep 29 21:44:12 so combined with the fact that the numbering of /dev/dri/card* devices is random, that's pretty useless Sep 29 21:47:13 you can try rebooting and see if the card numbering is more favorable :P Sep 29 21:50:49 or use a DT overlay with &bb2d { status = "disabled"; }; to disable the 2d gpu and increase the probability that card0 is omapdrm Sep 29 21:51:33 but this is really just a bug in eglinfo, or one in mesa's behaviour for handling a NULL GBM device Sep 29 21:52:11 it should at least look for a device with modesetting support Sep 29 21:53:40 like I said, I don't think a properly written program would run into this problem Sep 29 21:53:47 like, does kmscube work? Sep 29 21:54:43 (not that what it's doing is something I'd consider "properly written", but at least it passes in an explicit gbm device) Sep 29 22:16:27 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 Sep 29 22:18:23 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 Sep 29 22:18:56 still, anything that blindly assumes card0 is appropriate to use is broken Sep 29 22:19:02 and that's what eglinfo does Sep 29 22:20:20 kmscube doesn't compile./usr/bin/ld: /usr/local/lib/arm-linux-gnueabihf/libgbm.so: undefined reference to `major' Sep 29 22:20:38 uhh what Sep 29 22:21:12 This was something I asked earlier, but got disconnected so I didn't see if there was an answer. Sep 29 22:21:12 didn't see that question Sep 29 22:21:17 I noticed that ti-img-sgx/thud/1.17.4948957 has libgbm.so.1.0.0, what's that all about? Sep 29 22:21:24 pretty sure major() is a macro Sep 29 22:21:43 the 1.17 drivers use a mesa-based frontend Sep 29 22:22:41 warning: libgbm.so.1, needed by /usr/local/lib/arm-linux-gnueabihf/libEGL.so, may conflict with libgbm.so.2 Sep 29 22:22:54 that was further up. Sep 29 22:23:26 wait why is it trying to use libgbm.so.2, that doesn't exist in the 1.17 drivers Sep 29 22:23:49 Uh because I installed ti's libgbm like I did before... Sep 29 22:23:58 not supposed to? Sep 29 22:24:00 no Sep 29 22:24:26 it includes a libgbm Sep 29 22:25:44 well I went into the libgbm.git and make uninstall. now kmscube says: /usr/bin/ld: cannot find -lgbm Sep 29 22:26:16 you can't "uninstall" if it's overwritten stuff Sep 29 22:27:24 cleanly reinstall the sgx libs Sep 29 22:27:28 right. reinstalled the omap stuff Sep 29 22:27:33 kmscube compiles Sep 29 22:28:00 it's kinda funny and sad the repositories have "omap5" in the name yet they actually dropped support for the omap5 Sep 29 22:28:23 kmscube -d /dev/dri/card2 Sep 29 22:28:25 (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) Sep 29 22:28:40 it doesn't automatically find the right device? Sep 29 22:29:13 oops. card1... works. No it doesn't automatically find the write device Sep 29 22:29:54 ugh. right device. Sep 29 22:30:07 that's a step backwards... the old version did Sep 29 22:30:41 well it looks like it can display something to the screen which nothing else has done. Sep 29 22:30:57 yeah but having to specify the card manually is still broken Sep 29 22:31:11 speaking of, the DISPLAY variable need to be set for this? Or that only for X? Sep 29 22:31:15 that's X Sep 29 22:31:49 So does Qt stand a chance of working on top of EGL? Sep 29 22:31:50 btw to avoid depending on a card numbering, use the symlinks in /dev/dri/by-path/ Sep 29 22:32:00 I'd assume so Sep 29 22:32:14 I think it also scans a bit more intelligently for an output device Sep 29 22:37:25 Ok I'll install qt then. That takes awhile... Sep 29 23:47:51 hi, I have a bbb, which doesn't accept a microSD card to load. I followed these instructions to build a yocto system: https://beagleboard.org/p/30847/yocto-on-beaglebone-black-9ae649 Sep 29 23:48:12 but somehow the bbb does not read from the sdcard Sep 29 23:49:03 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 Sep 29 23:49:16 that will bypass the bootloader on eMMC and use the one on SD card instead Sep 29 23:52:34 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) Sep 29 23:54:18 So qt isn't working. Could not initialize egl display. strace log here https://pastebin.com/5qvDLmsJ Sep 29 23:54:34 I didn't see anything obvious, but I honestly don't know what I'm looking for. Sep 29 23:58:25 me neither but it's clearly not even trying so it might be a configuration issue Sep 29 23:59:50 zmatt: did it exact that way. holding the s2 button or boot button then connecting the device to power on, holding for about 20sek Sep 29 23:59:58 but no effect Sep 30 00:00:23 argonautx: like I said, there's no reason to hold it once the power led turns on Sep 30 00:00:48 so nothing happened other than the power led turning on? no led activity? Sep 30 00:01:35 only the power led lits on, I switch on the device by connecting to a USB power supply Sep 30 00:01:55 have you checked output on the serial console? Sep 30 00:01:57 no other LEDs Sep 30 00:02:13 not yet Sep 30 00:02:58 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 Sep 30 00:03:53 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) Sep 30 00:06:08 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 Sep 30 00:09:32 zmatt: I notice it's trying to open /dev/fb0. Is that the right device? would setting QT_QPA_EGLFS_FB help? Sep 30 00:10:02 I don't really understand why it's opening the legacy fbdev at all Sep 30 00:11:21 Apparently it's only to query sizes. Sep 30 00:11:40 yeah but that makes no sense to me, it should query that from the drm device it wants to use Sep 30 00:14:27 what version of qt5 are you using? Sep 30 00:16:40 Using Qt version 5.11.3, whatever was in the repo Sep 30 00:17:26 This same build works with kernel 4.4 and associated sgx libs. Sep 30 00:20:10 do you have QT_QPA_EGLFS_INTEGRATION set? if so, to what? Sep 30 00:24:22 try setting it to eglfs_kms Sep 30 00:25:51 It's set to none, kms not supposed to work? Sep 30 00:26:05 ? Sep 30 00:26:31 we had this conversation already, a couple of days ago Sep 30 00:27:04 you were surpised that export QT_QPA_EGLFS_INTEGRATION=none worked Sep 30 00:27:24 I still am yes Sep 30 00:27:38 and clearly it now doesn't :P Sep 30 00:27:44 so try eglfs_kms Sep 30 00:27:52 I did, it doesn't work either. Sep 30 00:28:36 does strace at least show stuff happening with /dev/dri/ devices? Sep 30 00:28:40 last time it was failing for a different reason though, something to do with gbm. Sep 30 00:28:56 this is what my seriel console tells me: http://codepad.org/GBWbPBWl Sep 30 00:29:08 no mention of /dev/dri Sep 30 00:29:42 argonautx: well, it loaded the kernel ;) Sep 30 00:30:09 and there it stucks Sep 30 00:30:39 argonautx: wait is this with S2 button held at power-on? Sep 30 00:30:47 it doesn't look like it is Sep 30 00:31:58 ahhh, .... sorry Sep 30 00:32:29 although that might not matter since it does look like it loaded the yocto system correctly Sep 30 00:33:10 I don't see any obvious problems Sep 30 00:34:56 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 Sep 30 00:37:04 so this is after pressing the button: http://codepad.org/LPW5oMSw Sep 30 00:38:56 it doesn't care about the ssd? Sep 30 00:38:58 looks pretty broken Sep 30 00:39:16 like, wtf is that crash Sep 30 00:39:47 and it looks like it has no boot script? unless you accidently pressed a key while it said "Hit any key to stop autoboot" Sep 30 00:40:41 I unplugged the device, pushed the button and plug it again Sep 30 00:40:45 anyway, either you somehow didn't follow the instructions correctly, or the instructions are wrong. I don't know anything about yocto myself Sep 30 00:40:53 while holding the button Sep 30 00:42:05 it looks like if yocto doesn't even been read or is started at all Sep 30 00:42:18 yes it seems to make no attempt at booting Sep 30 00:42:55 Loading Environment from FAT... *** Warning - bad CRC, using default environment Sep 30 00:42:57 so it's like both your u-boot and your linux system are somehow broken Sep 30 00:43:00 yeah you can ignore that Sep 30 00:43:19 okay Sep 30 00:44:01 too bad, I thought this can be something I can start, no proper FAT partition Sep 30 00:46:01 ? Sep 30 00:46:25 ah no, it just tries to load a previously saved persistent environment Sep 30 00:46:37 like, you can use that to override default environment vars Sep 30 00:46:56 generally there's no reason to do that Sep 30 00:47:19 and its warning that there's no saved environment is just a bit awkwardly phrased Sep 30 00:49:10 so we have to U-Boot here, one from 2019.04 on the MMC2 and one from 2020.01 on the SD-card? Sep 30 00:49:32 the 2019.04 is the one from eMMC yes, which is mmc1 misreported by u-boot as MMC2 Sep 30 00:49:37 (for historical reasons) Sep 30 00:50:06 but both want to boot from MMC1 or eMMC Sep 30 00:50:12 no Sep 30 00:50:56 the "Trying to boot from MMC" message (from u-boot SPL) has the mmc number off-by-one in both cases Sep 30 00:51:35 (bootrom loads SPL which loads the full u-boot which loads linux) Sep 30 00:52:59 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 Sep 30 00:54:08 the u-boot that's on eMMC will try to boot linux from SD card before falling back to booting linux from eMMC Sep 30 00:54:11 okay in this case both Uboots try to boot from the sd-card? Sep 30 00:54:16 yes Sep 30 00:54:20 well Sep 30 00:54:52 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 Sep 30 00:55:04 while the u-boot on SD card doesn't seem to make any attempt to boot anything whatsoever Sep 30 00:55:18 it's just throwing you into the shell Sep 30 00:56:51 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 Sep 30 00:57:03 (and why did it crash once but not a second time?) Sep 30 00:59:33 on the console it starts all over again, in a loop Sep 30 01:00:00 that was not clear from your paste, can you share an entire loop ? Sep 30 01:01:48 on the way Sep 30 01:03:05 http://codepad.org/FoPEz2em Sep 30 01:04:52 oh you're talking about the kernel, I wasn't. there's no (visible) crash here, but it seems the watchdog gets enabled and eventually expires, causing a system reset Sep 30 01:05:10 I was talking about the crash log in your paste when using the u-boot from SD card (with S2 button) Sep 30 01:05:32 at data abort, I pushed the S2 button, while reconnecting the device with the power source (usb-plug) Sep 30 01:06:14 you mean the data abort was the first message after reconnecting power? Sep 30 01:06:18 so I pushed the S2 button only one time Sep 30 01:06:27 yes Sep 30 01:06:50 how bizarre... does that happen every time? Sep 30 01:08:26 I just reproduced it, it seems so, after releasing the button there's a much faster reset loop Sep 30 01:08:39 ?? Sep 30 01:08:59 the S2 button should have no relevance once power is applied Sep 30 01:09:51 it's sampled at the moment of power-on (20ms after the power led turns on) and shouldn't have any impact otherwise Sep 30 01:10:44 (it decides whether the bootloader on eMMC is bypassed and this decision will apply until the next time the device is powered off and on again) Sep 30 01:11:12 can you share a paste of what you're seeing? Sep 30 01:12:48 http://codepad.org/TB540nEB Sep 30 01:13:37 okay so your earlier paste was in fact interrupted by pressing a key, u-boot seems to be working fine Sep 30 01:13:56 well Sep 30 01:13:57 sort of Sep 30 01:14:05 at least it seems to be going through the steps of booting a kernel Sep 30 01:14:48 but that crash log looks like one produced by u-boot, not one produced by the kernel (despite being after printing "Starting kernel ...") Sep 30 01:15:49 so I'm not sure what's going on, but this looks to me like both your u-boot and your kernel are broken, possibly misbuilt Sep 30 01:16:09 I attached a TFT as well, and there is neighter anything to see, Sep 30 01:16:29 no, nor would there be any expectation of that Sep 30 01:16:50 so the kernel crashes relendlessly, without any trace Sep 30 01:17:52 when using the u-boot on eMMC it seems to start the kernel but crash afterwards (evidently before it can initialize the serial console), while the u-boot you put on SD card seems to crash in the process of transferring control to the kernel Sep 30 01:18:42 so yeah, your yocto system is broken quite badly Sep 30 01:20:20 okay, thank you so far, then this it's the yocto depatement I have to address Sep 30 01:20:52 indeed. there's probably a #yocto channel you can try for help Sep 30 01:21:12 Im on it ;-) Sep 30 01:21:22 thank you Sep 30 02:53:58 If I wanted to run a .sh script that seems to need to be altered via ' sudo ', what method would I use to change it to debian instead of root? For instance, chown or another tool? Sep 30 02:55:23 chgrp? **** ENDING LOGGING AT Thu Sep 30 02:59:56 2021