**** BEGIN LOGGING AT Wed Nov 14 03:00:00 2018 Nov 14 03:08:50 That LoadCape is just ready to be taken for a spin. Any recommendations on where to start? Nov 14 03:08:52 ... Nov 14 03:09:57 I mean, I can jam on a battery and see what happens but I want to play it safe. Nov 14 03:10:35 off to the mfg! Nov 14 04:26:14 Hi, I'm working with the beaglebone Blue, with the goal of getting 1-wire working. Is there a free pin that would work for this? The P9.12 pin used on the Black goes to the BT I2S clock. Nov 14 10:57:55 all of them! make america great again! Nov 14 11:04:35 hello there, i was wondering if I could use the beagle bone black wireless to implement what was done in this papar >> http://www.ti.com/lit/an/swaa162a/swaa162a.pdf Nov 14 11:05:51 depends purely on whether that pin on the wilink8 module is connected to the am335x on the bbbw Nov 14 11:06:04 my guess would be it isn't, but I'll check Nov 14 11:07:43 gpio11 is not connected, not even to a testpoint (like some of the other gpios) Nov 14 11:09:11 I'm not surprised by this since the datasheet (revised in 2017, two years after this paper) says that gpio11 is "reserved" and should not be connected Nov 14 11:11:30 shame :( Nov 14 11:12:54 yep, kinda sucks that TI didn't properly document that pin Nov 14 11:13:13 could i just wire it up? Nov 14 11:14:39 on the beaglebone black schematic its not connected to anything Nov 14 11:15:13 sure, just drill a really tiny hole in the pcb to reach the ball, taking care to not damage any traces in that area, and manually create a via to it Nov 14 11:15:25 :) Nov 14 11:17:22 zmatt: hey do not confuse people that come here in search of inspiration and enlightenment with mere facts. Nov 14 11:17:27 first have to figure out of the OSD3358 has the GPIO2_2 pin accessible, i only see 2_0 and 2_1 Nov 14 11:17:33 (I know of one case where some crazy people actually did this to get a prototype board working under time pressure. I have no idea how they even conceived this as being a thing you might actually be able to do, let alone pulled it off successfully) Nov 14 11:18:01 lastaid: I was not being serious :P and the am335x side is not the problem, timer4-7 are all available on the expansion header Nov 14 11:18:22 i am quite aware :D, but that is quite good information Nov 14 11:18:25 (a guy here actually did something similar: pushing a wire under the bga from the side to reach an unconnected ball in the second row, and succeeding) Nov 14 11:18:30 although you'd also need a level shifter to go from 3.3v on the beaglebone side to 1.8v on the wl1835 side Nov 14 11:19:03 oh it's not actually a BGA Nov 14 11:19:10 kinda Nov 14 11:19:22 it looks more QFN-like Nov 14 11:19:33 http://beagleboard.org/black-wireless Nov 14 11:19:34 yes Nov 14 11:19:41 and i think its pin2 or s.th. Nov 14 11:20:43 yeah, which only has one immediate neighbour (there's some space between it and pin 1 (ground pin in the corner)) Nov 14 11:22:08 why would ti not connect those, they even have an application note for this purpose. :D Nov 14 11:22:48 maybe use the Submit Documentation Feedback link in the datasheet Nov 14 11:29:42 just send the feedback ^^ Nov 14 11:30:10 it would have been to perfect ... just buy 3 boards and see if we get a meaningful sync Nov 14 11:30:16 *too perfect Nov 14 11:32:06 jkridner[m]/rcn-ee[m]: maybe it's worth taking a note: on future beaglebone variants with a wilink8 module (or any revision of the existing ones) it would be useful to connect the timer4 output (or probably any of timer4-7) to the "GPIO11" pin of the wilink8 (via level shifter) Nov 14 11:32:52 and maybe connect remaining "reserved" pins to testpoints if there's space, in case more uses show up in the future Nov 14 11:45:08 (timer4-6 are also available on the vddhv5 i/o group, for the level-shifter-free integration option) Nov 14 13:11:19 Hello Nov 14 13:11:31 Any one in the other end ? Nov 14 13:12:56 no. obviously. Nov 14 14:01:15 m Nov 14 15:42:12 m Nov 14 15:50:29 Client: HexChat 2.12.4 • OS: Unknown Distro • CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4.00GHz) • Memory: Physical: 15.2 GiB Total (11.9 GiB Free) Swap: 15.6 GiB Total (15.6 GiB Free) • Storage: 1.1 TB / 1.5 TB (405.3 GB Free) • VGA: NVIDIA Corporation GK208B [GeForce GT 730] @ Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers • Uptime: 24m 17s Nov 14 15:51:05 oops. sorry if you got a sys info dump. Nov 14 21:33:48 docker on pi's and bones Nov 14 21:33:50 is there any reason? Nov 14 21:53:11 buzzword compliance Nov 14 21:55:20 we do actually use containerized services ourselves, mostly for the ease of updating and for increased security. they're not "full" containers though, just a squashfs with the executable and its dependencies (shared libs and such) and the essential etc files Nov 14 21:56:25 (just a mount namespace, no pid or user namespace) Nov 14 22:10:06 yeah i mean hmm the mount namespace huh Nov 14 22:10:44 i remember there was this .image from canonical or something that may or may not have been the same thing Nov 14 22:11:00 i guess that's better than doing some sort of full sysadmin type management? Nov 14 22:11:03 like puppet Nov 14 22:11:25 so many different ways to manage these systems, i'm not sure whats the point Nov 14 22:13:39 I have no experience with puppet, or how it interacts with its server, but in this case it's pretty important that clients are able to simply download an update, verify its signature (the server itself is _not_ trusted), and install in a way that makes every effort to make the update atomic and infallible even in the face of unexpected poweroff Nov 14 22:14:30 having everything related to an updateable part of our system packed into a squashfs container helps Nov 14 22:15:12 also, because those containers have fairly limited privileges, they can be signed by a less-restricted code signing key than the one required for root-privileged updates Nov 14 22:17:10 nice Nov 14 22:17:11 i like the approach Nov 14 22:17:34 i mean, the update philosophy makes sense Nov 14 22:17:40 and of course i get the security part Nov 14 22:17:47 unexpected poweroff is the gigantic "uh oh" Nov 14 22:18:01 I think appliances are also very different from your own systems within an organization Nov 14 22:18:07 and afaik puppet is intended for the latter Nov 14 22:27:50 no its true Nov 14 22:28:17 although i think the benefit of your system can be seen in both Nov 14 22:28:24 its just cheaper updatign Nov 14 22:28:26 updating* Nov 15 02:45:33 zmatt: For the beagleboard x15. If I have a list of gpio pins that I want to mux to the PRUs, what is the best way to modify the device tree? Nov 15 02:49:21 the same way you'd configure pinmux in DT in general: create a pinmux node (child node of the pinmux controller) and associate it with the device via pinctrl properties Nov 15 02:50:15 (I probably already mentioned that, for the am572x used on the bbx15, TI recommends doing pinmux in u-boot rather than DT to prevent glitches?) Nov 15 02:51:03 anyway, this example shows pinmux (a single pin) being associated with the ecap0 device: https://pastebin.com/MagZyG75 Nov 15 02:51:49 the pinctrl-single,pins can (as the name suggest) contain multiple pinmux lines Nov 15 02:53:38 (it's also possible to reference multiple pinmux nodes in the pinctrl-0 property of the device. this is rarely used, but it's needed if your device needs pinmux set up in multiple different pinmux controllers) Nov 15 02:56:42 for a less trivial example see https://github.com/mvduin/py-uio/blob/master/dts/bbx15-spi-test.dtsi Nov 15 02:57:21 ho hum, that actually doesn't look right to me Nov 15 02:58:33 What in particular Nov 15 02:58:58 I'm pretty sure MODE_SELECT should not be used unless iodelay is also being configured. (I think I copy/pasted this from a little test that did in fact configure iodelay) Nov 15 02:59:10 lemme double-check **** ENDING LOGGING AT Thu Nov 15 03:00:00 2018