**** BEGIN LOGGING AT Thu Aug 29 02:59:57 2019 Aug 29 13:08:28 m Aug 29 14:01:45 test Aug 29 14:06:18 I have installed debian 9.5 lxqt on beaglebone black. https://libreboot.org/docs/install/bbb_setup.html sudo ls /dev/spidev* returns what it is supposed to do. But ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 returns ./flashrom command not found. Why does flashrom not work? Aug 29 14:08:16 sudo which flashrom returns /usr/sbin/flashrom Aug 29 14:14:54 test Aug 29 14:17:13 I have installed debian 9.5 lxqt on beaglebone black. https://libreboot.org/docs/install/bbb_setup.html sudo ls /dev/spidev* returns what it is supposed to do. But ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 returns ./flashrom command not found. Why does flashrom not work? Aug 29 14:17:38 sudo which flashrom returns /usr/sbin/flashrom Aug 29 15:35:53 flj: "./flashrom" means you explicitly specify that this program is located in the current directory. the error implies that it is not located there Aug 29 15:37:24 there's no need to do any of this as root btw, nor to use sudo Aug 29 15:38:53 (the debian user is a member of the "gpio" and "spi" groups by default) Aug 29 16:02:24 On a Beaglebone Black running Debian 10 and rcn's latest 4.14 kernel. What does it take to move from the fbdev driver to modesetting driver? Just replacing the driver line in the Device section gets me a black screen, and EE errors in Xorg.0.log: Aug 29 16:02:29 (EE) modeset(0): failed to set mode: Invalid argument Aug 29 16:02:41 and earlier: (EE) modeset(0): glamor initialization failed Aug 29 16:05:49 Thank you. Then what should command ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 then look like? Or where is flashrom located? Aug 29 16:09:08 flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 Aug 29 16:09:42 And your which command shows us that will run: /usr/sbin/flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 Aug 29 16:13:27 Actually you ran which under sudo, so /usr/sbin might not be in your path. In which case run it like the second example /usr/sbin/flashrom -p... Aug 29 16:16:43 why is it in /usr/sbin anyway? it seems the instructions you were trying to follow suggest compiling it from source Aug 29 16:17:20 samnob: you'd need to debug why modesetting is failing I guess, the kernel driver should support it just fine Aug 29 16:17:52 flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 did not work. Aug 29 16:18:48 test Aug 29 16:18:51 test Aug 29 16:19:09 what are you hoping to accomplish by typing "test" here? Aug 29 16:20:05 test is because sometimes wifi disconnects and sometimes my messages do not show. Aug 29 16:20:34 typing a test message is not going to help you determine whether or not it arrives Aug 29 16:21:22 writing /usr/sbin/flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 did work. Aug 29 16:22:32 if test displays then my next message may also display. Aug 29 16:22:59 thanks. I stop. Aug 29 16:27:46 xserver-xorg-video-modesetting seems to have moved to a virtual package provided by xserver-xorg-core. So nothing comes to mind as missing packages. Aug 29 16:29:12 Am I safe to assume that if HDMI is working (with fbdev) that it's not a devicetree or pinctrl issue? Aug 29 16:29:15 https://www.spinics.net/lists/dri-devel/msg154127.html maybe this is related Aug 29 16:29:49 yeah it's either a kernel driver issue, an xorg issue, some weird interaction issue, or a configuration issue Aug 29 16:30:30 maybe pixelformat issue if xorg isn't told to use 16-bit and lacks decent detection for supported pixelformats Aug 29 16:31:26 I'm pretty sure the kernel driver should be working, though I can't remember whether I've actually done testing with drm on a beaglebone Aug 29 16:33:07 except that we do use qt5 with the eglfs backend (after getting the SGX drivers working). I did need to patch qt5 to fix a pixelformat issue (it turned out to be using hardcoded 24-bit color) Aug 29 16:33:37 pixelformat? I've tried with "defaultdepth 16" in the Screen section, but I've had that commented out for the last few tests. Aug 29 16:35:00 it is possible for userspace to query the kernel to determine supported pixelformats, hence manually specifying defaultdepth *ought* not to be required... of course that assumes someone bothered to implement proper autodetection :P Aug 29 16:37:29 it also assumes the devicetree correctly specifies the "blue-and-red-wiring" property, which is the case in current overlays Aug 29 16:38:03 (otherwise userspace could autodetect the wrong depth and end up with red and blue channels swapped) Aug 29 16:40:17 Ah, progress, uncommenting DefaultDepth 16, got me a login screen, though the BBB then immediately locked up. Aug 29 16:40:25 lol Aug 29 16:40:56 weird that this still has issues after so much time Aug 29 16:45:36 Hmm, maybe there's an interplay with USB? The monitor's USB hub hosts my keyboard and mouse, and that's ordinarily connected to the BBB. When it crashed I moved that. It rebooted fine, I was examinging Xorg.0.log (via ssh) all seemed good. So I move back the USB and boom it's down. Aug 29 16:46:50 I'm perfectly willing to believe usb issues, although interplay between usb and video stuff seems unlikely Aug 29 16:47:50 did it cause a kernel panic? Aug 29 16:49:51 Yeah, (though I'm not currently set up to watch any console besides tty0) Aug 29 16:50:37 But it fully locks up. I just tried a power-on with the USB attached and it was happy until I moved the mouse. Then locked up hard again. Aug 29 16:50:50 ah, a serial cable is definitely useful for debugging kernel driver issues obviously Aug 29 16:53:04 I was about to ask about the gadget console over USB, but that would be dumb in this scenario. So off to the car for the ttl. Aug 29 16:53:18 lol yes Aug 29 17:17:24 Hmm, so I boot up to lxdm greeter (No USB attached.) login to ttyS0, plug in USB hub with mouse and keyboard. An appropriate number of messages appear from usb and input, so I think there's a kernel console on ttyS0 (though /proc/cmdline [and uEnv.txt] shows ttyO0). But a few seconds after moving the mouse, no further messages, and BBB is locked up. (At ttyS0 plus all ssh sessions die and device doesn't Aug 29 17:17:30 ping) Aug 29 17:18:08 hm Aug 29 17:18:40 http://samnoble.org/tmp/BBB_xorg.conf Aug 29 17:20:19 http://samnoble.org/tmp/BBB_xorg.conf_nocomments Aug 29 17:26:38 Fresh boot, no USB yet. LXDM greeter. This showed up on the console after a few minutes: Aug 29 17:26:41 [ 655.812329] tilcdc 4830e000.lcdc: tilcdc_plane_atomic_check: Size must match mode (0x0 == 1280x1024) Aug 29 17:27:24 Some config I tried previously complained about a lacking tilcdc .so Aug 29 17:28:18 how on earth does something like that manage to only show up after a few minutes Aug 29 17:29:04 "a lacking tilcdc .so" ? there's no shared library specific to tilcdc, it just uses the generic DRM interface Aug 29 17:29:46 Sorry I'm trying to find/remember better details. Aug 29 17:34:40 So this is a "At some point I saw" so feel free to ignore. I think it may have been in an Xorg.0.log, but it couldn't find tilcdc_dri.so in /usr/lib/arm-linux-gnueabihf/dri/ Aug 29 17:35:59 I'm mentioning this becouse it's the only other reference to tilcdc I've seen onther than Size must match mode message pasted above. Aug 29 17:36:33 it must have autogenerated that library name from the kernel driver name (which is "tilcdc") since no such library exists, or has ever existed Aug 29 17:37:34 I think it has to do with 3D acceleration, which is not supported for X11 on the AM335x Aug 29 17:38:00 it has nothing to do with the kernel message you pasted Aug 29 17:38:41 the reason "tilcdc" shows up in both is simply that it is the kernel driver name Aug 29 17:39:03 Got it. TI LCD Controller? Aug 29 17:39:10 yeah Aug 29 17:39:24 grep -i tilcdc /boot/config-4.14.108-ti-r115 Aug 29 17:39:26 CONFIG_DRM_TILCDC=y Aug 29 17:39:35 yep, that one Aug 29 17:40:29 But modesetting 's the correct name for xorg.conf Aug 29 17:41:32 it would be the correct driver to use when not using fbdev yes (which is what is used more commonly I think... among the rare few people who think it is a good idea to run X11 on a beaglebone in the first place) Aug 29 17:42:19 * samnob doesn't feel attacked at all :-D Aug 29 17:42:30 lol Aug 29 17:44:07 I mean, it's fact. the graphics capabilities of the AM335x are pretty minimal, with lcdc not even supporting a hardware cursor. it's meant for supporting simple touchscreen interfaces, not for running a desktop environment Aug 29 17:45:31 also, TI officially doesn't support X11 anymore Aug 29 17:47:27 Yeah, I'm using it 90% as a VNC thin client. It's been pretty good in this role. But only works reliably in one oldish monitor. I'm hoping modesetting and xrandr will be more flexible. Aug 29 17:47:40 than fbdev Aug 29 17:47:56 that seems very unlikely Aug 29 17:49:41 for fbdev, the kernel performs modesetting by selecting the preferred mode based on the monitor's advertised modes and LCDC's capabilities. when using the modesetting driver, it will by default pick exactly the same mode marked as preferred by the kernel Aug 29 17:51:59 Right. So best I'm hoping for here is getting xrandr working. Aug 29 17:53:18 I mean, I guess it's more "flexible" in the sense that you could have a script pick a different mode based on some criteria, although if the preferred mode isn't working then that either implies the monitor advertises bullshit or there's a kernel bug which should be fixed Aug 29 17:54:01 if you don't need to pick the mode dynamically you can also specify it in the "video" kernel parameter Aug 29 17:55:32 if you're using it just as vnc thin client, an even better solution would be a vnc client that uses drm directly instead of using X11 Aug 29 17:56:30 but that aside Aug 29 23:48:52 Hello. How can I test on the BBBlue for temp. warnings of my processor? I am running arducopter and flying but the board, the BBBlue, is becoming severely hot. Aug 29 23:48:54 ... Aug 29 23:50:47 The fellows that ported the ArduPilot source to the BBBlue seem to not think that the boards got hot. Aug 29 23:51:00 I will keep searching Linux commands while I wait. Aug 29 23:55:28 Has anyone used lm-sensors on the BBBlue yet? Aug 30 00:39:32 well hell. Aug 30 00:39:48 I think "ut oh" basically w/ the lm-sensors library. Aug 30 00:40:18 It kicked out the ArduCopter .service and stalled for eternity. Aug 30 00:50:27 I tried watch, too. **** ENDING LOGGING AT Fri Aug 30 03:00:27 2019