**** BEGIN LOGGING AT Mon May 16 02:59:59 2016 May 16 08:19:27 hi I see that kernel 4.6 is out. is there any new in there for begalebone black users? May 16 08:23:42 how does beagle-bone work for detecting high surveillance equipment?does it show the network the high surveillance equipment is using the way a computer indicates the precence of a wi-fi network? May 16 08:27:14 because i read that it detects video cameras but how does it detect high surveillance equipment? May 16 08:50:07 ?!? May 16 08:51:32 citylight2: heh, at the top, literally at the top, of the linux 4.6 release announcement ( https://lwn.net/Articles/687511/ ): May 16 08:51:35 spi: omap2-mcspi: Undo broken fix for dma transfer of vmalloced buffer May 16 08:51:51 so that's already one bugfix immediately applicable to the am335x ;) May 16 08:52:52 right May 16 08:53:18 in general many generic stuff is of course also applicable to the beaglebone May 16 08:54:21 I have lately been getting dma-related errors in my kernel log on spi transfers, I've been meaning to investigate but I wonder if this may be it May 16 08:54:28 I remeber that past kernel releases had very importet features for the bbb user May 16 08:55:10 yeah I haven't investigated in detail, I'm still on 4.4 May 16 08:55:21 me too May 16 08:56:00 4.4.9 here May 16 08:56:59 kernel updates have only mattered to me insofar as they either break everything and make my BBB unbootable or everything continues working normally May 16 08:57:24 rebooting after a kernel update is always scary May 16 08:57:46 they added support for gpio chip selects to omap2-mcspi at some relatively recent point May 16 08:57:54 that one kind of mattered to me May 16 08:58:44 were you having trouble with any particular capes beforehand? May 16 08:59:51 we had multiple spi devices, and having to manually deal with the chip selects through gpio ranges from being a real chore to nearly impossible May 16 09:00:16 did you have to actually write your own drivers? May 16 09:00:41 we use spidev May 16 09:01:20 (i.e. directly communicate with spi devices from userspace) May 16 09:01:54 that actually made it possible to deal with it at all, kernel drivers would not have worked May 16 09:02:21 though I'm glad someone took the time to fix the mcspi driver... I briefly looked at it and mostly just got lost :P May 16 09:03:57 I can't imagine that being fun if it's just a means to an end May 16 09:04:34 what? May 16 09:04:38 doing spi from userspace? May 16 09:04:56 yeah I figured that would still require pretty good low level knowledge, right? May 16 09:05:05 no that's actually a piece of cake, especially since I made a C++ wrapper from the low-level ioctl May 16 09:07:04 anyone,help me out please May 16 09:08:07 a beaglebone expert to be exact May 16 09:09:40 promugulus: just ask your question, and be patient... people are generally not staring at this channel non-stop 24/7 so it can take time to get an answer May 16 09:12:20 PDogJr: http://pastebin.com/WwERbDJX this shows it in action for a dsp which you accessed just by reading/writing to it May 16 09:12:50 (these would be methods in a subclass of my spi device class) May 16 09:13:37 how does beaglebone detect high surveillance equipment?since i read it detects video cameras,but does it detect high surveillance by detecting the network its using the way a computer detects a wi-fi network? May 16 09:14:03 promugulus: where did you read that? because I have no idea what that could even possibly mean May 16 09:15:53 check out the website;'low cost tips to detect high surveillance equipment'. beaglebone is included as one of the ways. May 16 09:17:25 please give a link, not a vague description May 16 09:18:53 http://www.networkworld.com/article/2462752/microsoft-subnet/def-con-talk-gives-low-tech-tips-for-detecting-high-tech-surveillance.html May 16 09:19:45 promugulus: did you watch the talk? May 16 09:20:37 looks simple enough zmatt May 16 09:20:50 regarding your paste May 16 09:21:05 actually the paragraph of that article is reasonably specific already... namely by sniffing for wireless networks, presumably the talk contains more details May 16 09:22:45 PDogJr: yep, also supports neat stuff, like I could write in/out( ..., 1us ) to add a delay after that part of the transfer May 16 09:22:59 i watched the talk but it doesn't have demonstrations or anything on how to use beglbone for the purpose May 16 09:23:58 I don't really understand why the Beagle is being specifically mentioned in that article May 16 09:24:06 you should be able to use virtually any hardware for the same purpose May 16 09:24:07 it sounds like you just need any linux system May 16 09:24:08 that May 16 09:27:06 you guys might also want to check out this website http://venturebeat.com/2014/08/11/detecting-if-someone-is-spying-on-you-or-tailing-you/ it talks about beaglebone too May 16 09:27:55 well the first article just mentions it as an inexpensive solution for essentially using a packet sniffer May 16 09:28:01 hi.. i have a question raised in this link. please check http://stackoverflow.com/questions/37249111/image-appears-green-after-capture-opencv?noredirect=1#comment62026515_37249111 May 16 09:28:39 Guest94661: try disabling autosuspend May 16 09:30:47 what are you gonna do after finding out that you're under surveillance, promugulus? May 16 09:31:03 there are cameras everywhere and many aren't even covert, it's just a way of life now May 16 09:31:35 Guest94661: you can try it by writing -1 to power/autosuspend of the relevant device in /sys/bus/usb/devices/ May 16 09:32:00 anyways it's not like the Beaglebone itself has any special inbuilt IR detection capabilities May 16 09:32:45 or if you're lazy just (as root) for i in /sys/bus/usb/devices/*/power/autosuspend; do echo -1 >$i; done May 16 09:33:07 get any 3 physical devices and a packet sniffer and you can do exactly what they mention in that paragraph May 16 09:33:52 Guest94661: if that fixes the problem then you can change your /boot/uEnv.txt to add an option to the kernel cmdline which will disable usb autosuspend by default May 16 09:34:15 usbcore.autosuspend=-1 May 16 09:35:01 anyone see the PocketBone that Jason Kridner is working on? https://oshpark.com/shared_projects/GWqtFu43 May 16 09:36:13 Guest94661: although I kinda consider this also to be bugs in the usb cams, but quite often they give broken image data if you capture immediately after they're taken out of suspend (which is what's happening) May 16 09:37:00 please.. do you mind explaining to me what a packet sniffer is ? May 16 09:37:33 wireless LANs send out packets in order to communicate with other devices on the network May 16 09:37:46 PDogJr: yeah... w.r.t. a 2-layer design (i.e. no decent ground plane) containing high-speed stuff like this someone commented "good luck with FCC testing" May 16 09:37:56 I'd also be seriously concerned about signal integrity May 16 09:38:16 any device can theoretically capture and inspect these packets and if they aren't encrypted, then the user can actually see the data that wasn't meant for them May 16 09:38:51 haven't really had a chance to look at that in depth zmatt May 16 09:39:50 rather the NICs send out packets that can be intercepted by other devices with a packet sniffer May 16 09:40:08 take a look at wireshark promugulus May 16 09:40:42 this is why encrypted communications are especially important when you're on a public wifi network May 16 09:43:14 PDogJr: it looks like most of the bottom side is gnd though, lemme see what it looks like if I overlay the layer May 16 09:44:37 PDogJr & lastly..i a'int too tech savvy..what 3 devices are you talking about?& yeah i'll check out wireshark May 16 09:44:49 I seriously disagree with his color scheme though -.- May 16 09:45:16 I don't think it's actually purple but I think it would be awesome if it were May 16 09:45:32 I'm just referring to triangulation promugulus May 16 09:45:40 it's a general concept and it's how GPS works May 16 09:45:53 using a lighter shade of purple on a background of a darker shade of purple isn't exactly great for examination though May 16 09:46:00 the same concept can be used to pinpoint a stationary network device May 16 09:46:03 ok thanks May 16 09:46:58 I just figured it was fitting with the theme of the site May 16 09:47:11 but yeah you might need to turn your contrast up May 16 09:47:55 I just saw this in an article last night that talked about some company that managed to fit the BBB on a single chip May 16 10:10:15 PDogJr: that's what the pocketbone actually uses May 16 10:10:36 not really enthausiastic about that thing though May 16 10:10:45 I was just thinking that must be what goes in that giant empty space May 16 10:11:05 well from a technical perspective, I think it's pretty awesome May 16 10:11:07 and the pocketbone is definitely doing some serious violation of usb design guidelines May 16 10:11:47 I don't know anything about that - would there be something like cross-talk with the current design? May 16 10:14:23 if it had ethernet instead, this thing would be even better suited as a small home server May 16 10:15:41 I think it's kind of forgoing the original intent of the BBB without the gpio though May 16 10:16:15 it is, you basically might as well get pi zero May 16 10:16:42 that's not open hardware though May 16 10:17:20 my attempt at making the pcb clearer: http://gerbil.xs4all.nl/pocketbone-bottom.png and http://gerbil.xs4all.nl/pocketbone-composite.png May 16 10:17:41 blue is non-GND on bottom layer May 16 10:17:56 in a way, you kind of made it even worse May 16 10:18:42 it's a big ugly since I did a quick hack with gimp, but that's the only way to see the two layers in relationship to each other May 16 10:19:44 it does look cool to see the overlay though May 16 10:19:45 usb1 on the left shows the most blatent example of routing traces over a discontinuous ground plane May 16 10:20:40 actually if you look at the bottom layer there are large areas of ground separated from each other connected only by multiple, fairly narrow strips May 16 10:22:12 I know zilch about pcb design but you've got me kind of interested now May 16 10:22:34 he's open to bug requests May 16 10:22:43 http://www.ti.com/lit/an/sprabt8a/sprabt8a.pdf May 16 10:22:45 I mean pull requests May 16 10:22:55 check figure 2 and figure 4 May 16 10:24:05 I see what you mean now May 16 10:25:08 the large loops on the ground plane can also behave like antennae May 16 10:25:18 then USB1 might as well just be stripped, 1 port would suffice for a small board like this May 16 10:25:54 the other one was also routed over a slot in the ground plane May 16 10:26:26 I missed that May 16 10:26:47 I'm not sure there's much hope for getting this right with a 2-layer pcb... nor am I sure why it matters May 16 10:27:21 I doubt a 4-layer adds that much expense May 16 10:27:45 and saves a lot of headache May 16 10:27:56 (the bbb is 6-layer in case you're wondering) May 16 10:28:16 at that size, it doesn't look like there's really any way around the current design May 16 10:28:52 I was wondering actually May 16 10:29:20 maybe he can shed some more info when he's here May 16 10:29:33 I see him idling but I don't know if he actually ever reads this channel May 16 10:29:46 even talks now and then :) May 16 10:30:28 I might be interested in reading more on this but I gotta start with the basics again May 16 10:30:39 been years since I looked at circuits May 16 10:30:44 I mean many, many years May 16 10:30:50 I'm no real hw designer either, I just picked stuff up by osmosis May 16 10:31:15 well it sounds like it could come in handy May 16 10:31:44 I'm still better than our actual hw gui in things like thinking about power domains :/ May 16 10:31:49 *hw guy May 16 10:31:59 lol that typo May 16 10:33:01 speaking of power domains, that osh335x copied their power distribution structure directly from the bbb, which I'm not exactly enthausiastic about May 16 10:33:12 osd May 16 10:34:12 maybe ignorance is bliss because if it works, I'm content May 16 10:34:34 but it could also be cool to get on board with contributing to an iconic piece of hardware May 16 10:34:51 gonna head off for now but if I'm still motivated, maybe I'll look more into this later May 16 10:35:00 fun fact: basically every time you shut down a bbb the pmic briefly goes into FAULT state May 16 10:36:16 :P May 16 10:36:53 that's partly because the tps65217 has some pretty dubious design aspects May 16 10:38:17 unless one uses the integrated li-ion battery support I'd personally try to stay away from that pmic, there are alternatives May 16 10:39:26 and you can't use the integrated li-ion battery support with the default power supply structure of the bbb.... a bbb is however easy to patch to fix that May 16 10:40:10 having poured the components involved into a slab of epoxy like the osd3358 makes patching a bit more of a problem :P May 16 10:48:01 ok, gotto do some shopping May 16 12:52:36 hi zmatt: if you remember, we talked about "starting kernel ..." takes too long when kernel is loading i found the bottleneck there. May 16 13:01:13 milad_gh: care to share?! :) May 16 13:01:34 I want to do some extensive boot optimisation on one of my arm boards for one project soon(tm) May 16 13:01:50 damnit I -will- learn the keybaord shortcut to that symbol :\ May 16 14:02:11 veremit: try to disable unwanted file systems, in my case i needed just ext4 and fat32 and ntfs May 16 14:02:57 milad_gh: good grief .. don't tell me it tries every possibility in the book .. you might benefit simply from kernel cmdline containing rootfstype= May 16 14:03:09 like I've seen in grub2 configs May 16 14:05:34 it's unrelated to rootfstype, compiling kernel without unwanted fs s made my kernel boot time from 9 sec to 3.4 sec May 16 14:06:00 i'm talking about 4.4.10-bone10 May 16 14:24:44 ooup. well, good to know May 16 14:24:56 should only be building with about 3-4 built-ins anyhow May 16 14:25:20 but RN/beagle kernels tend to be bloaty for max compatibility out-of-the-box May 16 17:22:05 actually you can compile filesystems just as modules and only include the ones you need in your initramfs... although it makes sense to compile-in the fs you use for your rootfs May 16 18:06:56 Now I want a Linux distribution named Bloaty Mcbloatface :D May 16 18:29:24 veremit: but yeah, my kernel+initrd tends to be about half the size of that of rcn and I haven't done serious stripping yet May 16 18:31:25 ewwwwwwwwwwwwwwww initrd May 16 18:32:18 initramfs technically :P I can't help that the file is still called initrd for some reason May 16 18:33:17 why do you need that? May 16 18:33:41 kernel + rootfs should be all that you need unless you want to drink the koolaid and have all the other crap May 16 18:34:07 or you doing a pure kernel + ramdisk/rootfs combo? May 16 18:34:37 mostly because it's the default and I haven't invested effort into it yet... I've thought about going initramfsless but the ability to fsck the rootfs before mounting it rw seems kind of useful May 16 18:35:38 maybe I overestimate its importance May 16 18:36:00 like I said, it's mostly just the default May 16 18:36:58 you can fsck a direct setup. May 16 18:37:03 been doing that for ages May 16 18:37:34 oh true, hadn't even realized that May 16 18:37:43 wait, why exactly do we have initramfs? May 16 18:38:29 cuz the x86 guys wanted something to load modules May 16 18:38:54 as for why do WE have it? I can't think of a good reason unless it is for cape shannigans May 16 18:39:11 wait can fsck really fully do its job on a readonly-mounted rootfs ? May 16 18:39:18 that seems implausible May 16 18:39:25 the original goal was - you have a generic kernel. it would boot to initramfs, /init would dothe magic and load the module so the rootfs can be found May 16 18:39:40 why does it sound implausible? May 16 18:40:34 because I don't see how fsck can have the freedom of repairing stuff when part of the fs is cached by the kernel May 16 18:41:36 the cache can be flushed unconditionally in a RO mount. nothing pending May 16 18:43:53 ok.. I'll take your word for it since, although it still seems rather non-trivial, it also seems kind of unavoidable in a pre-initrd era May 16 18:44:24 and I don't see any cape-related reason for it either May 16 21:57:02 uuids I thought . make sure you load the right rootfs when emmc and usd are present May 16 22:04:44 no reason to use UUIDs May 16 22:05:02 all this is just making things more complex then needed May 16 22:06:44 if you cannot be sure if your media, you got bigger problems that doesn't need to be obscured May 16 22:08:00 ds2: its the difference between final installation and introduction/demo system May 16 22:08:52 veremit: I do plenty of demo systems May 16 22:09:03 never have UUID do anything more then hinder May 16 22:09:04 :) May 16 22:09:27 layering on complexities is not a replacement for understanding things May 16 22:13:31 ds2: which is why we have systemd on the debian images?! May 16 22:19:36 veremit: systemd needs to die! May 16 22:19:44 ds2++ May 16 22:20:11 yes? May 16 22:20:13 :) May 16 22:36:36 haha May 16 22:50:14 veremit: on recent kernels you can just specify /dev/disk/by-path/platform-481d8000.mmc-part1 May 16 22:50:31 zmatt: yikes .. and what's "recent" May 16 22:50:48 and does it have any bearing on which actual mmc device it is :P May 16 22:50:51 no idea, I noticed it on 4.4 but haven't checked older kernels May 16 22:50:56 ie. from the chip's point of view May 16 22:50:58 yes, that's guaranteed to be eMMC May 16 22:51:18 that 481d8000 is the address of the mmc1 controller May 16 22:51:20 cool .. we should see that in later RN kernels then I'd imagine :) May 16 22:53:02 I still think the linux-mmc maintainers are idiots and unjustified in having rejected patches that ensure mmc device numbers always match those given in platform data (when given) May 16 22:53:11 e.g. i2c does make sure of this May 16 22:53:56 I'd much prefer to write /dev/mmcblk1p1 instead of the crap above May 16 22:54:22 -shrug- May 16 22:55:17 which reminds me, I should try my hand at making that fix based on how i2c does it. iirc it was like a dozen-line patch at most May 16 23:00:18 oh well, not urgent, I'll shove it further on my to-do list :P May 16 23:18:37 en foei jason, je zou beter moeten weten dan usb traces over een niet-doorlopend ground plane te routen... http://gerbil.xs4all.nl/pocketbone-composite.png May 16 23:19:10 sowieso snap ik niet waarom iemand serieus ook maar zou *proberen* zoiets 2-layer te maken May 16 23:29:18 whoops, wrong channel May 16 23:31:01 wheeeeeeeeeee carrier for board works, random wires gone May 16 23:34:03 were the wires truly random? May 16 23:34:14 I've never had much luck with those May 16 23:36:01 in general random connections don't seem to be associated with working boards... apparently the one where a QFP was placed 90 degrees rotated was not a success either May 16 23:36:28 ^_^ May 16 23:38:22 haven't done a statistical analysis to prove randomness :D May 16 23:38:46 now I have equiv of P8/P9 May 16 23:39:36 I would have voted for more ground pins than p8/p9 though May 16 23:40:57 trying to reuse other boards designed against P8/P9 May 16 23:41:01 it's kind of unfortunate that those cool connectors that keep a ground plane adjacent to all pins are kind of expensive en obnoxious to work with May 16 23:41:16 *and May 16 23:41:38 indeed May 16 23:44:02 samtec makes pretty neat ones... https://www.samtec.com/connectors/high-speed-board-to-board May 16 23:47:31 cool, they even have hermaphroditic connectors May 16 23:48:44 then you price them out... May 16 23:52:21 to be honest the ability to just stick jumpers in is far too convenient to let go of May 16 23:52:30 although unfortunately the x15 does just that **** ENDING LOGGING AT Tue May 17 02:59:58 2016