**** BEGIN LOGGING AT Wed Oct 03 03:00:01 2018 Oct 03 03:32:36 GPS! Oct 03 03:33:44 BBGW and a SIM28! Oct 03 03:35:02 It says I am six-ft-under and not moving. Oct 03 03:35:19 Ut oh! Oct 03 03:38:04 rolling avg of readings? Oct 03 03:40:34 Yep! Oct 03 03:41:13 I have this KML wrapper and Google Earth! Oct 03 03:42:17 I do not know how to make KML wrappers but i listened to this one and got it. Oct 03 03:42:42 The KML wrapper needed to be changed, though. And... Oct 03 03:43:13 W/ changing it and changing a KML file to .gpx, the whole shindig worked. Oct 03 03:43:44 Now, I just need to remember the site where it allows me to change files, again. Oct 03 03:44:36 This little SIM28 is pretty powerful. I am 10 ft. away from the window. It works just fine. Oct 03 03:45:47 ... Oct 03 03:46:10 Now, I can put the GPS on my odd scooter or gas/electric bike and know where it is I went. Oct 03 03:47:34 MrCurious: Do you have any ideas on electric transportation? Oct 03 03:49:06 too broad a question Oct 03 03:49:21 Oh. Oct 03 03:49:27 Okay...here goes it. Oct 03 03:49:43 Do you know anything about electric bikes and electric scooters? Oct 03 03:50:07 The only thing I know is that the dang-gone batteries are very expensive. Oct 03 03:50:26 This must shy people away from making more of them. Oct 03 03:50:35 not really, i got a segway, and fell and herniated c6-c7 so not good for riding :) Oct 03 03:50:46 Oh and No! Oct 03 03:50:49 Dang. Oct 03 03:51:00 segways are dangerous. Noted. Oct 03 03:51:27 I kneeled once for too long and got tendonitis. Oct 03 03:51:33 Does that count? Oct 03 03:51:40 well, batteries, i found the cheapest source i could find was to get MBP batt packs off ebay, they were 2x4 lipo with charge controler Oct 03 03:51:50 Oh. Oct 03 03:52:07 Good idea. Ebay has China at the forefront making cheap batteries for all. Oct 03 03:52:42 Get this. I got a battery pack made locally, for some odd reason, that cost me over the amount of the item I was fixing. Oct 03 03:53:42 i also go to hobbyking… look for specials… Oct 03 03:54:19 and keep in mind lithium batteries have issues. they also serve as self destruct mechanisms Oct 03 03:54:20 I went to a dealer online of electric scooter and electric wheelchairs. Oct 03 03:54:22 research them Oct 03 03:54:28 Okay. Oct 03 03:55:14 The battery set up was over $300.00 and the gas powered version w/ engine was only $138.00. Oct 03 03:55:15 ... Oct 03 03:55:36 I am going to incorporate the BBB somehow. I just need to make things have momentum first. Oct 03 03:55:40 i have to fade for the night. if anyone has BB blue, please DM me, would love to hear what you are doing with em Oct 03 03:55:56 MrCurious: Look no further! Oct 03 03:56:03 My BBBlue is doing it all. Oct 03 03:56:15 Oh. Later for now. Oct 03 04:11:31 Now...the GPS says I went to the neigbor's home. Oct 03 04:11:50 Off to the neighbors! Oct 03 06:59:14 zmatt: interesting Oct 03 06:59:46 zmatt: it seems even while the bbb is in ds0, I can talk to the wkup_m3's debug unit. Oct 03 07:00:27 zmatt: I can command it to halt, it won't do it right away because its sleeping, but as soon as I cause a wakeup event (e.g. uart0) it will acknowledge the halt Oct 03 07:00:57 zmatt: and then I can inspect the power domain state before it started to wake up the system Oct 03 07:01:04 that's pretty neat Oct 03 07:34:52 why's the bbb so chatty on i2c? Oct 03 10:15:34 thinkfat: voltage changes corresponding to cpu frequency changes? Oct 03 10:37:52 Hi Beagle people. It looks like my beagle board shutsdown on inactivity. I was thinking of debuging this by reading last session log, I mean last time the system was on and devided to power off. Any idea where I can start? Oct 03 10:39:00 that sounds very improbable Oct 03 10:39:55 poweroff is triggered only by explicit request or by electrical problems Oct 03 10:41:19 Ok, that sounds bad ... Oct 03 10:41:33 if a persistent journal is enabled (/var/log/journal exists) then you can do e.g. journalctl --since=yesterday Oct 03 10:41:59 Do you know if there is any log file one can look for anomaly? Oct 03 10:42:19 otherwise there may be older forms of logfiles in /var/log/ you can inspect (syslog or messages) Oct 03 10:42:52 if the poweroff was done by the pmic I expect nothing in any logfile though Oct 03 10:43:58 I don't know what sort of logging is enabled by default on current images so you'd just have to poke around Oct 03 10:44:28 (I personally disable any form of persistent logging normally to reduce wear-out of eMMC) Oct 03 10:45:09 Alright, I'm running command "journalctl --since=yesterday". Going throgh the logs ... Oct 03 10:48:44 did you confirm /var/log/journal exists? otherwise it will only contain messages since this powerup Oct 03 10:50:50 Ahh, no I did not. There is no journal file in /var/log Oct 03 10:51:49 Can journal file be activated runtime or this must be built in? Oct 03 10:51:56 (directory, not file) Oct 03 10:52:19 you can enable persistent journal by creating that directory and disable it by removing that directory Oct 03 10:52:48 but like I said, there may be other legacy logfiles you can inspect instead since iirc the default images do have rsyslog installed Oct 03 10:53:14 The content of "/var/log" is "btmp lastlog messages messages.0 wtmp" Oct 03 10:53:57 so inspect messages? (or messages.0 if messages only seems to contain stuff since this boot) Oct 03 10:54:13 Ok Oct 03 11:10:17 zmatt: I found something fishi in "/var/log/messages" https://pastebin.com/m4nrUCmS Oct 03 11:10:44 that's just you logging out Oct 03 11:12:12 (and your user manager shutting down, not the system) Oct 03 11:12:48 you should look for the most recent boot messages (which should be easy enough to spot) and whatever comes immediately before it Oct 03 11:22:33 The "message" log is filled with this: https://pastebin.com/7pxANR4G Oct 03 11:54:40 zmatt: The power off is coused because of power cutoff. I'm using one power supply to power beagle board and another board. That other board, at power on consumes alot more power than expected. Oct 03 11:55:15 *caused Oct 03 12:36:06 Enver: cutting power will cause the beaglebone to power off, yes :) Oct 03 12:58:56 zmatt: might be, yes Oct 03 13:12:49 zmatt: and there I though all these years that the bbb gates its jtag when nSRST is asserted Oct 03 13:13:02 zmatt: and it was just a bug in openocd ;) Oct 03 13:14:38 iirc jtag works but is close to useless while warmreset is asserted Oct 03 13:14:46 since none of the interconnects work Oct 03 13:14:51 zmatt: depends on what you're trying to do Oct 03 13:15:15 I guess it might be possible to enable wait-in-reset via icepick Oct 03 13:15:49 zmatt: maybe through the SDTap registers Oct 03 13:16:18 but iirc talking to icepick is all you can do in this state Oct 03 13:16:18 zmatt: but what I'm looking for is a true "reset halt" which halts the cpu right on the reset vector Oct 03 13:16:37 you can't, the reset vector is in secure world Oct 03 13:17:00 zmatt: I seem to have full access to all the debug registers at least Oct 03 13:17:20 zmatt: I guess I can instruct it to halt, if the run control stuff works Oct 03 13:17:28 if you attach to the cortex-a8 it will run until it switches to public world and only then will it halt Oct 03 13:17:47 which is the public rom code, right? at 0x20000 Oct 03 13:17:52 yes Oct 03 13:18:01 that's where I'm halting it right now Oct 03 13:18:43 btw you can also get this by asserting EMU0 low during reset, although I'm not 100% sure whether that only applies to power-on-reset or also warm-reset Oct 03 13:19:51 yes, but that'd require a special jtag probe with the necessary gpios, or at least a jumper wire somewhere Oct 03 13:27:45 zmatt: do you know what this KEEPPOWEREDINTLR (keep powered in tlr) in the SYS_CTL icepick register actually does? Oct 03 13:33:30 zmatt: another funny aspect: in reset, I can also instruct the wkup_m3 to halt. Again it will not acknowledge right away but as soon as linux boots up and initializes its power management, the m3 will halt :-D Oct 03 14:34:20 which bit is that? Oct 03 14:35:52 here are my notes on icepick: https://pastebin.com/raw/DR7JVRwd Oct 03 14:36:34 you mean bit 7 ? Oct 03 14:39:39 I doubt it has any relevance on the am335x considering they don't seem to have paid any attention to icepick-prcm integration, but for example on OMAPs you can debug the system even from the lowest power states (e.g. so-called "OFF mode"). However this requires you to deassert nTRST and toggle TCK for a while to give the debug logic time to power up Oct 03 14:41:43 my assumption would be that if bit 7 is cleared, if you let the tap go into reset state again then the debug logic is permitted to power down again (presumably with some potential loss of state?) while setting bit 7 prevents that Oct 03 15:50:04 zmatt: that power-up of the debug logic is probably why every TI target file in openocd has a "runtest 100" at the end of the reset handling... Oct 03 16:07:48 yep Oct 03 16:15:53 oh Oct 03 16:15:59 my bbb has only 2G eMMC? Oct 03 16:16:18 if you have one that's older than rev C Oct 03 16:16:25 yup, a5a Oct 03 16:16:38 that explains why the iot image doesn't fit Oct 03 16:17:00 iot image used to fit just fine but I think they managed to bloat it up again Oct 03 16:17:14 I made modifications to it myself... Oct 03 16:17:22 I may have overshot the limit Oct 03 16:17:34 which is was blissfully unaware of anyway Oct 03 16:17:42 should have started with a console image instead :) Oct 03 16:17:57 yeah Oct 03 16:18:03 that's what I just trashed Oct 03 16:18:32 but, no problem, I'm just going to uninstall stuff until it fits again ;) Oct 03 16:18:55 don't have any use for apache and node red and bonescript stuff anyway Oct 03 18:32:22 ok, giving the flasher another go Oct 03 18:32:43 zmatt: there's quite some stuff on the iot image that isn't really for the bbb Oct 03 18:33:19 zmatt: ti-opencl, stuff for the dra7xx, stuff for am5xxx, c6000 code generation tools... Oct 03 18:35:47 correction, that's not even for the platform Oct 03 18:37:51 yeah I don't understand why that's even on there Oct 03 18:39:27 seems to fit now Oct 03 18:39:29 yes Oct 03 18:39:30 all good Oct 03 18:41:15 now I can go hunting for milliamps Oct 03 18:46:57 without the sdcard i'm down to just over 500mW in idle Oct 03 18:47:08 with ethernet down, though Oct 03 19:00:49 zmatt: do you know of any peripherals that have switchable power rails that could be switched off in memsleep? Oct 03 19:04:02 on the BBB? the only power rail you can safely cut off (since rev A6, not before!) is LDO2, which supplies the power led Oct 03 19:04:35 the ethernet phy and the hdmi framer do have suspend modes iirc Oct 03 19:06:11 the hdmi framer is spec'd to consume only 18 μW in standby mode Oct 03 19:11:05 ethernet phy specs 1.7 mA (typ) in powerdown mode, i.e. 5.6 mW Oct 03 20:08:13 zmatt: I'm still a bit baffled by the ds0 power consumption Oct 03 20:08:26 45mA from 5V is rather a lot Oct 03 20:17:28 I have no idea what is expected/achievable Oct 03 20:20:11 well, experience with omap3 and other platforms tells me that a few mW should be possible Oct 03 20:20:30 comparing with an omap is not entirely fair Oct 03 20:20:31 but those other platforms were designed to be power conservative from the getgo Oct 03 20:20:34 that Oct 03 20:21:56 still, I think going through the i/o pads and looking for pull conflicts and stuff would make sense Oct 03 20:22:43 sleep mode pad configuration is nowadays entirely done by devicetree, is it? Oct 03 20:25:19 about the PRU: writing 0b100000 + eventNr to r31 is supposed to generate PRU_EVTOUT_ ?? Oct 03 20:28:16 writing 32-47 to r31 triggers event 16-31 of the intc Oct 03 20:29:03 in prussv1 you'd actually write the event number (writing 32-63 would trigger event 32-63) but they managed to fuck that up in pru-icss Oct 03 20:31:02 got it Oct 03 21:28:04 Im having an issue with downloading the beaglebone drivers and am hoping someone can help Oct 03 21:29:50 my connection through usb is apring as CDC ECM instead RNDIS Oct 03 21:30:08 if anyone knows any ways to fix this that would be great thank you Oct 03 21:40:32 Jacobw: you shouldn't need to download any drivers Oct 03 21:40:46 at least if you're using mac, linux, or windows 10 Oct 03 21:41:02 and your beaglebone is running a not-ancient image Oct 03 21:41:54 also works out-of-the-box on Windows 7 Oct 03 21:42:08 didn't know that, good to know Oct 03 21:43:55 For instance, it is really straightforward to share internet to a PocketBeagle Oct 03 21:46:59 again good to know. next time someone is here because they're struggling to share internet to their beagle via usb, I'll just tell them someone said it was really straightforward, and hopefully that fixes the problem for them :D Oct 03 22:22:03 Do I need to --sync_synchronize() after prussdrv_pru_clear_event(... ?? Oct 03 22:25:27 ? Oct 03 22:26:39 __sync_synchronize is typically both overkill and useless Oct 03 22:27:43 okay Oct 03 22:29:59 prussdrv uses volatile accesses, so no compiler barrier is required Oct 03 22:34:37 and a memory barrier wouldn't accomplish anything. if the registers are mapped as strongly-ordered (they normally are) then each write will synchronously wait for completion anyway, if they're not mapped as strongly-ordered (e.g. I patch my kernels to use device mapping instead of strongly-ordered) then writes will always be "fire and forget" and no memory barrier suffices to wait for their completion Oct 03 22:35:30 it is rarely required to wait for writes to complete anyway, since the next read or write to the same target will still be ordered behind it Oct 03 22:37:33 what are the benefits of device mapping? Oct 03 22:37:55 the cpu doesn't synchronously wait for every write to complete Oct 03 22:38:29 also it makes uio (or /dev/mem) mappings in userspace behave the same as device mappings in the kernel (which always use device type rather than strongly-ordered type) Oct 03 22:41:35 basically, a write to a device mapping is 1 cycle (as long as the write queue isn't full) while a write to a strongly-ordered mapping is just as slow as a read (around 150 cycles or so I think? in that ballpark range anyway) Oct 03 22:43:16 and I've noticed that strongly-ordered accesses are actually often even slower than device reads... they also seem to synchronize against normal accesses, like a memory barrier Oct 03 22:43:24 *normal memory accesses Oct 03 22:55:22 good info Oct 03 23:02:31 didn't quite get the part "uio (or /dev/mem) mappings in userspace behave the same as device mappings in the kernel" Oct 03 23:33:15 does anyone know if GadgetFs is supported out of box in default image " Debian 9.5 2018-08-30 4GB SD IoT"? When I invoke "mount -t gadgetfs gadgetfs /dev/gadget", I get error "mount: unknown filesystem type 'gadgetfs' " Oct 03 23:34:43 I made sure gadgetfs is listed via lsmod. dmesg reports "[175819.128982] gadgetfs: USB Gadget filesystem, version 24 Aug 2004" Oct 04 00:05:47 zmatt: welcome back Oct 04 00:19:23 can I use uio for both pwmss and pruss? because I have seg fault when prussdrv_open, if both overlays are loaded (pwmss2 and AM335X-PRU-UIO-00A0.dtbo) Oct 04 02:14:10 CoffeeBreakfast: that's because libprussdrv is very badly written and blindly assumes /dev/uio0-uio7 belong to uio_pruss Oct 04 02:28:47 Bummer Oct 04 02:33:18 my c-uio based in your py-uio still works with both DT overlays :) Oct 04 02:34:09 well, it is a crude version for now, but works Oct 04 02:47:11 +1 for c-uio! **** ENDING LOGGING AT Thu Oct 04 03:00:02 2018