**** BEGIN LOGGING AT Fri Jun 15 03:00:11 2018 Jun 15 04:15:30 e Jun 15 10:22:41 so my device wakes up from "mem" sleep with an RTC and then spits out this https://pastebin.com/eVD8RXaH Jun 15 10:22:46 any thoughts anyone? Jun 15 10:52:58 PRU on BBB, linus 4.14.48 - should I be using pasm v2? Jun 15 10:59:51 hmm here is a more complete explanation of the error on how I got there https://pastebin.com/y6kB9ibd Jun 15 13:06:51 Guest17943: depends on how you want to load your program. if you use remoteproc-pru then you need to use clpru, if you use uio-pruss with prussdrv you need to use pasm, if you use uio-pruss with py-uio then you can either whichever you prefer Jun 15 13:09:00 TonyTheLion: have you tried a non-rt kernel? Jun 15 13:09:29 "external abort on non-linefetch" simply means "bus error" btw Jun 15 13:09:47 I'm not sure what a bus error is Jun 15 13:09:48 most commonly the result of attempting to access a peripheral that is not enabled in PRCM Jun 15 13:10:27 PRCM? Jun 15 13:10:29 a bus error means a read or write transaction to the interconnect (the "bus") returned an error Jun 15 13:10:37 ah I see Jun 15 13:11:00 either because the target itself returned one, or because the interconnect returned one because the target was not reachable Jun 15 13:11:46 I guess I shall try a non-rt kernel Jun 15 13:12:51 in particular, if a peripheral or subsystem is not enabled in PRCM (the Power/Reset/Clock manager), the interconnect will return an error on any attempt to access it Jun 15 13:13:43 -rt kernels can sometimes cause unusual ordering of activities hence expose bugs that aren't encountered on non-rt kernels, hence my suggestion Jun 15 13:14:13 it could also simply be a bug in the (pretty mediocre) eqep driver Jun 15 13:14:33 I wouldn't be surprised if nobody has tested the eqep driver with suspend/resume Jun 15 13:14:58 oh I see Jun 15 13:15:52 eqep is "enhanced quadrature encoder pulse"? Jun 15 13:16:03 yep that Jun 15 13:16:53 for quadrature inputs, or pulse counting / frequency measurement Jun 15 14:14:54 zmatt: interestingly the default 4.14 build doesn't wake up at all from rtc when putting it to sleep Jun 15 14:15:44 but it does from other wakeup sources? Jun 15 14:16:26 I will need to try that Jun 15 14:17:22 including "from rtc" makes it sound like a problem with the wakeup source, while more likely it's a problem with suspend/resume in general Jun 15 14:17:50 (it is very difficult to imagine rtc not working as wakeup source) Jun 15 14:18:11 let me confirm that it works with GPIO pin Jun 15 14:19:37 now see if it doesn't work with a gpio pin, I'd be willing to believe it's some configuration issue or you used the wrong pin (only pins on gpio0 can wake the system up from deepsleep) Jun 15 14:20:30 but not waking up from rtc? that probably just means it crashed during resume Jun 15 14:21:00 you didn't get any output on the serial console? Jun 15 14:21:40 ye nothing on serial console, no led activity Jun 15 14:22:50 with "default 4.14 build" you mean the latest 4.14-ti kernel or something? Jun 15 14:23:58 ye Jun 15 14:24:38 I built the beaglebone/linux/4.14 branch Jun 15 14:26:14 are you using cape-universal? Jun 15 14:26:52 because needless to say, the more drivers are loaded, the higher the probability of suspend/resume issues. and cape-universal enables everything and the kitchen sink Jun 15 14:28:03 would I be able to see if its enabled in the uEnv.txt? Jun 15 14:28:24 yep, enable_uboot_cape_universal Jun 15 14:28:55 seems enabled Jun 15 14:29:04 can I just disable it in uEnv.txt? Jun 15 14:29:11 yep, by commenting out the line Jun 15 14:29:50 note that disabling cape-universal means basically no peripherals are enabled by default and config-pin won't work Jun 15 14:33:14 so any gpio wakeup would not work then? Jun 15 14:33:53 no idea. pins are muxed to gpio by default and you can still manually export them via sysfs, and of course you can do anything using overlays Jun 15 14:34:03 cape-universal is itself just a bigass overlay Jun 15 14:34:31 ah right, but essentially a wakeup on GPIO should be triggered just by setting that pin high? Jun 15 14:47:20 I made that gpio pin a gpio-key and it doens't wake up when you set the key high or change its value Jun 15 14:53:25 the non-rt kernel doesn't wake up at all with a gpio-key, but the -rt kernel wakes up from deepsleep using a gpio-key Jun 15 15:10:42 zmatt: disabling cape universial on the rt kernel makes the mem sleep rtc wakeup work. Jun 15 15:13:45 I guess I2C is also disabled by disabling cape universal Jun 15 15:28:53 the i2c2 bus on P9.19-20 is enabled by default Jun 15 15:29:09 everything else needs to be enabled specifically Jun 15 15:30:02 you can also try enabling cape-universal but prevent the eqep driver from loading using a blacklist entry in /etc/modprobe.d .. assuming it's compiled as kernel module Jun 15 16:13:06 Hi People Jun 15 16:15:04 tip: if you have a question, just ask it (and have patience). don't expect a reply to "hi" Jun 15 16:16:10 I've been here once or twice, zmatt. Thanx though. Jun 15 16:22:07 ok :) just said it since it happens way too often that people come in, say hi, and leave Jun 15 16:34:04 as long as they don't leave all upset. Jun 15 16:34:26 I suspect many of them expected a reply to initiate a conversation Jun 15 16:36:06 Interesting that you should say that. .... ... Instant Messaging at work ... ... People will send me a 'hi' or 'good morning' or even The Dreaded 'how are you' to initiate a conversation. Jun 15 16:36:32 I cannot count the number of times that I have replied with the equivalent of 'I have work to do, just spit it out'. Jun 15 16:39:46 hehe Jun 15 23:27:01 Where would I find information on creating a parallel port for bbb? Jun 15 23:29:12 Scy: what do you mean? Jun 15 23:29:52 you want to create an actual oldschool parallel printer port? Jun 15 23:34:56 okay **** ENDING LOGGING AT Sat Jun 16 03:00:04 2018