**** BEGIN LOGGING AT Fri Jan 04 02:59:57 2019 Jan 04 06:37:24 hi all Jan 04 11:56:18 I'm getting a CMEM error on BeagleBoard-X15 OpenCL. This is with the latest Ubuntu 18.04. Jan 04 11:56:27 http://www.w6rz.net/cmem.png Jan 04 13:07:07 drmpeg: have you tried using the latest recommended debian image? Jan 04 13:08:21 Yes, it does work on Debian. Jan 04 13:08:37 okay, problem solved then Jan 04 13:12:39 Yeah, but it seems it should work on Ubuntu too. Jan 04 13:14:22 it should work on the images available for download from beagleboard.org. you can't always expect the same from random other distros Jan 04 13:15:03 it's enough work to maintain one distro Jan 04 13:16:12 my guess would be that it worked on ubuntu images at some point in time, but since nobody uses ubuntu it doesn't get tested hence doesn't get noticed when it breaks Jan 04 13:18:02 This is from Robert Nelson. https://elinux.org/BeagleBoardUbuntu Jan 04 13:18:14 I know it is Jan 04 13:18:22 that doesn't really change anything about my statement Jan 04 13:18:42 If nobody uses Ubuntu, why does he bother updating it? Jan 04 13:19:05 good question, I have no idea Jan 04 13:20:19 obviously saying "nobody" uses it is hyperbole on my part, but it is likely to be a very small number of users compared to the default distribution Jan 04 13:49:31 road less traveled etc Jan 04 15:15:33 anyone using canbus on BeagleBoard.org Comms Cape A2? i have it on a bbb revC running a 4.14.71-ti-r80 kernel which brings by default can0 and can1, but neither one seems to work. there's a lot of hits on google concerning canbus on bbbs, but i can't find relevant infos on that particular cape and a recent kernel. any pointer would be appreciated Jan 04 15:21:34 samael: I'd make doubly sure that the proper device tree nodes are there and then also look at the pins if there are any sort of signals that look like they should Jan 04 15:31:05 tbr: i'm largely used to 3.8 kernels, only recently migrated to 4.14 ti ones, and currently feeling confused about device tree management. i always missed a properly done documentation summing up important highlights needed to manage them on different kernel versions Jan 04 15:31:19 m Jan 04 15:32:04 anyway, FWIW, uboot seems to detect the cape and properly set the kernel cmdline Jan 04 15:45:53 samael: you're saying it exposes two can interfaces? that's ... interesting Jan 04 15:46:11 given that one of the two can interfaces of the bbb conflicts with cape autodetection Jan 04 15:46:47 samael: maybe check what the actual pin configuration is using my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins Jan 04 15:47:40 zmatt: i always have two can interface when booting with that kernel, regardless of the actually installed capes. Jan 04 15:47:54 I don't actually see any overlay for the comms cape in the bb.org-overlays repository, so I suspect that you're simply seeing the can interfaces defined by cape-universal and no pinmux by default at all Jan 04 15:48:07 in which case you'll need to configure the pins before you can bring up the interfaces Jan 04 15:50:11 at some point i guessed that, but apart of my ignorance on device tree drivers management with this kernel, i'd expect to find at least the basic documentation about a project-official cape Jan 04 15:50:53 yeah that would be nice, but the information available about this cape and several others appears to be severely lacking Jan 04 15:51:06 (unless this is all done to confuse the enemy. in that case, it's all well done :D) Jan 04 15:51:35 I don't even see a pdf of the schematic here -> https://github.com/beagleboard/capes/tree/master/beaglebone/Comms Jan 04 15:52:40 yeah, that's the first place i checked, and got discouraged Jan 04 15:52:54 jkridner[m]: ^ Jan 04 15:52:56 jkridner[m]: ping **** ENDING LOGGING AT Sat Jan 05 02:59:56 2019