**** BEGIN LOGGING AT Tue Jul 26 02:59:58 2016 Jul 26 06:45:50 join Jul 26 06:46:19 any one used bleagleboard green wireless bluetooth? Jul 26 12:15:51 I am trying to get MCP2515 to work with the beaglebone, but i get a spi probe error, [ 1051.160265] mcp251x: probe of spi2.0 failed with error -2, when i manualy load it. If i load it in uEnv.txt it just says that it fails, with no error message. Jul 26 12:16:30 I tried to load just my spi driver manually, and that does not work, but it works if i load it from uEnv.txt Jul 26 13:08:17 Could really need some help! Have been trying to get this to work for the last week Jul 26 15:40:30 laurittr: Maybe also try a beaglebone subreddit? Jul 26 18:46:07 Hi everyone, I have some problems with peripherals when using Debian 8 or Ubuntu 16. For example my UARTs don't get any data when checking via minicom. I had no problems with older version of the kernel (ver 3.8). This situation is present on nearly clear installation (some apt-get updates, upgrades only). Any dieas? Jul 26 19:58:38 laurittr: which kernel/image? the new universal cape stuff should have the SPI driver already loaded, waiting for you to set the pinmux to use it, at least by my understanding. Jul 26 20:02:20 jkridner: output from uname -a Jul 26 20:02:21 debian@arm:~$ uname -a Jul 26 20:02:21 Linux arm 4.4.14-bone11 #1 Sat Jul 2 19:14:30 UTC 2016 armv7l GNU/Linux Jul 26 20:03:04 k. I'm less familiar with the -bone kernels as of late.... Jul 26 20:03:25 with the latest -ti kernels, you can use uio for the PRUs, so not so much need to use -bone anymore. Jul 26 20:03:41 4.4.15-ti-rt-r37 is what I'm currently using. Jul 26 20:04:13 Are the bone kernels being phased out? Jul 26 20:04:33 hmmm.... but I'm not seeing any /dev/spi* ... looking deeper. Jul 26 20:05:05 MathOnNapkins: don't think so.... rcn-ee would know best, but I assume -boneX will stick around longer than 4.4. Jul 26 20:05:26 Okay thanks Jul 26 20:06:30 So i should change to the ti kernel? Jul 26 20:06:56 jkridner: gave beagleboard.org some mention in my talk a few weeks ago: https://debconf16.debconf.org/talks/19/ Jul 26 20:07:05 * jkridner looks around https://github.com/RobertCNelson/linux-dev/tree/master/patches Jul 26 20:07:12 vagrantc: thanks! Jul 26 20:07:32 laurittr: I would, but it might be tangential to your challenge right now. Jul 26 20:07:34 one of many, but the bbx15 has held up pretty well compared to others Jul 26 20:08:25 * vagrantc still needs to debug why u-boot 2016.07 fails to boot, but 2016.07-rc3 worked fine Jul 26 20:10:32 root@beaglebone:/sys/class/spi_master# ls Jul 26 20:10:32 spi1 spi2 Jul 26 20:10:36 not sure if this is informative: ^^^ Jul 26 20:11:31 I've already got spi working, but what kernel should i choose? Jul 26 20:12:20 ah: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts Jul 26 20:12:51 Yeah, thats close to what i am using Jul 26 20:13:03 i just replaced one of the channels with the mcp2515 device Jul 26 20:13:06 root@beaglebone:/sys/class/spi_master# config-pin overlay BB-SPIDEV0 Jul 26 20:13:07 Loading BB-SPIDEV0 overlay Jul 26 20:13:15 root@beaglebone:/sys/class/spi_master# ls /dev/spidev1.* Jul 26 20:13:15 /dev/spidev1.0 /dev/spidev1.1 Jul 26 20:13:43 I'd recommend general development use the 4.4.X-ti series. Jul 26 20:13:44 http://dpaste.com/3FPHG14 Jul 26 20:14:03 Ok, il change to that one and see what happens Jul 26 20:14:24 Could you see if i got the interrupt pins right in my dts on dpaste? Jul 26 20:15:13 it would be easier to read if the "4" in "<21 4>" used one of the macros. Jul 26 20:15:27 I can't recall off the top of my head what edges that means. Jul 26 20:15:37 using GPIO 3.21? Jul 26 20:16:13 confirmed with: http://dpaste.com/3FPHG14#line-14 Jul 26 20:17:24 Yea, i think gpio3_21 is located on p9.25 Jul 26 20:19:17 https://www.kernel.org/doc/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt doesn't seem to have http://dpaste.com/3FPHG14#line-67 Jul 26 20:20:17 So i should remove those 3 lines Jul 26 20:20:50 I see the interrupt is 0x02 on that kernel documentation site Jul 26 20:21:05 i had 4 on my overlay, so thats probably wrong? Jul 26 20:22:15 vagrantc: thanks for the ack! Jul 26 20:22:52 laurittr: don't know if it should be removed or not... probably best to look at the source rather than the documentation. Jul 26 20:28:17 jkridner: found the source, but I honestly have no clue what to look for Jul 26 20:28:17 https://github.com/RobertCNelson/linux/blob/master/drivers/net/can/spi/mcp251x.c Jul 26 20:35:18 tomba: I've got tiler working at very decent performance on omap5 btw :) Jul 26 20:35:23 laurittr: yeah... don't see it. Jul 26 20:35:31 zmatt: would that work on X15 too? Jul 26 20:35:33 yo jkridner, sup? Jul 26 20:35:34 yes Jul 26 20:35:45 zmatt: is it in our distro images? Jul 26 20:36:03 zmatt: I've seen our GUI performance be something much less than it SHOULD be. Jul 26 20:36:20 zmatt: what do we need to do to integrate? Jul 26 20:36:28 apparently xf86-video-omap is also pig-slow but I haven't looked into that really Jul 26 20:36:34 clue.apk Jul 26 20:36:36 * ds2 runs Jul 26 20:36:36 pyra uses the fbturbo driver for x11 instead Jul 26 20:37:13 ds2: your android related insults are lost on me. Jul 26 20:37:28 :D Jul 26 20:37:48 I've only just gotten userspace access to tiled memory working well yesterday, and it involved some hackery that's not exactly upstreamable quality :D Jul 26 20:38:16 mostly disabling some machinery in the omapdrm driver that presuably was there for a reason Jul 26 20:38:27 zmatt: demo quality is worth playing with. Jul 26 20:38:34 https://github.com/mvduin/linux/branches Jul 26 20:38:52 for performance testing -> https://github.com/mvduin/omapdrm-test Jul 26 20:39:35 the four patches on patch/tiler-fast are the relevant ones Jul 26 20:40:15 hmmm.... seems without X11 integration, I wouldn't know how to demo it. Jul 26 20:40:18 patch/fast-nc-read speeds up read access to normal non-cacheable memory, which is not related to tiler though Jul 26 20:40:33 ds2: you played with monitor mode on a wl18xx? Jul 26 20:40:51 patch/tiler-fast should make xf86-video-omap a LOT faster when rotated using xrandr Jul 26 20:41:06 jkridner: no...but I might be about to... bringing up a board with that module right now Jul 26 20:41:15 fast-nc-read probably speeds up other cases of x11 Jul 26 20:41:20 ds2: It says it (mdk3) is sending packets (beacon floods), but none of my wifi clients seem to see them. Jul 26 20:41:34 ds2: also, airodump-ng doesn't grab anything. Jul 26 20:42:15 jkridner: also, why x11 integration? TI seems to be going full wayland Jul 26 20:42:23 :P Jul 26 20:42:46 ds2: cool. not sure what reference you are using. seeed beaglebone green wireless is something to start, but I have some other options that might be interesting, depending on what you are doing. Jul 26 20:42:57 zmatt: Wayland is fine... think I can do X11 emulation that way. :-) Jul 26 20:43:25 jkridner: it might be you don't have the correct firmware loaded.. at one point there were several flavors Jul 26 20:43:50 patch/fast-nc-read affects all read accesses to normal non-cacheable memory Jul 26 20:44:10 ds2: k. driver thinks its in monitor mode.... do you know where I can grab some firmware blobs? Jul 26 20:44:11 jkridner: the HW engineer for this board whipped it up straight from the WL datasheet.. so no real reference Jul 26 20:44:17 let me look Jul 26 20:44:24 patch/tiler-memtype benefits all use of tiler (via omapdrm) Jul 26 20:44:40 actually patch/tiler-fast (which is based on top of it) Jul 26 20:45:02 knowledgable drm client can get more performance however if they promise to write only and not read Jul 26 20:45:12 but the x11 driver reads Jul 26 20:45:56 (current linux uses 'strongly ordered' memory type, patch/tiler-memtype changes that to 'device' with the option for 'normal non-cacheable' if userspace explicitly asks) Jul 26 20:46:38 patch/tiler-fast additionally allows a tiled buffer to be mapped entirely into userspace Jul 26 20:47:10 jkridner: from the source, it looks like only the WL12 uses different firmwares... the WL18 seems to use only one firmware Jul 26 20:47:18 so nix what I said Jul 26 20:47:24 right now there are two pages that are used round-robin for accessing a tiled buffer from userspace, so a fill of the whole framebuffer costs you typically 2*(number of lines) pagefaults Jul 26 20:47:49 versus 0 with my patches Jul 26 20:48:16 the price tag is being a bit more wasteful with tiler's virtual memory space Jul 26 20:50:21 tiler's virtual memory however is 8192 x 4096, enough for 12 framebuffers at 1920x1080 or 30 framebuffers at 1280x720 Jul 26 20:50:42 so I don't feel an urgent need to be extremely conservative with it Jul 26 20:50:57 (8192 x 4096 pixels @ 32-bit depth) Jul 26 20:51:39 jkridner: thanks for the help, il see if i can get it working now Jul 26 20:54:11 jkridner: I intend to do a proper write-up about what's up with tiler on omap5/vayu Jul 26 20:55:08 basically there's some tiler behaviour that escalated from inconvenient to outright erratum when it was combined with the cortex-a15 Jul 26 20:55:27 you can equally well blame the cortex-a15 though, that thing behaves in really bizarre and obnoxious ways Jul 26 20:57:05 as a workaround for the resulting bus-errors a "fix" was subsequently applied to the omapdrm driver that rendered it basically unusably slow Jul 26 21:12:01 'evening Jul 26 22:14:21 hi Jul 26 22:14:36 anybody there Jul 26 22:15:54 i need advice whether to buy a bbb or noe Jul 26 22:29:08 .. if you have to ask .. the answer's probably no... Jul 26 23:04:23 @#%$@!$*@#&$*#@&*!@#(!@&#*(!@#)!*@)(#!@*)( DTs is suck a PoS Jul 26 23:06:19 23493284928490238423 layers of indirection and some @#%$!@$!@$ renumbers from things from 0 to 1 based and vice versa Jul 26 23:09:59 ds2: ah you're just discovering the fun of DT .. congrats! Jul 26 23:10:38 and before I get nightmares .. sleep tyme! I) nite! Jul 26 23:11:01 it is a poorly designed system. I have said it from the beginning and I am saying it again Jul 26 23:11:13 proper board files work. Jul 27 00:11:05 I'm not sure either of those seems particularly appealing to me Jul 27 00:13:06 ds2: btw, is it just me or is still there still no decent official way to use gpios from userspace yet? it still seems to be stuck on the sysfs hack Jul 27 00:16:11 gpio_helper makes it slightly better, but not much, and isn't mainline nor heading there afaik Jul 27 00:55:53 zmatt: yes, that is correct. Jul 27 00:56:01 gpios are too dangerous to use from userland ;) Jul 27 00:56:49 right, so as a result I need to run any process that needs them as root... makes things so much safer Jul 27 00:57:01 hmmm? Jul 27 00:57:01 since I can't easily make a udev rule for specific gpios Jul 27 00:57:09 why do you have to run it as root? Jul 27 00:57:34 you are suppose to have a proper driver for it to expose only a safe level of functionality... that driver can be configured for the appropriate user Jul 27 00:59:02 the proper driver is: having the gpio configured as input or output (done by gpio_helper currently) and granting userspace access to that pin Jul 27 01:00:59 making sure the pin direction isn't changed from input to output would be the "safe" part of "safe level of functionality" Jul 27 01:05:16 the led drivers in the kernel are even more annoying Jul 27 01:05:46 again a sysfs interface, but worse: if you change the trigger property, parameter files in sysfs get created/destroyed Jul 27 01:06:13 and they always get created as root/root rw-r--r-- Jul 27 01:35:05 . Jul 27 01:37:23 , **** ENDING LOGGING AT Wed Jul 27 02:59:58 2016