**** BEGIN LOGGING AT Wed Nov 30 03:00:01 2016 Nov 30 12:18:51 Usually DIMM contain EEPROM to write SPD data. What about the DDRL available on BBB? Where SPD data resides? Nov 30 13:00:56 Hhh Nov 30 13:51:44 my beaglebone has an usb wifi key (wlan0), it has the same IP class of eth0, despite the fact it registers to wifi access point , it is not pingable or usable unless i shut down eth0 (even if eth0 has nothing connected)Any idea why ? Nov 30 13:52:03 Same ip class but different address of course Nov 30 16:23:54 la Nov 30 16:24:20 cd /opt Nov 30 16:24:47 oooops....wrong keyboard... Nov 30 17:47:42 hello, is the config-pin utility available in a debian repo, or is it the one available here - https://github.com/cdsteinkuehler/beaglebone-universal-io? Nov 30 19:34:05 hey rajesh Nov 30 19:34:24 i got the config-pin from updating with rcn's repo Nov 30 19:34:44 hey have any of you guys taken a look at the BBB design files? Nov 30 19:35:12 its kinda off topic but i noticed theres this gerber file called assy thats not to scale at all (huge) and i was wondering if anyone knew what its point was Nov 30 22:39:23 hi Dec 01 00:57:48 hi. where can i buy beagleboard x15? Dec 01 00:58:25 ??? Dec 01 00:58:51 I just looked at both distributors listed on the site and both say they're out of stock Dec 01 00:59:23 looks like RS out of stock to Dec-12 Dec 01 00:59:31 err, Dec-06 Dec 01 00:59:33 http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8874764/ Dec 01 00:59:37 hi all. where can i bye beagleboard x15? Dec 01 01:00:05 we're looking at the same sources you are Dec 01 01:00:41 rs and special comp, both are out of stock Dec 01 01:00:42 yeah, keep eye on this page: Dec 01 01:00:55 http://beagleboard.org/x15 Dec 01 01:01:14 This is the other distributor: https://specialcomp.com/beagleboard/x15.htm Dec 01 01:01:25 Unfortunately, you'll have to wait for now Dec 01 01:01:31 where did it start to order? Dec 01 01:02:08 There was a limited quantity of pre-FCC certified X15 boards Dec 01 01:02:15 those have been sold Dec 01 01:02:33 the full production FCC certified units will hopefully start shipping soon Dec 01 01:02:44 once that happens, you'll see all the normal distributors have it Dec 01 01:03:25 here's the mailing list for BeagleBoard x15 Dec 01 01:03:26 https://groups.google.com/forum/#!forum/beagleboard-x15 Dec 01 01:03:27 i have submitted my request to buy in beagleboard.org . but i have received no email for start of ordering! Dec 01 01:03:50 it wasn't the official launch Dec 01 01:04:23 it was a small batch of an pre-certification revision, made by the old manufacter (CircuitCo) Dec 01 01:05:05 background info here: https://groups.google.com/forum/#!topic/beagleboard-x15/c1zpR4Dh4cg Dec 01 01:05:38 when the full certified versions will be available for ordering? Dec 01 01:05:59 there's no precise date that I know of, but I would say by the end of the year Dec 01 01:06:14 You may want to email https://groups.google.com/forum/#!forum/beagleboard-x15 Dec 01 01:11:58 pdp7: I saw your tweet about walleij's slides on gpio... I'm hoping you shared that to point and laugh and not as endorsement? Dec 01 01:12:39 well, he seems have reasons. the new utilites seem interesting Dec 01 01:14:21 I have absolutely zero love for the new chardev, the sysfs interface enhanced with patches (I recently also contributed some) is far superior Dec 01 01:14:35 interesting, which patches? Dec 01 01:17:27 the most important I did was add an attribute to exported pins to get their label, and I cleaned up gpio-of-helper a bit. with the label I was able to easily make an udev rule that makes symlinks in /dev/gpio based on the name assigned in device tree -> http://pastebin.com/raw/05ve6xw9 Dec 01 01:17:37 this way applications don't have to know the exact pinout Dec 01 01:17:48 also permissions are set Dec 01 01:18:50 would this be in the kernels that rcn produces? Dec 01 01:19:48 I think he merged them, but if not then they're here -> https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.8/patches/gpio Dec 01 01:20:22 thanks Dec 01 01:21:10 http://pastebin.com/raw/RaaMMxVX device tree fragment related to this example Dec 01 01:21:59 since DT controls the direction (unless it adds an explicit property to allow userspace control) there's no risk of userspace accidently or maliciously causing drive-conflicts which could damage hardware Dec 01 01:24:01 the udev rule is a bit uglier than usual udev rules because they're not devices but it's not too awful -> http://pastebin.com/raw/eGMTHrW7 Dec 01 01:26:05 interesting approach, i hadn't seen someone doing this before Dec 01 01:26:28 what is "S-Pro"? Dec 01 01:26:33 an amplifier Dec 01 01:26:39 ah ok Dec 01 01:27:28 heh, yay followers on twitter... I virtually never use it, but hey ;) Dec 01 01:28:22 I think this solution sets a pretty high bar for any replacement mechanism Dec 01 01:29:24 do you know if Linus W is familiar with this solution? Dec 01 01:30:05 dunno, gpio-of-helper has been around for quite a while, I think it was already in the 3.8-bone kernels Dec 01 01:30:33 adding symlinks using udev seemed like an obvious thing to do to me Dec 01 01:31:09 I think patches to do similar things have been submitted now and then Dec 01 01:31:34 like, gpio-hog came out of this afaik, but it really isn't the same obviously Dec 01 01:31:57 ah ok Dec 01 01:32:10 there was also a patch that turned custom-definable groups of gpios into char devices Dec 01 01:32:13 now *that* could have been nice Dec 01 01:32:41 I don't remember where I saw that Dec 01 01:33:04 interesting, wonder what the person was using that for Dec 01 01:33:14 Parallel-port printers? :D Dec 01 01:33:18 :) Dec 01 01:35:55 but "engineers and makers" who wants real gpio performance aren't going to do syscalls anyway, not when you can set and/or clear any subset of the 32 pins of one gpio controller with a single store-instruction after mmaping the gpio controller Dec 01 01:36:33 but most applications aren't *that* performance-critical, and then what matters is safety and convenience Dec 01 01:36:47 thanks for the insight Dec 01 01:38:21 np :) Dec 01 01:38:36 note btw I'm pretty biased towards "do it from userspace!" Dec 01 01:39:02 which is quite the opposite of what kernel devs seem to be biased to, although I'm not sure why Dec 01 01:41:31 like, this also pisses me off -> https://github.com/beagleboard/linux/commit/956b200a846e324322f6211034c734c65a38e550 Dec 01 01:41:42 I just read this yesterday and thought it was pretty interesting: Dec 01 01:41:44 https://lwn.net/Articles/703785/ Dec 01 01:41:47 Linux drivers in user space — a survey Dec 01 01:42:06 "he recent posting of a patch set aimed at allowing LED drivers to be written as user-space programs seems like a suitable opportunity to have a look at the range of options currently available." Dec 01 01:42:08 (of course the beaglebone kernel reverted that commit, and the rpi one added "spidev" to the list of OF ids) Dec 01 01:42:38 I use uio a lot Dec 01 01:43:02 or well, I still use /dev/mem too often, but I plan to move most of it to uio Dec 01 01:43:23 'spi: spidev: Warn loudly if instantiated from DT as "spidev"' Dec 01 01:43:40 ah, i remember seeing that when going through Robert's scripts Dec 01 01:43:59 just as with gpios, some kernel devs seem to believe no userspace use of it is acceptable, or something Dec 01 01:44:00 trying to reduce the patch set to just wanted i needed (as a learning exercise) Dec 01 01:44:58 That LWN article lists race conditions as one reason to avoid user space drivers, but it seems like solution can be found Dec 01 01:45:35 btw this is another thing I made -> https://github.com/mvduin/py-uio to try to make uio easier to use for Normal People™, which is also why I chose python which I knew a little but hadn't used very seriously before Dec 01 01:45:50 unfortunately the more I learned about python, the less I liked it Dec 01 01:46:28 race conditions? lemme see what the article claims then Dec 01 01:47:58 oh, deadlocks, that's not the same. that's limited to pretty narrow classes of devices though Dec 01 01:48:48 ah, good to know Dec 01 01:49:02 certainly it only applies to cases where you're providing a service from userspace to the kernel, that alone is rare Dec 01 01:49:26 FUSE indeed is an example of it Dec 01 01:50:07 gotcha Dec 01 01:50:09 (that's what this whole article is about though) Dec 01 01:51:29 sorry, that's not true, the second half of it is I mean Dec 01 01:53:31 the downstream interfaces, right? Dec 01 01:53:40 yeah Dec 01 01:53:48 I'm mostly not interested in those though Dec 01 01:54:09 although they have their uses Dec 01 01:54:59 but generally I just want to use the hardware that's available to me from userspace apps, and uio_pdrv_genirq works excellent for most of that :) Dec 01 01:56:24 note that the stuff the article says about UIO is specific to PCs Dec 01 01:56:45 no custom in-kernel component is needed for using uio on an ARM SoC Dec 01 01:59:38 good to know. Dec 01 01:59:50 interesting, I hadn't heard of uio_pdrv_genirq before Dec 01 01:59:54 looking at https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt/ Dec 01 01:59:58 or rather, the essential difference is the shared irq lines of PCI devices versus the dedicated irq lines of on-chip peripherals Dec 01 02:00:13 see also gpio-irq.py in https://github.com/mvduin/py-uio Dec 01 02:00:41 the device tree fragment for it is pretty trivial -> https://github.com/mvduin/py-uio/blob/master/dts/gpio.dtsi Dec 01 02:01:13 if you want to use an existing peripheral via uio, the device tree fragment is generally even more trivial -> https://github.com/mvduin/py-uio/blob/master/dts/adc.dtsi Dec 01 02:01:42 uio_pdrv_genirq is enabled in rcn's kernels btw (after I asked him to, quite a while ago already) Dec 01 02:02:21 the uio-alias property is again just something meant for use by udev to create symlinks Dec 01 02:02:24 very interesting, i'll have to try it out Dec 01 02:05:34 I should probably at least create an updated example for pwmss. those subsystems have traditionally been a bit awkward but things have improved in recent kernels Dec 01 02:06:58 especially since those peripherals are very nice for direct access... they're very versatile and sticking them behind a lowest-common-denominator interface provided by a kernel driver really loses quite a bit Dec 01 02:07:43 and there's little or not harm in letting userspace access them directly... worst case you just end up with a confused peripheral Dec 01 02:13:01 http://pastebin.com/raw/gvAGJg7b what you typically find on the beaglebones I work on ;) Dec 01 02:15:43 the tree is cleaner than what I'm used to wading through in /sys :) Dec 01 02:16:28 well of course, since this tree was human-made Dec 01 02:17:57 there's an alternative way to find the uio device you need, by examining their sysfs properties to figure out which is which, but funny enough I prefer a sensibly-named symlink ;) Dec 01 02:55:36 pdp7: I don't really have a high opinion of that adafruit python library btw... last time I looked it mainly just seemed to read/write sysfs files, inexplicitly doing this in a C extension instead of pure-python, and still managed to be unnecessarily inefficient Dec 01 02:57:44 is that the python2 one .. heh **** ENDING LOGGING AT Thu Dec 01 03:00:00 2016