**** BEGIN LOGGING AT Thu Apr 12 03:00:05 2018 Apr 12 09:46:55 is git.ti.com down ?? or whats the thing today ?? Apr 12 09:49:02 seems like it Apr 12 09:50:38 ok at least its not just me Apr 12 09:53:45 kenrestivo: I don't know if you're interested, but for fun I also made an (incomplete, untested) hd44780 example using the LCD controller via py-uio: https://github.com/mvduin/py-uio/commit/78800b94 Apr 12 09:58:45 (I made the example for 4-bit interface since that seems to be most commonly used, even though it's a bit awkward) Apr 12 10:09:55 Hm, it seems that when flashing an image from the SD card to the EMMC, the SSH host key changes. Is this known and/or expected? Apr 12 10:10:47 Ah, seems that's intentional, probably to allow mass-flashing multiple BB's I guess Apr 12 10:14:05 that's expected yes Apr 12 10:14:55 hopefully /etc/machine-id too Apr 12 10:15:13 Doesn't look like Apr 12 10:15:38 :-/ Apr 12 10:15:40 /opt/scripts/tools# grep -r machine-id <-- returns nothing Apr 12 10:16:03 fortunately I use my own script Apr 12 10:17:00 dunno how likely it is to give issues in practice, but it *is* intended to be a unique id for the machine Apr 12 10:24:20 In my case, I start from a clean image for every machine, so that will be fine (which is why the ssh regeneration is annoying). I guess it would be good if the SSH key (and machine-id) regeneration would be optional. I'll open an issue at https://github.com/RobertCNelson/boot-scripts Apr 12 10:27:11 zmatt: Seems it might regenerate machine-id after all, controlled by the ssh.regenerate file: https://github.com/RobertCNelson/boot-scripts/blob/a890d66119f9b84505b4c162ce90ffce977475b5/boot/generic-startup.sh#L28-L32 Apr 12 10:28:29 you make a new flasher card for each beaglebone? wouldn't it make more sense then to flash the bbb via usb? (e.g. using a tiny bootable sd card that does modprobe g_mass_storage file=/dev/mmcblk1 ) Apr 12 10:28:58 to avoid having to flash each image twice (once to sd card, once to eMMC) Apr 12 11:29:10 Oh, that's an interesting thought Apr 12 11:30:59 Going through the SD card allows setting up a new system first and only when it really works, flash to eMMC, but that's less of an issue now I got the configuration sorted out. Still, I'm only working with a handful of boards, so it's not much of a big deal Apr 12 11:35:47 zmatt: https://github.com/RobertCNelson/boot-scripts/issues/81 Apr 12 12:05:10 i've run a qt widget application on EGLFS beaglebone Black. There are two QMainWindows. The First QMainwidow is loaded in fullscreen flawlessly but as i hit a button the next windows is instantiated and set to fullscreen but it isn't loaded as fullscreen indeed. Apr 12 12:05:10 Here's the image of the first Windows which is in fullscreen Apr 12 12:05:10 https://pasteboard.co/HggzcUI.jpg Apr 12 12:05:10 Here's the image of the second Screen loaded by the first one and it is not as we expected Apr 12 12:05:10 https://pasteboard.co/HggA1Zt.jpg Apr 12 12:05:12 I was wondering if anyone could help me how to make the second window full screen too! Apr 12 12:21:12 mehdi: Does it work on a normal Linux system? If not (an maybe if yes too), you might be better off asking in a QT-related channel. Apr 12 12:25:39 Yes it works in normal Linux system Apr 12 12:26:03 blathijs: i also asked in QT channel Apr 12 12:26:46 mehdi: Same window manager? Apr 12 12:32:18 no lxde Apr 12 12:42:06 That might also make a difference, AFAIU the window manager (or compositing manager as I think is used nowadays) is also involved in making something fullscreen Apr 12 13:14:05 blathijs: tanx Apr 12 13:58:16 mehdi: it works with eglfs on another system? Apr 12 13:59:30 "EGLFS forces the first top-level window to become fullscreen. This window is also chosen to be the root widget window into which all other top-level widgets (for example dialogs, popup menus or combobox dropdowns) are composited." Apr 12 14:00:05 could that be related to your issue? Apr 12 14:00:21 blathijs: eglfs means there's no window manager involved Apr 12 14:00:32 it's single-window-fullscreen Apr 12 14:01:32 mehdi: it sounds like you're simply trying to do something that eglfs doesn't support Apr 12 14:01:41 zmatt: Ah, sounds like that his exactly his issue indeed :-) Apr 12 14:06:13 mehdi: a few seconds of googling yielded the suggestion to use QStackedWidget to switch between different fullscreen "windows" (the children of the QStackedWdiget) Apr 12 14:59:13 zmatt: yes.you are right.eglfs does not support multliple windows Apr 12 14:59:59 zmatt: QStackedWidget , i heard about much memory use of QStackedWidget Apr 12 15:00:29 my project has 20-30 sub project Apr 12 15:01:42 and i think if i use QStackedWidget, my memory exceeded Apr 12 15:01:59 most recent version of beaglebone black firmware: how do you enabe UART2 serail port? Apr 12 15:02:16 mehdi: like I said, it was just something I found while googling, you may find better advice in a qt channel now that you understand what the core issue is Apr 12 15:03:18 mostlybutnotcomp: the port itself is enabled by default, all you have is configure the pins: config-pin P9.21 uart && config-pin P9.22 uart Apr 12 15:03:25 *have to do Apr 12 15:05:49 Sorry about that. My connect did something weird. What was that command for configuring the pins? Apr 12 15:06:14 config-pin P9.21 uart (and ditto for P9.22) Apr 12 15:08:01 Gives error: """Pin has no cape: P9_21""" Apr 12 15:08:17 are you booting from eMMC or SD card? Apr 12 15:08:24 SD card Apr 12 15:09:03 an old bootloader on eMMC is messing things up. easiest fix if you don't care about the current contents of eMMC is wiping it with: sudo blkdiscard /dev/mmcblk1 Apr 12 15:09:06 and then reboot Apr 12 15:09:23 (reflashing eMMC would also fix it of course) Apr 12 15:10:09 going with using blkdiscard for now. rebooting... Apr 12 15:13:13 zmatt, thank you so much! can see the device! Apr 12 16:17:14 zmatt: thanks man Apr 12 16:20:36 Hi all - I've noticed some Debian images have kernel version 'SMP' while some have 'SMP PREEMPT'. How can one tell which version a Debian image is without installing it to a microSD, booting, and running `uname -a`? Apr 12 16:21:06 I'm looking for the latest image that is just SMP, not SMP PREEMPT. Apr 12 16:22:10 FYI the latest non-GUI version returns to `uname -a`: Linux beaglebone 4.9.88-ti-r109 #1 SMP PREEMPT Sat Apr 7 03:19:20 UTC 2018 armv7l GNU/Linux Apr 12 16:29:07 sscirrus: it doesn't really depend on the image, just on the kernel, and more specifically the kernel config. you can inspect the image and check for CONFIG_PREEMPT=y in the /boot/config-* file Apr 12 16:29:26 or if you have the kernel version you can check it online: https://github.com/beagleboard/linux/blob/4.9.88-ti-r109/arch/arm/configs/bb.org_defconfig#L74 Apr 12 16:30:31 Is there a way to look it up from the 'latest-images' name? (bone-debian-9.3-iot-armhf-2018-03-05-4gb.img.xz) Apr 12 16:31:24 no, but I'm pretty sure CONFIG_PREEMPT has been enabled for a long time already Apr 12 16:31:33 I don't know why it would be disabled Apr 12 16:31:49 It's creating issues with a script I'm running Apr 12 16:32:03 ? Apr 12 16:32:06 The script is altering items in the /sys folder and it's failing with a SMP PREEMPT error. Apr 12 16:32:16 that sounds nonsensical Apr 12 16:32:25 there's nothing in /sys that's different on a PREEMPT kernel Apr 12 16:32:41 PREEMPT should be completely invisible other than in performance characteristics Apr 12 16:32:44 I flashed the device using the Oct 10th 2017 image (not SMP PREEMPT, just SMP) and it works every time Apr 12 16:33:04 what error are you getting exactly that is making you think it's related to PREEMPT ? Apr 12 16:33:04 It's changing the HID status Apr 12 16:33:20 It's a kernel failure, the first line is: kernel:[ 127.897553] Internal error: Oops: 5 [#1] PREEMPT SMP ARM Apr 12 16:33:51 PREEMPT isn't part of the error there, it's just mentioning it's a PREEMPT SMP ARM kernel Apr 12 16:33:59 can you pastebin the full oops? Apr 12 16:34:06 sure, one sec Apr 12 16:34:33 the difference will most likely be due to kernel version, not whether PREEMPT is enabled or not Apr 12 16:34:41 also, an oops is indicative of a kernel bug Apr 12 16:34:42 https://pastebin.com/Uzgibp2B Apr 12 16:35:20 so far, I've had this error on two kernels that say 'smp preempt' and not on a kernel that said 'smp' - that's why I thought it was the issue Apr 12 16:35:40 The two specific unames where it failed: Linux beaglebone 4.9.45-ti-r57 #1 SMP PREEMPT Fri Aug 25 22:58:38 UTC 2017 armv7l GNU/Linux Apr 12 16:35:41 okay this is saying nothing useful, there should be a traceback normally Apr 12 16:35:47 Linux beaglebone 4.9.88-ti-r109 #1 SMP PREEMPT Sat Apr 7 03:19:20 UTC 2018 armv7l GNU/Linux Apr 12 16:36:02 The version where it worked: Linux beaglebone 4.4.91-ti-r133 #1 SMP Tue Oct 10 05:18:08 UTC 2017 armv7l GNU/Linux Apr 12 16:36:07 can you pastebin the full output of the dmesg command? Apr 12 16:36:12 that's a big difference in kernel version Apr 12 16:36:16 a ton will have changed Apr 12 16:36:51 OK - let me run the script to produce the error then I'll pastebin the dmesg Apr 12 16:38:49 Here we go: https://pastebin.com/d6jS4Qsw Apr 12 16:39:31 it may be worth trying a few different kernel versions (you can install them with apt-get). maybe try 4.14.32-ti-r42, or if you don't specifically need features from the -ti kernel series you can also try 4.14.33-bone14 Apr 12 16:40:07 I'll try those two and report back. Thanks Apr 12 16:40:40 Hi! Apr 12 16:40:48 looks like your problem is a known issue Apr 12 16:40:48 enable-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>; Apr 12 16:40:55 sscirrus: https://patchwork.kernel.org/patch/9494173/ Apr 12 16:41:08 Where can I find how GPIO_ACTIVE_HIGH is defined as I don't have those includes available Apr 12 16:41:19 oh! i see Apr 12 16:41:30 so where can I find the versions that have this issue fixed? Apr 12 16:41:44 sscirrus: so the question is... is this was known more than a year ago, why does it still exist in 4.9 ? Apr 12 16:42:40 yeah... Apr 12 16:42:44 bou4: it's a standard header for device trees Apr 12 16:43:25 Is there a way to see if that issue is known to be fixed in the two kernels you suggested to me? Apr 12 16:43:41 bou4: if you're building an overlay, you may want to clone the https://github.com/RobertCNelson/bb.org-overlays repository and use its makefile to build your overlay Apr 12 16:43:58 bou4: and #include to get those definitions Apr 12 16:44:03 bou4: https://github.com/RobertCNelson/bb.org-overlays/blob/master/include/dt-bindings/gpio/gpio.h#L13 Apr 12 16:44:22 sscirrus: I'm poking around to see if I can figure out what happened Apr 12 16:44:59 Does that work even if the file is not in the folder that contains dt-bindings? Apr 12 16:45:08 Aha, didn't read the line above it Apr 12 16:45:17 sscirrus: meanwhile try the 4.14 kernel Apr 12 16:45:51 Thanks zmatt! Your help is really appreciated Apr 12 16:46:01 I wish the #alsa IRC channel was this active Apr 12 16:46:13 * bou4 spent the whole day debugging ALSA Apr 12 16:47:14 sscirrus: the relevant piece of code seems to have changed considerably in 4.14 Apr 12 16:47:30 so I'd guess it has been fixed Apr 12 16:48:51 final question, is gpio1_27 (the GPIO that enables the 24.576 MHz clock) connected to a pin? Apr 12 16:49:16 an external pin? no Apr 12 16:49:29 alright Apr 12 16:49:37 it's just a connection between the am335x and that oscillator Apr 12 16:50:27 Where can I find its offset? As I want to enable it in my device tree Apr 12 16:50:44 And if it's not a pin, I can't find it on Derekk's P9 table Apr 12 16:51:13 sscirrus: it looks like the fix was also backported to 4.9 series, it's in kernel 4.9.90 Apr 12 16:52:27 Found it! Apr 12 16:52:35 Awesome, thanks. I'm about to test 4.14 Apr 12 16:52:38 bou4: for a detailed list of all of the BBB's pins, see the "BBB" tab of my pins spreadsheet: https://goo.gl/Jkcg0w Apr 12 16:53:11 or check existing device trees at https://github.com/RobertCNelson/dtb-rebuilder/tree/4.9-ti/src/arm Apr 12 16:54:16 That seems to have worked. Thank you very much. There's no way I'd have figured this out by myself - too new to all this! Apr 12 16:54:36 https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-boneblack-audio.dts#L17-L28 this is how you declare the audio oscillator in a way that allows the kernel to automatically enable it when needed Apr 12 16:55:07 Perfect, thanks! Apr 12 16:55:17 I am interfacing the BBB with a audio codec Apr 12 16:55:30 Playing audio works, but recording doesn't Apr 12 16:55:39 I got "GBLCTL write error" in the kernel logs Apr 12 16:55:54 which codec? Apr 12 16:56:13 CS4272 Apr 12 16:56:15 GBLCTL write error means a clock is missing Apr 12 16:56:20 But then I found https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/346626/1224119?pi317334=2 Apr 12 16:56:39 From which it seams that a clock seems out of sync Apr 12 16:56:53 for which my next solution that I am going to try is to configure the codec as slave in stead of master Apr 12 16:57:08 both master and slave work Apr 12 16:57:49 Yes, but I think that the clock signals aren't clean enough for the BBB, which gives the GBLCTL write error Apr 12 16:58:11 So maybe if the BBB generates the clock signals it self, it won't produce this error Apr 12 16:58:15 At least that's my theory Apr 12 16:58:19 that sounds very implausible Apr 12 16:58:30 GBLCTL write error almost certainly means a clock is completely missing Apr 12 16:58:58 Why does playing audio then works actually? Apr 12 16:59:42 that *is* an interesting question. can you pastebin the device tree declarations you're using? Apr 12 17:00:25 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/alsa/devicetree/beaglebone-black-codec-alsa.dts Apr 12 17:05:03 ohh, this may be slightly tricky, since you're saying the codec is the source of the master clock, but that isn't true Apr 12 17:06:04 are you sure it isn't the source? Apr 12 17:06:24 as the codec produces MCLK Apr 12 17:06:35 very certain of that since I saw in the oscilloscope Apr 12 17:06:43 okay, but then you shouldn't enable the audio osc on the beaglebone obviously Apr 12 17:06:56 since that would result in a drive conflict Apr 12 17:07:01 my uboot config disables hdmi and audio Apr 12 17:07:19 and I thought that that also would disable the audio osc Apr 12 17:07:33 yes Apr 12 17:07:36 but I check all clock lines of the McASP with the scope Apr 12 17:07:41 and there was nothing on them Apr 12 17:08:03 I was just making wrong assumptions since you asked about it earlier Apr 12 17:08:28 aha, I was doing that because I am writing another device tree to test it, but with the codec configured as slave Apr 12 17:08:35 to see if I am then able to record audio Apr 12 17:09:14 slave vs master usually just refers to the bitclock and lrck, the master clock is a separate configuration choice Apr 12 17:10:37 also, I once made a little util to monitor the state of mcasp0: https://liktaanjeneus.nl/asp-monitor.tar.xz maybe it's useful Apr 12 17:11:02 are you seeing these problems intermittently or consistently? Apr 12 17:11:12 have you tried starting recording while playback is in progress? Apr 12 17:11:48 Thanks for that util! Apr 12 17:12:03 and I am seeing the problem consistently Apr 12 17:12:22 every arecord results in a "GBLCTL write error" in the logs Apr 12 17:12:31 while aplay works just fine Apr 12 17:12:46 and I tried arecord | aplay, which also didn't work Apr 12 17:13:09 really strange Apr 12 17:13:14 But playback of another file and recording at the same time is something I didn't try yet Apr 12 17:15:12 the linux mcasp driver configures it into synchronous rx/tx mode (I had to hack in support for async rx/tx myself when I needed it), so I don't understand how the rx section can be missing a clock when the tx section works fine Apr 12 17:16:13 it would have been helpful if the mcasp driver logged what it was trying to write to GBLCTL and what value it got back Apr 12 17:16:44 That is what I am going to try next if configuring it as a slave doesn't work out Apr 12 17:16:50 Adding printk's to the davinci driver Apr 12 17:22:14 But is it not possible that configuring it a slave will work? Apr 12 17:22:35 maybe, I really have no idea what the issue could be Apr 12 17:22:38 other than "it's clock related" Apr 12 17:22:43 Than it doesn't rely on someone's others clocks Apr 12 17:22:52 So I think my biggest chance is in configuring it a slave Apr 12 17:22:53 yeah maybe there's something odd going on with power management or something Apr 12 17:23:22 Do you know of a handy tool for generating the values of the pinmux Apr 12 17:23:32 I once had a spreadsheet that calculated it for me Apr 12 17:23:34 use the macros Apr 12 17:23:56 also, to make your overlay more readable, you can consider my overlay-utils Apr 12 17:23:58 https://github.com/mvduin/overlay-utils Apr 12 17:24:20 (it also includes macros for pinmux) Apr 12 17:24:30 May I include it in my repo? Apr 12 17:24:35 It is BSD licensed Apr 12 17:25:29 no problem, you can consider it public domain as far as I'm concerned Apr 12 17:26:12 the only significant code is in the perl script that preprocesses the sources (to turn normal DT fragments into the hideous syntax required for overlays) Apr 12 17:26:39 oh I see, won't they work with just using dtc? Apr 12 17:27:15 or can't I just add the defines at the top of my device tree Apr 12 17:28:04 https://pastebin.com/77NnUV5A Apr 12 17:28:11 that's what my perl script does Apr 12 17:28:13 roughly Apr 12 17:28:53 makes things a lot easier on the eyes Apr 12 17:29:20 plus it's the same syntax as you'd use when customizing the main device tree source, so you can easily port stuff between normal DTs and overlays Apr 12 17:30:07 and yeah you can use my macros separately of course... although there are now also pinmux macros upstream (albeit using different syntax) Apr 12 17:31:53 Aha, alright! Apr 12 17:32:03 And what is the point of configuring an output as pull up? Apr 12 17:34:38 "output" just means "input disabled" Apr 12 17:34:50 it might still be high-Z Apr 12 17:35:28 either that or just didn't want to spend any thought on it Apr 12 17:37:35 Alright, I think I know enough Apr 12 17:37:39 Thanks for all the help Apr 12 17:38:28 I am going to the lab tomorrow, I hope it get it to work by configuring it as a slave Apr 12 17:38:31 https://pastebin.com/3xVmeVjD Apr 12 17:38:47 here's an example of both versions of the pinmux macros Apr 12 17:39:31 Cool! Apr 12 17:44:04 bou4: btw it looks like that using the audio osc on the beaglebone would be complicated in your case, since to make the codec treat mclk as input you'd need to disconnect its crystal from XTI/XTO (and ground XTI) Apr 12 17:44:46 but using the codec to produce the master clock shouldn't be a problem Apr 12 17:54:47 zmatt, shouldn't be a problem, I made the PCB myself Apr 12 17:55:08 I am going to cut he traces Apr 12 17:55:13 okay, but regardless it seems unlikely to be necessary Apr 12 17:55:15 I am going to cut the traces Apr 12 17:55:16 just try slave mode first Apr 12 17:55:30 how do you mean? Apr 12 17:55:42 that's what I am doing now, ain't I? Apr 12 17:56:22 your DT configured the codec as master right? try configuring cpu as master instead Apr 12 17:56:45 Aha, what will that change in terms of clocks? Apr 12 17:57:20 which side is driving the frame sync (lrck) and bit clock signals Apr 12 17:58:56 my best guess would be something weird is going on with starting up those clocks Apr 12 17:59:06 Aha, thanks! Apr 12 17:59:13 if mcasp is responsible for them itself, less risk of issues Apr 12 17:59:20 True that Apr 12 17:59:32 I think I know what to do tomorrow Apr 12 18:00:22 Thanks for all the help! Apr 12 18:00:31 I'll let you know if it worked Apr 12 18:00:58 I got 4 weeks left to produce a working DSP cape for the BeagleBone Apr 12 18:01:44 in case it's useful, these are the audio-related kernel patches I'm using myself: https://github.com/dutchanddutch/bb-kernel/commit/6d02c63ab001 Apr 12 18:02:16 What fixes your patches? Apr 12 18:03:50 to be honest it's too long ago to remember exactly why I did all the things I did, but part of it was supporting async rx/tx, which you don't need, but I also seem to do things differently with starting up clocks Apr 12 18:04:31 Alright! Apr 12 18:05:14 See you Apr 12 18:05:17 (I also added a generic TDM "codec", which we use for interfacing with an external DSP) Apr 12 18:05:20 later Apr 12 18:05:31 Cool! Apr 12 18:06:24 but mainly my different clock startup might be worth a try Apr 12 18:06:43 Okidoki! Apr 12 18:06:58 I sincerely hope my codec works tomorrow Apr 12 18:07:06 Spent too many hours debugging already Apr 12 18:07:17 Getting a PCB to work wasn't easy Apr 12 18:07:21 yeah it looks like it ought to have been straightforward to interface it Apr 12 18:07:39 I had a problem with ringing Apr 12 18:07:55 Which made that I2C worked when that was the only connected to the PCB Apr 12 18:08:16 But when I connected the I2S lines, the noise became too much for I2C to work Apr 12 18:08:42 huh, what do those two have to do with each other? Apr 12 18:08:51 or you mean cross-talk issues? Apr 12 18:08:56 Cross-talk indeed Apr 12 18:09:12 And somehow connecting it all up, made it worse Apr 12 18:09:23 But some resistors fixed it Apr 12 18:09:39 My output isn't as clean as it should be, but that's a problem for future versions Apr 12 18:09:39 series resistors at the driving side of the i2s is a good idea yeah Apr 12 18:09:53 although omitting it shouldn't fuck up a neighbouring i2c Apr 12 18:10:29 but I think stuff like a discontinuous ground plane might cause that Apr 12 18:10:36 Yes, it was Apr 12 18:10:52 The crystal lines where crossing the ground plane beneath the I2S lines Apr 12 18:11:03 But I already fixed that too Apr 12 18:11:37 But good, now I really need to leave, thanks for all the help! Apr 12 18:11:47 ah yeah then the return current would try to find a different route, and the high-impedance i2c lines are an easy victim Apr 12 18:11:55 okay! Apr 12 20:12:15 greetings everyone Apr 12 20:13:00 can someone help me with drivers for the bb blue? Apr 12 20:20:29 ok then. I'll go back to google Apr 12 20:24:02 lol Apr 12 20:33:12 much better Apr 12 20:40:50 Well. I don't know Apr 12 20:46:24 I am using Stretch IoT from https://beagleboard.org/latest-images on a BeagleBone Black, I see that it is using libcomposite and USB gadget configfs to set up the virtual USB devices, and I am trying to add an HID device to this mix Apr 12 20:47:29 and I have some commands that I have used on a Pi Zero to achieve something similar, except that on the Pi Zero it is setting things up from an empty /sys/kernel/config/usb_gadget directory, so I tried to adapt these commands to add things onto existing configfs Apr 12 20:47:57 this is sufficient to get the module usb_f_hid to load, but I don't see /dev/hidg0 appearing, nor anything in dmesg, nor does the USB host detect any new devices Apr 12 20:48:39 this may be because I'm initializing something wrong, and I'd rather edit the existing configuration to create the necessary files in configfs for HID at bootup along with everything else Apr 12 20:49:05 but... where anywhere in that image are the configuration/scripts responsible for inserting the libcomposite module and /sys/kernel/config/usb_gadget? Apr 12 21:15:55 hodapp: somewhere in /opt Apr 12 21:16:11 try grep -r usb_gadget /opt Apr 12 21:17:08 note that you can't dynamically add functions to an usb_gadget that's already enabled. it can only be modified while disabled Apr 12 21:23:45 trying to disable & re-enable leads me to http://lpaste.net/2792420472652824576 Apr 12 21:24:36 hah, second person today Apr 12 21:24:50 cool, do I win a prize? Apr 12 21:25:09 that's a kernel bug, upgrade the kernel to 4.14 Apr 12 21:25:12 bleh Apr 12 21:25:32 can one do this easily on that image? Apr 12 21:26:15 sure Apr 12 21:26:28 and what does the bug affect in particular? Apr 12 21:26:39 it causes that specific crash Apr 12 21:26:43 it's a bug in f_hid Apr 12 21:27:15 oh... Apr 12 21:27:41 sudo apt update && sudo apt install linux-image-4.14.32-ti-r42 Apr 12 21:28:33 oh, awesome, thanks Apr 12 21:28:49 there's also a kernel update script somewhere in /opt but I've never used it so no idea how it works Apr 12 21:29:23 my image is already nearly a stock image. I'll just try the apt way and if it destroys everything just nuke the SD card Apr 12 21:29:38 lol Apr 12 21:32:20 the script basically does the same thing, but it checks for you what the latest version is within the series you want and cleans up unused old kernels, stuff like that Apr 12 21:33:07 w00t. upgrade worked, my script no longer causes a null pointer deref, and the HID device appeared Apr 13 02:10:16 is there any reason why someone would need to insert the sdcard to upgrade between major versions of debian on a beaglebone black? Apr 13 02:12:11 lets say im running 8.10 and want to update to 9.3 Apr 13 02:30:03 all upgrade instructions i can find seem to indicate these upgrades must happen by reflashing from the sdcard Apr 13 02:43:15 if that is the case, i guess it means there is some aspect of the software that can't be updated through apt **** ENDING LOGGING AT Fri Apr 13 03:00:02 2018