**** BEGIN LOGGING AT Tue May 10 02:59:59 2016 May 10 03:05:13 okay, python3.4-compatible now I think... May 10 03:06:42 pushed May 10 03:11:20 ready to pull, and just changed my gas cylinder .. its gonna be a long night .. :J May 10 03:16:01 * veremit cues up Black Eyed Peas .. Good night .. May 10 03:17:13 also added asyncio version of irq demo May 10 03:19:02 zmatt: better - https://gist.github.com/mjeveritt/aa5730798048408abf1405c64b9dd8a9#gistcomment-1773368 May 10 03:19:35 hrm no /dev/uio period .. is that created when you load the overlay .. or .. May 10 03:20:03 https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/uio.rules May 10 03:20:21 notice the uio/ in SYMLINK+= May 10 03:20:24 oh I need to udevadm --reload-rules May 10 03:20:33 +control May 10 03:20:34 blad May 10 03:20:38 blah May 10 03:20:48 without the rule you will just have /dev/uio$n for integer $n May 10 03:21:24 the only way to find anything that way is by checking sysfs for each of those to see if it's what you're looking for May 10 03:21:37 not particularly convenient :P May 10 03:22:01 aye not pretty .. but until I've actually "exported" something .. I presume its not gonna appear, right? May 10 03:22:25 you need an uio device to have an uio device :P May 10 03:22:32 well, fancy that! May 10 03:22:34 they're not exactly hard to make though you know May 10 03:22:51 ere, you wanna tunnel this imx board ;) May 10 03:23:02 or do I have to find a way to bring up this 'spare' bbb ... >,< May 10 03:25:12 if there's a peripheral you want to use exclusively in userspace that's particularly easy, see dtc/adc.dtsi for example May 10 03:25:31 yeah the adc seems to make sense May 10 03:25:36 only requirement is that the peripheral has status="disabled"; in the main dts May 10 03:26:00 you can't steal a device once the kernel got its hands on it ;) May 10 03:26:04 now I found my original kernel sourcs ... lol .. I can find the dts May 10 03:27:52 I actually tried unbinding the kernel driver from a device via sysfs ... while that seemed to work and an overlay to reclaim the peripheral did apply (it didn't before), still no uio device appeared May 10 03:28:05 hmmm May 10 03:28:08 dunno why May 10 03:28:18 sure you can... with the right kernel mods, the kernel can share May 10 03:28:26 donno why anyone wants to do that though :D May 10 03:28:28 oh sharing is easy May 10 03:28:40 just make a second DT node with the same reg=<> May 10 03:28:44 O:) May 10 03:28:53 sharing in a more cooperative fashion May 10 03:28:59 though actually there are very very few peripherals where that's not a very bad idea May 10 03:29:17 depends on what you want to do May 10 03:29:20 gpio is one example since it has nice atomic-set/clear registers May 10 03:29:33 so those can be safely used by multiple parties May 10 03:30:15 as long as ther are no conflicting functional use... May 10 03:30:37 a lot of them offer alternative gpio capability May 10 03:31:03 right, but for most peripherals if you start meddling with 'em while a kernel driver is also active it'll probably get very very confused :) May 10 03:31:14 ok we got i2c1 and/or uart2 and/or ... May 10 03:31:22 ds2: any idea about the weirdass pinctrl problem btw? May 10 03:31:35 zmatt: waiting on board assembly May 10 03:31:36 lets do one/both of them .. no adc per-se May 10 03:31:40 ds2: https://github.com/mvduin/py-uio/blob/master/dts/p9.12-irq.dtsi May 10 03:31:54 I commented out the pinmux stuff in that dtsi to make it work May 10 03:32:04 you rarely NEED to have the kernel driver ACTIVE along with other uses May 10 03:32:09 (when converted to overlay) May 10 03:32:50 it would be stupid to talk to /dev/foobar and directly access hw associated with foobar but if foobar only loaded... May 10 03:33:05 zmatt: the head banging begins friday evening when the board comes back May 10 03:33:16 so far 1 real error May 10 03:33:58 I'm getting http://lxr.free-electrons.com/source/drivers/pinctrl/devicetree.c#L118 this message May 10 03:34:35 but with the node mentioned being the _interrupt controller_ May 10 03:34:51 which, I might add, is really not a pinctrl node in any sense or fashion May 10 03:34:58 ok zmatt.. back on https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl.dtsi .. help me out here .. i2c1 or uart2 take your pic .. or something else .. May 10 03:36:05 veremit: heh, in my experience both can be lots of "fun" XD May 10 03:36:05 zmatt: wonder why there's 7 gpio's defined ther e.. or that's just an example lol May 10 03:36:22 but maybe freescale made decent peripherals, I'd say check the docs May 10 03:37:39 possibly .. shades of grey and all that May 10 03:38:11 ds2: it really puzzles the heck out of me how that function can manage to get its hands on the interrupt controller node ... especially since the code calling it is just parsing pinctrl properties and getting their phandle May 10 03:38:16 zmatt: so taking a random disabled documented peripheral .. how do I make it uio'd .. :p May 10 03:38:33 ds2: it's almost like phandles are getting mixed up May 10 03:38:51 (note: the problem only manifests when using overlays, the same fragment works fine in the main dts) May 10 03:39:45 veremit: if it has a (disabled) DT node, see dts/adc.dtsi May 10 03:40:12 veremit: if not, you probably need to add more fluff, see dts/l3-sn.dtsi maybe May 10 03:40:59 ok lets give this a roll .. May 10 03:41:12 for the imx it seems they model the bus architecture of the chip accurately, probably for power management reasons (stuff that ti sweeps under the ti,hwmods carpet)... so if you need to add a new DT node you will probably need to do it in the right parent node May 10 03:41:30 that's just my 5-second-glance impression thoguh May 10 03:41:48 ok well I'm picking out something described, but disabled .. so theoretically .... May 10 03:41:55 veremit: that's easiest yeah May 10 03:42:16 which node? May 10 03:43:23 some details can make things more "interesting"... like peripherals smaller than a page May 10 03:43:42 oo there's aliases .. hrm May 10 03:44:02 but .. Soc->aips-bus->uart2 May 10 03:44:27 hey, anyone know what prcm stuff needs to be done to init the PRU May 10 03:44:35 yeah lots of stuff seems to be under the aips_bus May 10 03:44:39 i'm writing a driver for it & i'm geting linefetch aborts when trying to access any registers May 10 03:44:47 kremlin: kernel normally handles that for you May 10 03:44:52 specifically a REVID reg in ctrl May 10 03:44:57 zmatt: i am writing the kernel driver :) May 10 03:45:10 kremlin: still remains true May 10 03:45:21 zmatt: uh oh .. more than 1 aips-bus .. HALP! lol May 10 03:45:25 right, i need to know what to do in our prcm.c May 10 03:45:30 the DT node should have suitable ti,hwmods property May 10 03:46:04 kernel has built-in knowledge of power management stuff and will flip the right switches for you when you do the pm_ thingydo calls you need to do May 10 03:46:23 pm_? May 10 03:46:27 what kind of calls are those May 10 03:47:09 ehh, hold on, I'm no kernel programmer.. :P May 10 03:47:17 pm_runtime_ stuff May 10 03:47:28 ahh ok May 10 03:47:30 thanks May 10 03:47:49 all the work on the am335x has inspired me to apply to TI May 10 03:48:16 I can even access PRU using the generic uio driver (uio_pdrv_genirq) which has no device-specific knowledge at all May 10 03:48:24 as long as the DT entry is right May 10 03:48:29 this isn't linux May 10 03:48:35 it is May 10 03:48:45 no, i mean, i am not writing a linux driver May 10 03:48:48 ah May 10 03:49:11 sorry, that sort of stuff is useful to mention early on May 10 03:49:20 my fault, sorry May 10 03:49:20 when you say "kernel driver", people tend to assume May 10 03:50:58 http://freebsd.1045724.n5.nabble.com/External-Non-Linefetch-Abort-S-td5831937.html May 10 03:51:04 this person is trying to exactly what i am May 10 03:51:08 general guideline of enabling stuff is: wake clockdomain, enable module, if applicable release reset-bit, wait until module indicates ready May 10 03:51:08 and ran into the same error May 10 03:51:15 but didn't expand on the prcm bits he had to set May 10 03:51:22 zmatt: make: Nothing to be done for 'i2c1.dtsi'. May 10 03:51:25 gotcha May 10 03:51:35 ah yes, "external non-linefetch abort" ... the most idiotic name ever for a bus error May 10 03:51:41 especially since you also get them on linefetches May 10 03:52:00 i was trying to grok the ARM docs with no luck May 10 03:52:05 that stuff goes over my head, quick May 10 03:52:28 if you mean the architecture reference manual, try to find the old rev B May 10 03:52:39 keep in mind the cortex-a8 is the very first ARMv7-A processor May 10 03:53:03 and in practice simpler than many later ones May 10 03:53:30 it's strictly in-order, nearly any abort is synchronous, all very tidy May 10 03:54:04 on a cortex-a15 even bus errors on reading from Device-type memory are asynchronous :/ May 10 03:54:12 anyhow May 10 03:54:38 i think i found the section of our prcm driver that i need to edit May 10 03:54:44 thanks for the help May 10 03:54:49 sec May 10 03:55:03 https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h#L247 <-- clock domain May 10 03:55:21 https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h#L214 <-- module May 10 03:55:56 https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h#L565 <-- reset bit May 10 03:56:37 awesome, thanks May 10 03:57:04 yes, i see in my jtag debugger that the module isn't enabled May 10 03:57:20 this would have taken me hours to figure out, this channel is a godsend May 10 03:57:36 I'm not sure what is held in reset by the reset bit, iirc you don't need to release it to just access the subsystem memories but I may remember wrong May 10 03:57:50 the cores are held in reset anyway by local controls within the subsystem May 10 03:58:37 also quite important: inside the subsystem you need to enable the L3 initiator ports of the PRU cores, otherwise any attempt to perform an access outside the subsystem will hang May 10 03:59:12 so accesses from host -> PRU subsystem May 10 03:59:46 L3 -> PRUSS is under control of the module register in PRCM May 10 04:00:09 PRU cores -> L3 is under control of a config register inside PRUSS May 10 04:00:52 gotcha May 10 04:01:00 specifically the sysconfig register in the Cfg block May 10 04:03:11 I have no idea why they bothered to include a standbymode field there given that the standby request is entirely under manual software control anyway (bit 4 of that register) May 10 04:08:36 normally it would be hw-managed in such a way that the initiator (e.g. a core or dma engine) cannot be confronted with a non-functioning port May 10 04:09:35 but prcm on the am335x is a complete mess May 10 04:09:58 how come> May 10 04:10:02 stuff like this? May 10 04:10:22 they had an intern do it? someone was drunk? they were just really in a hurry? May 10 04:10:25 I don't know May 10 04:10:40 icepick prcm overrides are also non-functioning May 10 04:11:39 so when linux happily disables the debugss clock since it is "not in use", jtag debugging no longer works since the debugger's request to reenable the clock appears to be not-connected May 10 04:14:03 but, well, it is the way it is May 10 04:15:32 the arrangement with the cortex-m3 as wakeup controller is kinda interesting though May 10 04:15:33 zmatt: why do I get a make error .. surely thats a load of *** May 10 04:15:47 veremit: error or warning? May 10 04:16:04 zmatt: make: Nothing to be done for 'i2c1.dtsi'. or uart2.dtsi .. May 10 04:16:28 missing the obvious again :( May 10 04:16:40 try just "make" :) May 10 04:16:56 (hint: it's "make $outputfile", not "make $inputfile" ) May 10 04:18:31 *facepalm* yup May 10 04:18:41 haha! May 10 04:18:45 you were exactly right May 10 04:18:57 now the linefetch abort is wrong but i'm hanging :) May 10 04:19:05 because of the L3 OCP thing May 10 04:19:19 did you design this SoC? May 10 04:19:42 you're making it seem like you did May 10 04:19:46 if I were, I'd be too embarrassed to ever admit it May 10 04:19:47 but no May 10 04:19:52 :( May 10 04:19:56 lol May 10 04:21:00 veremit: both devices look like fine choices from a DT point of view May 10 04:21:17 of course you'd need to read the docs to see if they're any fun to play with May 10 04:21:32 yeah I've got the overlays loaded supposedly now (no errors) May 10 04:21:38 (I'm currently playing with eQEP... that thing is pretty cool :) May 10 04:21:38 but .. nothing in /dev/uio still .. May 10 04:21:54 do they/should they appear in sys somewhere? May 10 04:22:42 yeah you can find them as platform devices even if linux failed to bind a driver May 10 04:23:22 such as? May 10 04:23:33 either /sys/devices/platform/ and then navigate the hierarchy, or probably quicker to check /sys/bus/platform/devices/ May 10 04:24:31 aha .. ok .. May 10 04:25:44 and if all went well they ought to be under /sys/bus/platform/drivers/uio_pdrv_genirq/ May 10 04:26:04 ok identified under /sys/bus/platform/devices sanely .. May 10 04:26:31 does it has a driver symlink? May 10 04:26:44 lrwxrwxrwx 1 root root 0 May 10 06:24 driver -> ../../../../bus/platform/drivers/uio_pdrv_genirq/ May 10 04:27:29 https://gist.github.com/mjeveritt/4f16bc0a79d49f08bcca8209fa21f8e1 May 10 04:27:51 ok so it is loaded by has no devices May 10 04:28:21 so matching probably failed May 10 04:28:25 /sys/../devices/21a0000.i2c/driver .. May 10 04:28:50 you did take notice of https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf ? May 10 04:29:24 .. mhmm.. May 10 04:29:27 if in doubt, modprobe -r uio_pdrv_genirq; modprobe uio_pdrv_genirq of_id=uio May 10 04:30:10 hmm, the PRU moduile doesn't seem to be coming online after the module bit is flipped in prcm May 10 04:31:19 kremlin: check all three places I pointed to: clockdomain (write 2), module (write 2), reset (clear bit 1) May 10 04:31:25 zmatt: bug - [ 5:30am] root@wand_MJE /home/debian/py-uio/dts # bin/rm-overlay p9.12-irq.dtbo May 10 04:31:25 Can't fileno($fh): at bin/rm-overlay line 19 May 10 04:31:32 but I have a /dev/uio now .. :D May 10 04:32:58 rm uses overlay name without .dtbo... not sure how you get that error though May 10 04:33:32 hmm this is a bit chaotic .. but I have 2 i2c busses .. May 10 04:33:45 wonder if I have another /dev/ttyS* I wouldn't be able to tell I s'pose .. May 10 04:34:24 well anything you turned into uio obviously won't appear anymore as any other sort of kernel device May 10 04:34:31 then again they were disabled to begin with May 10 04:34:38 (right?) May 10 04:34:47 the module is in idle mode, clockdomain is enabled May 10 04:35:13 zmatt: this looks weird - [ 5:34am] root@wand_MJE /home/debian/py-uio/dts # ls /sys/bus/platform/drivers/uio_pdrv_genirq/21e8000.serial/driver/21e8000.serial/driver -l May 10 04:35:13 lrwxrwxrwx 1 root root 0 May 10 05:34 /sys/bus/platform/drivers/uio_pdrv_genirq/21e8000.serial/driver/21e8000.serial/driver -> ../../../../../bus/platform/drivers/uio_pdrv_genirq May 10 04:35:19 kremlin: what do you mean by the former? what value are you reading from the register? (hex) May 10 04:35:33 0x00050002 May 10 04:35:36 from CLKCTRL one May 10 04:35:37 but I'd say that sorta works .. enough for tonight :D May 10 04:35:53 veremit: that looks fine, yuo're just going in circles there May 10 04:36:07 zmatt: right ok May 10 04:37:08 kremlin: clockdomain (CLKSTCTRL) ? reset control? May 10 04:37:45 forgot that that last one is called by ti.. PER_RSTCTRL or something? May 10 04:39:36 RM_PER_RSTCTRL? May 10 04:39:43 that May 10 04:39:50 lemme check May 10 04:40:10 that was the third ingredient I mentioned May 10 04:44:52 zmatt: 0x00000003 May 10 04:45:24 06:31 < zmatt> kremlin: check all three places I pointed to: clockdomain (write 2), module (write 2), reset (clear bit 1) May 10 04:45:44 it appears to be held in reset May 10 04:45:52 because you didn't clear it :P May 10 04:45:55 perhaps clearing that bit will cause it to go May 10 04:45:56 :) May 10 04:46:06 i'm not the sharpest tool in the shed May 10 04:46:15 hehe May 10 04:49:29 it works!! May 10 04:49:32 thanks zmatt May 10 04:54:39 you're welcome :) May 10 05:13:07 zmatt: strikes again! May 10 07:02:35 Is there any known workaround to the current issues HoRNDIS is having with El Capitan and the unsigned kext issue? May 10 07:06:32 the what-who-where-why-how ? May 10 13:44:24 my beaglebone black isn't booting the sdcard, what's wrong? May 10 13:44:38 it doesn't boot the internal OS either May 10 14:00:49 Raiz: does the leds start ? May 10 14:03:27 the power LED only May 10 15:06:08 I'm trying to get a pru program working on kernel 4.1.22-ti-r59, but when I call prussdrv_open, it errors with No such file or directory. I did load the pruss and pru_rproc modules, and I did add uio_pruss_enable to my slots file. May 10 15:07:52 What am I missing? It's a trivial program, it just calls prussdrv_init(), then prussdrv_open(PRU_EVTOUT_0) and finally prussdrv_exec_program(0, "file.bin"). May 10 15:08:26 It worked on an earlier kernel (which needed a different cape and module), but not on this one. May 10 15:11:32 rproc is afaik not compatible with _open and friends, which leverage uio_pruss. May 10 15:12:15 Ragnorok: So what should I do? I just want to load a program into the PRU, it doesn't even need to communicate. May 10 15:13:08 (The program is outputting a clock on one of the pins; it doesn't have any interaction with the main cpu.) May 10 15:13:14 I personally ditched remoteproc like a bad infection and used uio_pruss exclusively, and the simple way to do that is use a kernel with uio_pruss rolled in, which is not generally a ti version. May 10 15:13:42 Once you know uio_pruss is working, there are gobs of examples on the 'net how to use it. It works a treat. May 10 15:15:31 I squandered 8 days trying to figure out if anything even loaded on a PRU using remoteproc. Switched kernels, less than a day I knew it was working and was actively developing the code I needed. Remoteproc may be a killer deployment mechanism but it's about as developer hostile as I can imagine. May 10 15:16:23 Ragnorok: I didn't even know there were different methods. How do I recognize what I'm using? May 10 15:18:02 Sadly I don't have my BBB up at the moment to verify, but it's something like /dev/uio or /sys/devices/uio. If that's empty uio_pruss is not working. If that's populated, uio_pruss is loaded and working, and libprussdrv will work as advertised. May 10 15:19:14 I have stuff in /sys/module/uio/ May 10 15:19:19 Using a kernel with uio_pruss native usually means lsmod doesn't show remoteproc loaded, and it does show uio loaded. There's an overlay in the pages on uio_pruss that load and enable it. May 10 15:19:41 Does lsmod show uio_pruss? May 10 15:20:50 No. It's also not under /lib/modules/. Oh right, the modules that are loaded are under /kernel/drivers/remoteproc/, so I suppose I should ignore those. May 10 15:21:18 So then this kernel doesn't support uio_pruss? May 10 15:22:08 What does lsmod say? Also it's possible remoteproc will conflict. If you have that *and* uio_pruss, I would disable remoteproc to be safe. May 10 15:22:46 But I don't know for sure. I literally scrapped every single thing havign to do with remoteproc, just to be sure. May 10 15:23:50 Also have you looked at dmesg? That should have errors if say it's conflicting. May 10 15:26:21 dmesg doesn't complain, it just said this after I loaded the overlay: dtbo 'uio_pruss_enable-00A0.dtbo' loaded; overlay id #1 May 10 15:26:57 lsmod has pruss and pru_rproc loaded, nothing else with pru in it. It also has uio and uio_pdrv_genirq. May 10 15:27:32 The latter two are normal. I don't recall pru_rproc, but as I said my BBB isn't online atm. Slinging code this week. May 10 15:27:58 I'll plug it in and see what it says. May 10 15:28:16 Both those modules are in /remoteproc in under /lib/modules. I removed them, but it doesn't make a difference. May 10 15:28:26 I'm guessing I need uio_pruss. May 10 15:29:06 Definitely. May 10 15:29:40 And definitely remove anything relating to remoteproc. I can't imagine there's no conflict; they're trying to use the same resource. May 10 15:37:23 Fargin' dynamic IP. May 10 15:39:00 Can I just install a newer kernel? I remember that the last time I tried that, my beaglebone wouldn't boot anymore. May 10 15:39:25 you shuold be able to apt-get .. I can't remember the syntax ever to list the ones in the repo May 10 15:39:31 RN's done a bunch though May 10 15:39:43 (assuming stock debian) May 10 15:39:54 Yes, I have the list, I'm wondering if I really need a TI kernel, or I can use something from Debian. May 10 15:41:25 I did apt-get to change kernels to 4.1.19-bone20. I'm sure newer ones are out there. May 10 15:41:57 I have uio_pruss loaded in lsmod, nothing else pruss/pru, and the dir that needs to be populated is /sys/class/uio May 10 15:42:17 If that's empty it won't work. May 10 15:44:38 ok "aptitude search linux-image*" works for me .. plenty there to choose from .. lol :D May 10 15:45:09 up to 4.6 May 10 15:45:57 they're not "debian" kernels per-se .. they're ARM kernels generic (with customisations, as you'll see from the names) May 10 15:57:20 veremit: Right, and any of them should work? May 10 15:58:11 I -think- so .. just doin a bit of initial testing on my 4.1 kernel .. but that's on .. AHA .. yes, no PRU's on an imx6 processor .. lol d'oh May 10 15:58:26 my bbb is offline currently May 10 15:58:46 I'll just try it; worst case I'll reflash the device with the old image. May 10 15:58:47 but uio is definitely present .. was doing some testing yesterday / earlier May 10 15:59:13 shevek: yea you -should- be able to revert .. might wanna copy your uEnv just to be sure .. or RN's scripts might just comment it I dunno May 10 16:07:35 It's still booting, so that's a good start. :-) May 10 16:07:58 :) May 10 16:09:58 zmatt: wtf version of perl you runnin there? May 10 16:16:22 Ha, now it's working. Thanks! May 10 16:17:44 shevek: 'gratz .. onwards and upwards! :D May 10 16:17:55 \o/ May 10 17:33:27 veremit: ehh, I run 5.22 myself though I didn't think I used any new features in my scripts? May 10 17:58:48 hm May 10 17:59:05 anyone here know the semantics of the pru's loop instruction? May 10 18:09:21 ? May 10 18:09:42 Oh. You mean ASM. I prog'd mine in C. May 10 18:31:35 hi alan_o.... I've been reading a few snippets of your hidraw/etc. code today. May 10 18:45:14 hi jkridner May 10 18:45:21 howdy! May 10 18:45:52 alan_o: been having a good amount of Bluetooth fun lately, but also am messing with USB scanners.... May 10 18:46:28 what kind of scanner? May 10 18:46:35 I was looking for an easy way to convert a /dev/input/eventX stream into just plain text input, but it looks like I'm going down the path of doing it manually. May 10 18:46:39 barcode scanner. May 10 18:47:40 anyway, your name turned up a lot on example code bits, so I thought I'd say hi when I saw you in the room. May 10 18:49:01 ah yes. well hello :) It's been too long. 2013 ELC I think. May 10 18:49:26 have a look at evtest for dumping data from /dev/input/event devices May 10 18:50:04 yeah, I'm pretty familiar with evtest.... just was hoping to see a shortcut. May 10 18:50:25 2013 sounds right. May 10 18:50:57 just write a quick C program May 10 18:51:06 open(); ioctl(); read(); May 10 18:51:44 evtest does way too much parsing May 10 19:03:52 yeah, still a lot of junk messages I have to throw away to build up a string. no biggie. May 10 19:08:09 jkridner: I finally got the first few py-uio examples working without requiring anything esoteric :D https://github.com/mvduin/py-uio May 10 19:08:32 still need to verify it works on jessie (I have no bbb currently that still runs it so I'd need to flash one) but it should work May 10 19:09:57 I reduced python dependency from 3.5 to 3.4 since that's the default python3 in jessie May 10 19:14:06 overlays are still a headache and I'd rather avoid them altogether, but I got no choice until there's a low-barrier way to rebuild the main dts (usable by typical BBB users) May 10 19:21:56 I wonder how much overhead python adds, e.g. if I'd bitbang a gpio via uio May 10 19:22:01 still need to bench that May 10 20:35:04 ~ssen rcn-ee May 10 20:35:13 ~seen rcn-ee May 10 20:36:46 !seen rcn-ee May 10 20:37:00 Nuttin' woiks. May 10 20:38:00 did anyone insult rcn? he used to be here quite a lot May 10 20:38:17 I would expect barring other evidence that he's just busy. May 10 20:43:28 woo, got eQEP working via py-uio May 10 20:45:28 \o/ May 10 21:31:29 zmatt: rm-overlay and list-overlays doesn't work for me .. perl throws a wobbly at the fileno function line 19 .. can't seem to settle a filehandle/lock May 10 21:31:54 zmatt: does it work for you? May 10 21:41:29 zmatt: I've had good luck avoiding overlays for other stuff, but it is tough with PRU. May 10 21:41:37 py-uio is a PRU thing, no? May 10 21:41:47 * jkridner looks at repo May 10 21:43:23 jkridner: most other peripherals, not seen pru yet May 10 21:43:37 zmatt: the "cape universal" pinmux and gpio helpers that get loaded typically in newer images eliminate most of the need for overlays. May 10 21:43:56 eww eww cape universal lol :P May 10 21:44:13 I like the idea of overlays being much more modular ;) May 11 00:59:44 cape-universal is also incompatible with almost any overlay, and hence with py-uio May 11 01:01:01 cape-universal is just a hideous hack born out of an attempt to avoid the other hideous hack, overlays :P May 11 01:01:18 the right solution though is a user-friendly generator for the main dts May 11 02:37:38 zmatt++ **** ENDING LOGGING AT Wed May 11 02:59:58 2016