**** BEGIN LOGGING AT Thu Dec 15 03:00:01 2016 Dec 15 08:44:40 Hi there, I have an issue with installing opencv on my BBB , I am working on Debian GNU/Linux7, while installing the files at a certain point after (61%) it gives an error: ‘SIZE_MAX’ was not declared in this scope, I tried different techniques to solve this error but I havent found a solution yet. Thanks in advance for your help Dec 15 10:42:05 Hi everyone, i'm a noobie getting started with a beaglebone wireless green, i need help :(( Dec 15 10:43:46 i'm connected via ssh, IDE cloud9 works, RedNode works too, problem is the USR lights blink from left to right (all four of them) and i'm not sure how to stop them, is there a program running to keep them blinking? Dec 15 11:41:45 edubai__: that sounds like one of the cloud9 demos Dec 15 11:41:55 I think Dec 15 11:41:56 not sure Dec 15 11:42:47 if i run blink.js from cloud9 demo then the lights will blink in a weird way, as if two programs are running Dec 15 11:43:15 @zmatt Dec 15 11:43:30 i can only bring can1 down and up once, afterwards i get `RTNETLINK answers: Device or resource busy` when trying to bring it back up (the exact sequence is finish booting, down, up, down, up -> error). from that point on, each up fails with the same error Dec 15 11:43:37 is there any way to investigate this? Dec 15 11:45:33 edubai__: try: sudo lsof /sys/class/leds/usr*/brightness Dec 15 11:46:29 edubai__: unfortunately I've seen lots of code that doesn't keep files open (which would make tracing this much easier) but inefficiently do { open, write, close } every time they want to update something Dec 15 11:46:41 so lsof might not give results Dec 15 11:47:08 lsof: status error on /sys/class/leds/usr*/brightness: No such file or directory Dec 15 11:47:14 huh Dec 15 11:47:23 oh right Dec 15 11:47:32 try just * instead of usr* Dec 15 11:47:58 nothing happend Dec 15 11:48:11 no results, that's what I was afraid of Dec 15 11:48:22 what does that mean? Dec 15 11:48:35 it didn't find any program that had any of those open at that time Dec 15 11:48:43 ohh, I have an idea Dec 15 11:49:12 all 4 blink and i can't stop them Dec 15 11:49:34 yeah so some process is doing that, I'm trying to think of a way to find out which Dec 15 11:49:50 it can also be helpful to check what's running on the system to look for suspicious candidates Dec 15 11:50:00 one set of options to ps I personally like is: ps f -fe Dec 15 11:50:20 i will show you a short video 1 sex Dec 15 11:50:23 1 sec Dec 15 11:52:46 https://usercontent.irccloud-cdn.com/file/gEm4wr0I/IMG_1257.m4v Dec 15 11:53:16 funky Dec 15 11:53:29 definitely not something the kernel will do though, so it'll be some userspace process doing this Dec 15 11:53:57 will a restart fix it? Dec 15 11:54:35 i will update the firmware first.. Dec 15 11:54:39 given that I have no idea what process might be doing it or why, or how that process came to be running in the first place, I have no way to answer that Dec 15 11:55:08 will a firmware update start everything from the start? Dec 15 11:55:15 bute force method: kill all processes one by one until the blinking stops Dec 15 11:55:29 thinkfat: requires a bit of care in process selection though :P Dec 15 11:55:35 indeed :) Dec 15 11:56:21 edubai__: reflashing the system fixes pretty much any problem :P but if you don't know how this came to be, and you don't find out now then it might happen again the same way Dec 15 11:56:24 * thinkfat grabs a shotgun Dec 15 11:56:28 also when i try any of the demo example from beaglebone.local website it would say initialising bonescript and then nothing happens Dec 15 11:56:38 edubai__: if you wait briefly I have a way to find out which process is doing it Dec 15 11:56:43 ok Dec 15 11:57:14 zmatt: you know there was once a doom-styled process manager. Dec 15 11:57:24 yes I know Dec 15 11:58:09 I think the endboss was sendmail. biggest task on any system at that time :) Dec 15 11:58:45 or was that emacs? Dec 15 12:00:00 i will do the firmware update and i will come back, this may take some time.. Dec 15 12:09:11 i.e. we'll never find out what it was and I just made this utility for nothing, ok Dec 15 12:10:23 well, here's the thing anyway... https://gerbil.xs4all.nl/grab-lease.tar.gz Dec 15 12:10:55 it grabs a lease on a file and reports when some other process is trying to open the file Dec 15 12:11:17 that process is temporarily blocked, which gives you time to use lsof to locate it Dec 15 12:17:41 afk Dec 15 12:33:01 Hello, can I use any Bluetooth dongle for connecting to my beaglebone black ? Dec 15 12:33:57 Jack_: it needs to be one supported by Linux, but most fit that. Dec 15 12:35:06 Jack_: personally, I recommend using the Pluggable one. Dec 15 12:35:11 Have you seen https://developer.ibm.com/recipes/tutorials/connecting-a-beaglebone-with-sensortag-to-the-iot-foundation/ ? Dec 15 12:35:20 ok thank you. Dec 15 12:36:15 http://plugable.com/products/usb-bt4le/ Dec 15 12:37:17 thnx for info Dec 15 15:44:19 hi av500 Dec 15 15:44:39 lo jkridner Dec 15 15:45:19 Hilo, HI Dec 15 15:46:20 @zmatt, the problem was related to wireless, it was looking for SSID Dec 15 15:47:00 @zmatt, once i reconfigured the wireless it stopped blinking the way i was showing in the video Dec 15 15:48:51 @zmatt, so i tried a blink.js and when i end the program the lights will sometimes get stuck on or off depending on when i pressed the stop button, is that normal? Dec 15 15:50:45 this means some cleaning should be done with ports before ending a program??? Dec 15 15:53:34 edubai__: yes, it doesn't save/restore the old led configuration Dec 15 15:54:53 @zmatt, so this means so ports will end with being on until a restart .. hmmm Dec 15 15:54:57 some** Dec 15 15:55:31 edubai__: in general stuff remains the way it is unless changed to something else Dec 15 15:56:07 also the led names is different for beaglebone green wireless Dec 15 15:56:18 root@beaglebone:/var/lib/cloud9# ls -1 /sys/class/leds Dec 15 15:56:19 beaglebone:green:usr0 Dec 15 15:56:19 beaglebone:green:usr1 Dec 15 15:56:19 beaglebone:green:usr2 Dec 15 15:56:19 beaglebone:green:usr3 Dec 15 15:56:33 that's the same on all beaglebones Dec 15 15:57:13 the green refers to the color of the leds, which was green on the beaglebone white, and then couldn't be changed because people had hardcoded those paths in their programs Dec 15 15:57:44 oh, i thought it refers to the name of the board.. Dec 15 15:57:56 interesting. Dec 15 15:57:58 fortunately I don't have to care about those people so I changed them to just usr0..usr3 in my own device tree Dec 15 15:58:33 @zmatt, do you have any experience with the PRUs? Dec 15 15:59:06 to my shame I haven't had the opportunity to use them much yet, but I am familiar with their capabilities Dec 15 15:59:50 @zmatt, in general are they more capable than an arduino uno chip? Dec 15 16:00:04 lol yes, a lot Dec 15 16:00:18 they run at 1 Ghz too? Dec 15 16:00:21 200 MHz Dec 15 16:01:33 And 32 bits. Very spiff. Dec 15 16:01:34 32 registers (29 general-purpose), each 32-bit Dec 15 16:02:11 @zmatt, i wish the beaglebone to have a quad core... Dec 15 16:02:23 that will make it the ultimate board Dec 15 16:02:23 quad core what? and why? Dec 15 16:02:36 ultimate board for what? Dec 15 16:02:52 i was comparing it with Pi2 Dec 15 16:02:56 Pi3** Dec 15 16:03:15 they have very different characteristics Dec 15 16:03:21 Yes Dec 15 16:03:35 Pi3 is aimed for multimedia Dec 15 16:03:42 with less ports Dec 15 16:03:45 while TI SoCs nowadays focus more on industrial and automotive applications Dec 15 16:03:46 no analogs Dec 15 16:03:52 i see Dec 15 16:04:22 hence they use cores that they're experienced with and suffice for the purpose Dec 15 16:04:31 Not sure what quad core would do for a BBB. It has three cores, effectively, with the pair of PRUs, and orders of magnitude more hardware interface capability. Dec 15 16:04:43 instead of catering to "MOAR CORES, MOAR MEGAHURTZEZ" consumers Dec 15 16:05:48 it will use more power .. there are some disadvantages Dec 15 16:05:56 with quad core i mean Dec 15 16:06:06 not really important... Dec 15 16:07:23 if you want a lot of cores, there's always the beagleboard-x15 :P Dec 15 16:07:42 i didn't know that !! Dec 15 16:07:47 i will check it out Dec 15 16:07:48 dual cortex-a15, two c66x dsp cores, four PRU cores, four cortex-m4 cores Dec 15 16:07:58 wow.. A15s Dec 15 16:08:20 large cores.. Dec 15 16:08:53 one of the faster 32-bit ARM cores I think Dec 15 16:08:55 I was going to mention that, but there it is. (grin) Dec 15 16:09:55 to me it seems a beaglebone is more suited for home automation.. Dec 15 16:10:08 to control alot of sensors in home Dec 15 16:10:15 with a node js server Dec 15 16:10:17 Or any automation / interfacing. Dec 15 16:10:36 note that the particular core can matter quite a bit... e.g. although the Cortex-A7 implements the Neon instruction set, some Neon instructions take 4 times as many cycles as the same instruction on the Cortex-A8 Dec 15 16:10:45 (cortex-a7 is used e.g. in rpi2) Dec 15 16:12:37 @zmatt, rPi3 uses 1.2GHz 64-bit quad-core ARMv8 CPU Dec 15 16:12:51 yeah, do they run a 64-bit OS yet? Dec 15 16:13:15 not sure, i don't have own the rPi3 yet Dec 15 16:13:31 since I heard they couldn't yet because some of the drivers didn't support 64-bit yet Dec 15 16:14:20 but in general I don't really care about the rpis Dec 15 16:14:22 zmatt: there's a 64bit kernel port, but I think the rootfs is still totally 32bit Dec 15 16:16:43 zmatt: not that I care much, but the constant aarch32 / aarch64 switching was a good test of openocd ;) Dec 15 16:17:23 openocd sounds like a condition engineers suffer from... Dec 15 16:18:31 lol Dec 15 16:18:51 thinkfat: a quick google on the rpi forums doesn't make it seem like they're using a 64-bit kernel yet, just some experimental builds? Dec 15 16:19:12 oh lol, "KVM ideally requires an ARM GIC (interrupt controller). The Pi3 has a proprietary Dec 15 16:19:15 interrupt controller that is at best documented by source code, reverse engineering and guesswork. Dec 15 16:19:29 so no KVM either Dec 15 16:19:30 nice Dec 15 16:19:33 zmatt: well I said there's a 64bit kernel port, not that it's officially used Dec 15 16:20:26 zmatt: and you could of course implement a virtual interrupt controller in kvm that is close enough to what the broadcom driver expects ;) Dec 15 16:21:30 zmatt: or, you implement an ARM GIC in kvm and hack the device tree Dec 15 16:22:10 but of course, that would be slow Dec 15 16:22:15 hehe Dec 15 16:24:06 the GIC VCPU interface is nice because you can just map it into the guest and let it operate on the registers without a need to trap into the hypervisor Dec 15 16:24:17 edubai__: but really the am335x on the beaglebones is really nice for I/O and interfacing Dec 15 16:24:30 edubai__: besides the awesome PRU there's all sorts of nice peripherals Dec 15 16:24:58 i wanted the beaglebone black wireless but there was no stock Dec 15 16:25:04 CAN controllers, lots of PWM Dec 15 16:25:04 the new one.. Dec 15 16:25:10 I wouldn't want one Dec 15 16:25:13 it has no ethernet Dec 15 16:25:14 why? Dec 15 16:25:22 so what ? Dec 15 16:25:47 not good for baremetal hacking Dec 15 16:25:55 I guess it's a matter of preference :) but that's why there are two versions now Dec 15 16:25:59 i woudn't want an ethernet cable on my robot Dec 15 16:27:12 edubai__: if you want something with more cores, "sabrelite" board is available with an iMX6 Quad core cpu Dec 15 16:27:55 i was reading about the beaglebone ports, if you try opening and closing without adding a small delay that will cause the cpu to reach 100%?? Dec 15 16:28:14 edubai__: the black wireless would have been a better choice than the green wireless though... the morons from seeed studio didn't reuse the ethernet pins for wireless but instead sacrificed a whole bunch of pins on the expansion headers Dec 15 16:28:58 edubai__: uhh, if you do stuff continuously then obviously the cpu is.. doing stuff continuously Dec 15 16:29:15 @zmatt, that's bad !! i was looking for missed ports but did'nt notice Dec 15 16:30:22 it's especially stupid since the pins (formerly) used for ethernet form a separate io voltage domain, so they could have put those on 1.8V (which the wireless chipset requires) and avoid having to use level shifters Dec 15 16:30:41 I thought the same, did they sacrify any ports for the wireless but I couldn't find which ports Dec 15 16:31:22 i made a mistake buying two lol Dec 15 16:32:10 i will get all the versions, black, black wireless Dec 15 16:32:30 * zmatt has two of the beaglebone enhance Dec 15 16:32:32 d Dec 15 16:32:46 and X15 :P Dec 15 16:32:55 that's a beagleboard, not beaglebone :) Dec 15 16:33:20 without any bones? Dec 15 16:33:22 lol Dec 15 16:35:39 it was recently found that a lack of bone on embedded platforms was linked to quick prototyping... Dec 15 16:36:17 that's right - today's a combination of boredom and having little to contribute... don't mind me, carry on. Dec 15 16:36:40 extra pins used by the bbgw are P8.{11,12,14-18,26} and P9.{12,28-31} Dec 15 16:36:50 maybe it doesn't require all of them though Dec 15 16:37:04 oh and P9.41 Dec 15 16:39:26 @zmatt, i looked at the pins diagram, both green wireless and black are identical Dec 15 16:39:45 they are, but both also attach on-board stuff to some pins Dec 15 16:40:20 they didn't mention this. Dec 15 16:40:37 they do in many places last time I checked, at least the bbb Dec 15 16:41:05 where in bbb? Dec 15 16:41:54 I've made my own spreadsheet though which includes overviews for the BBB -> https://goo.gl/Jkcg0w (the orange-marked tabs are BBB-specific) Dec 15 16:42:37 my P8 tab doesn't show alternative functions for which you could use the eMMC pins since I always run from eMMC myself Dec 15 16:44:40 is running from eMMC slower ? Dec 15 16:44:57 i mean the SDcard Dec 15 16:44:59 http://elinux.org/Beagleboard:Cape_Expansion_Headers this also marks the pins used for eMMC and HDMI Dec 15 16:45:21 not eMMC, i mean the sdcard Dec 15 16:45:29 sdcard depends heavily on the card Dec 15 16:45:58 oh ok, depends on the card itself Dec 15 16:46:06 the max theoretical speed for sdcard however is 1/2 the max speed for eMMC Dec 15 16:46:13 since the interface is 4-bit while the eMMC interface is 8-bit Dec 15 16:47:03 however also with eMMC it's not necessarily the interface speed that's the limiting factor, especially for writes. it depends a bit on which particular eMMC they placed, which can vary Dec 15 16:47:21 Oh lovely, eMMC Dec 15 16:47:28 hi folks :) Dec 15 16:48:25 did you know apple using a full speed pcie ssd in the iphone 6s? that's why most android devices can't compete Dec 15 16:50:00 sorry for going off topic Dec 15 16:50:07 just saying Dec 15 16:51:57 there also the interface isn't the limiting factor: http://tssdr1.thessdreview1.netdna-cdn.com/wp-content/uploads/2015/10/iPhone-Passmark-Disk-Speed-Chart.png Dec 15 16:52:09 especially for writes :) Dec 15 16:52:27 which makes perfect sense since it's all just NAND flash under the hood Dec 15 16:53:27 Mm Dec 15 16:53:39 I still have two devices on my desk with morphic eMMC that I can't figure out Dec 15 16:54:12 Spidler: the phenomenon persists even after power cycling? that *is* pretty bizarre Dec 15 16:54:15 @zmatt, what do you use the beaglebone for ? Dec 15 16:54:39 zmatt: Well, my squashfs filesystems aren't readable anymore. just _that_ I think is weird Dec 15 16:54:59 I'm thinking about a weather station, not sure yet Dec 15 16:55:05 Meh, it's xmas. I need a bluetooth speaker... I wonder if someone has a kit I can build Dec 15 16:55:10 Spidler: certainly, but that could have happened due to a kernel fuck-up Dec 15 16:55:18 zmatt: Yep. Dec 15 16:55:28 Spidler: it would have helped if you had hardware write-protected the sectors of the squashfs partition Dec 15 16:55:30 brb Dec 15 16:55:48 zmatt: Well, I want to overwrite them bi-monthly :) Dec 15 16:56:02 Spidler: unprotect, overwrite, protect Dec 15 16:56:05 Hmm Dec 15 16:56:11 Is that supported by Linux? Dec 15 16:56:26 Or do I end up having to fess with the emmc controller directly? Dec 15 16:56:36 maybe check if mmc-utils has it implemented Dec 15 16:56:49 I didn't see anyhting Dec 15 16:57:46 beware there are three kinds of write-protect you can apply to an allocation block: non-volatile (can be freely set and unset), until next power-cycle (cannot be cleared except by power-cycle), and permanent Dec 15 16:58:21 Seems that it can only do a full device tuntil next boot Dec 15 16:58:48 (you can also reduce the chance of accidents by setting the bit to permanently disable the ability to apply permanent-write-protect) Dec 15 16:59:04 that sounds handy Dec 15 16:59:25 How does the write reliabiltiy function work? Dec 15 16:59:26 mmc writeprotect user set Dec 15 16:59:45 zmatt: which mmc is that? Not mentioned here: http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/tree/man/mmc.1 Dec 15 17:00:11 maybe the man page isn't uptodate, I just got this from the help output of the command itself Dec 15 17:00:34 You're right Dec 15 17:00:35 oh yeah, write reliability... that little detail -.- Dec 15 17:00:38 It's in the documentation.... Dec 15 17:01:17 "irreversible change" Dec 15 17:01:21 How lovely Dec 15 17:01:28 That really invites me to want to play with it Dec 15 17:01:38 yes very developer-friendly Dec 15 17:02:01 write-reliability can only be set during hardware partitioning Dec 15 17:02:04 which is OTP Dec 15 17:02:25 Ah Dec 15 17:02:28 "don't touch it" Dec 15 17:02:31 as for what the bit indicates, hold on I'll quote the standard Dec 15 17:02:40 one last question.. can a beaglebone be used for an airbag system that requires realtime response? Dec 15 17:02:49 @zmatt Dec 15 17:02:56 edubai__: With the PRU you can do that, afaik. Dec 15 17:03:02 I wouldn't want a bunch of beaglebones flying towards me in a crash Dec 15 17:03:07 Since a PRU can read a pin in 5ns I would expect that's sufficient. Dec 15 17:03:09 lol Dec 15 17:03:22 ok thanks Dec 15 17:03:29 Does the PRU reset when the board resets/reboots? Dec 15 17:03:50 Ragnorok: the response time is more than 5ns though (due to hardware delays) Dec 15 17:03:53 Spidler: yes Dec 15 17:04:20 zmatt: Ofc. Dec 15 17:05:08 Ragnorok: iirc I got around 25ns round-trip from gp input to gp output (with a program that just continuously copied input to output) Dec 15 17:05:15 that includes resynchronization time of course Dec 15 17:05:29 Sounds pretty good. Dec 15 17:05:56 Spidler: Dec 15 17:05:59 0x0: In the main user area, write operations have been optimized for performance and existing data could be at risk if a power failure occurs. Dec 15 17:06:02 0x1: In the main user area, the device protects previously written data if power failure occurs during a write operation. Dec 15 17:06:05 Wonder why so high though? If you're on the same register that's mapped to the PRU, wouldn't it be three instructions? Dec 15 17:06:15 Why can't we just make dashes and steering wheels out of really soft, cushiony material instead Dec 15 17:06:32 zmatt: So it's similar to the write cache on other hardware? Dec 15 17:06:40 Spidler: no it's worse than that Dec 15 17:06:44 Ohh Dec 15 17:06:52 fsync can't save you now? Dec 15 17:07:52 afk Dec 15 17:08:01 Spidler: lemme find the article again which explains the issue Dec 15 17:08:03 zmatt: what'd you use for your i/o program? remoteproc/rpmsg? Dec 15 17:08:17 zmatt: Appreciated! Dec 15 17:08:20 rajesh: ? Dec 15 17:08:40 zmatt: the test you mentioned above re: 25ns Dec 15 17:08:45 rajesh: I don't know much about rpmsg, though the little bit I saw of it makes me not very inclined to look further into it Dec 15 17:09:29 rajesh: as I said I used a pru program that copied the gpi to the gpo (every cycle) Dec 15 17:09:52 yes, and what're you using for accessing the pru? Dec 15 17:10:26 to upload the pru program you mean? I just mmapped pruss Dec 15 17:10:33 ok Dec 15 17:12:47 Spidler: eMMC also supports (during hw partitioning) marking some hw-partitions and/or some subarea of the main user partition as being "enhanced", the meaning of which is left to the manufacturer but apparently means in practice that it'll be SLC flash instead of MLC Dec 15 17:14:54 zmatt: ahh. Right. Dec 15 17:15:24 Spidler: ah this is the article I read recently (although I already knew about it before then): https://www.embeddedarm.com/blog/preventing-filesystem-corruption-in-embedded-linux/ Dec 15 17:15:51 Oh, thank you. Seems like fun Dec 15 17:15:55 How are your projects going? Dec 15 17:16:16 Spidler: the usual Dec 15 17:16:22 lots of screaming and flailing going on Dec 15 17:16:23 ;-) Dec 15 17:17:25 deadlines vs stupid piece of software that stubbornly resists being written Dec 15 17:19:13 Ahh, lovely Dec 15 17:19:32 I can say that "corrupting eMMC" sort of took the wind out of me these last few weeks Dec 15 17:19:45 Been reimplementing stuff to regularly checksum the drives of all devices Dec 15 17:20:05 Just to attempt and get a warning of _when_ it happens next. Dec 15 17:20:19 hmm Dec 15 17:21:17 the data is already protected by ECC while stored in flash though, and by CRC when transferred via MMC Dec 15 17:21:40 yep Dec 15 17:22:09 Which is all the more confusing, as the error happened on two different boards, but not the others, and all of them run the same software combination Dec 15 17:25:42 occasionally reading the whole thing might perhaps still be useful as a "scrubbing" procedure, assuming the eMMC firmware will rewrite a block if it had an uncomfortable amount of correctable errors during read Dec 15 17:25:52 I have no idea whether it does though Dec 15 17:26:59 which eMMC do your beaglebones use btw? Dec 15 17:27:24 Built in Dec 15 17:28:16 zmatt, where can i find a sample program that uses a PRU to read a pin and write to another pin? Dec 15 17:28:33 @zmatt Dec 15 17:28:33 Spidler: yes, but which is that? there's at least three different eMMC chips I've seen used Dec 15 17:30:07 zmatt: lemme find a screwdriver Dec 15 17:31:47 i found a good resource for working with the PRUs >> http://credentiality2.blogspot.ae/2015/09/beaglebone-pru-gpio-example.html Dec 15 17:32:03 edubai__: https://github.com/beagleboard/am335x_pru_package Dec 15 17:32:10 Spidler: mmc cid read /sys/bus/mmc/devices/$device Dec 15 17:32:37 zmatt: It's not hooked up right now :) Dec 15 17:32:46 @zmatt, thanks i will look into it Dec 15 17:33:16 Spidler: ok, I just noticed the cid output isn't quite as useful anyway Dec 15 17:33:40 it's a kingston, I'll just have to google to see which of the numbers is the part # Dec 15 17:34:08 KE4CN2H5A or EMMC04G-S100 Dec 15 17:34:18 KE4CN2H5A Dec 15 17:34:33 ok Dec 15 17:35:56 it's noticably faster than the micron MTFC4GLDEA-0M WT is (or used to be) commonly used for beaglebones Dec 15 17:36:30 I noticed the latest ones we got are kingston EMMC04G-S100, a newer and even more poorly documented one Dec 15 17:36:59 Oh lovely Dec 15 17:37:03 What do you build with them? Dec 15 17:37:20 they're used in all sorts of products really Dec 15 17:38:18 our own products are active speakers though, in which the bbb is responsible for programming the dsp, managing the ui, etc Dec 15 17:38:40 active speakers? Got a link? Dec 15 17:38:51 http://dutchdutch.com/ Dec 15 17:39:00 Shouldn't that be .nl? ;) Dec 15 17:40:11 Fancy things! Dec 15 17:40:28 but we're in the same building as the engineering firm from which we've split off so we also "borrow out" our experience/expertise with the bbb, so that's how I also get involved in speaker-unrelated projects Dec 15 17:40:42 Ahh, right Dec 15 17:50:29 Spidler: btw excessive reads from a flash block do also cause the stored data to deteriorate, though presumably the eMMC firmware will deal with that and rewrite/move the block when necessary Dec 15 17:50:33 :) Dec 15 17:50:47 just a fun fact Dec 15 17:51:06 zmatt: Yeah, I read that when researching this. Also, non-reads from a flash block for an amount of time will cause detoriation Dec 15 17:56:12 still, eMMC *ought* to deal with all of this. the main hazard there afaik is stuff like power failure during write, that's where performance trade-offs come in (configurable with the write-reliability bits in eMMC 4.41) Dec 15 17:56:43 Yeah Dec 15 17:56:55 Well, these two had 150+ days of uptime: ) Dec 15 17:57:05 No problem with power loss there. Dec 15 17:57:21 And it was the currently running partition that'd failed under it, so the rootfs (squashfs) failed.... Dec 15 17:57:39 That's how I discovered it.. it couldn't open command line utils as reading them from disk failed. Dec 15 17:58:14 did you manage to get a kernel log? Dec 15 17:59:04 Nope Dec 15 17:59:09 dmesg was part of what couldn't load Dec 15 17:59:18 The other one I got it from Dec 15 17:59:22 No errors on the block device Dec 15 17:59:33 just "suddenly" started to get decompression errors from squashfs Dec 15 17:59:41 No block level / IO errors Dec 15 18:00:01 dd if... iflags=direct |sha1sum ; returned different data each time Dec 15 18:04:58 pretty bizarre Dec 15 18:05:53 did this behaviour persist? (I'm assuming it eventually got rebooted) Dec 15 18:06:23 it stopped _while_ i was doing it for a few hours. Dec 15 18:06:34 Not even powering them down Dec 15 18:07:11 Working theory so far is that we hit bad flash, cause of too much writing and the firmware didn't have enough blocks to work with to rotate them. Dec 15 18:07:18 But that's just a theory as bad as any other Dec 15 18:07:43 that would imply extremely broken eMMC firmware though Dec 15 18:09:28 I prefer to think of them as "user friendly" Dec 15 18:09:43 "you don't want an error, do you? no, lets hide that and just return something fun!" Dec 15 18:09:52 btw are your partitions 4MB-aligned? Dec 15 18:09:56 Now they are Dec 15 18:09:59 Used to not be Dec 15 18:10:07 Those two are not aligned on erase blocks Dec 15 18:10:36 Other reason to expect the flash is that it saw 1.5TiB of writes Dec 15 18:10:42 Which is big Dec 15 18:10:57 did you check if their corruption happens to be limited to an erase block? Dec 15 18:13:35 No, haven't done that Dec 15 18:13:59 since you presumably know what the content of the squashfs partition should have been Dec 15 18:14:13 yea Dec 15 18:14:40 doing a diff of sorts would be high on my list of things to investigate in a case like this Dec 15 18:15:01 1.5TB is avg less than 500 writes/block, not that much at all Dec 15 18:15:40 1.5TB on 2TB Dec 15 18:17:06 ? Dec 15 18:17:12 1.5TB / 4GB Dec 15 18:20:07 1.5TB on 1.5GB or so Dec 15 18:20:12 But still not that bad. Dec 15 18:20:32 right but wear leveling is across the physical storage available Dec 15 18:20:36 hence the / 4GB Dec 15 18:26:51 if the device is really low on spare blocks this might show up in ECSD via DYNCAP_NEEDED, maybe Dec 15 18:33:07 you can download the eMMC standards from JEDEC btw (free registration required), although they're pretty awful to read Dec 15 18:34:49 zmatt: But when 50% of the device is static data that never changes, wear levelling can't really do much with it? Dec 15 18:35:24 it should occasionally move those to ensure wear leveling doesn't get too heavily inbalanced Dec 15 18:39:28 lol... http://imgur.com/itA9S0j Dec 15 18:47:33 Yeah Dec 15 18:47:57 I've started to discard the partitions (including empty space) to allow wear levelling to have stuff Dec 15 18:52:46 yey! office discussion about which normal form of unicode to accept Dec 15 18:52:47 hah Dec 15 18:52:54 lol Dec 15 18:53:33 There's also arguments about if we accept visually similar characters or not . Dec 15 18:53:33 :) Dec 15 20:02:10 Spidler: I'm reminded of https://xkcd.com/1726/ ;-) Dec 15 20:03:19 Hahaha Dec 15 20:03:24 Way too true Dec 15 21:25:32 has anyone ever tried to design a cape for the bbb? Dec 15 21:28:56 if you have a specific question it probably makes more sense to ask that :) Dec 15 21:29:04 woups, sorry Dec 15 21:29:08 unless you're just polling for statistics ;) Dec 15 21:29:17 I'm a zero. Dec 15 21:29:30 a friend of mine is designing beagle bone cap that contians a can transceiver and he is suggesting to add a "buffer ic" Dec 15 21:30:05 i believe it is because the specs say that the CPU does not like it if there is a activity on the RX/TX pins Dec 15 21:30:11 while booting up Dec 15 21:30:47 i'm trying to wrap my head around this and see if it is necessary Dec 15 21:31:06 the pins are high-impedance with weak pull (up or down depending on pin) until they are configured by software Dec 15 21:31:08 or find the specific section in the docs, but 5k pages aren't easy to grok for an amateur Dec 15 21:31:18 however Dec 15 21:31:39 so high-impedance == lots of resistance == no issue, weak pull == dito? Dec 15 21:31:56 it is critical that you don't try to drive a voltage into I/O pins that exceeds the I/O supply voltage (vdd_3v3a) at all times, including during power-up and power-down Dec 15 21:32:33 but that should never happen with a can transceiver, should it? since it only drives the vdd_3v3a back into the rx/tx pins? Dec 15 21:34:31 well, that's one little detail: vdd_3v3a isn't on the expansion headers, only vdd_3v3b is. still, if the CAN transceiver is powered from the vdd_3v3b then things should be fine. it may be advisable to still include a series resistor near the pin driven by the transceiver, both as a safety measure and for signal integrity Dec 15 21:34:58 um Dec 15 21:35:23 excuse my naivety, but there's two vdd_3v3s ? Dec 15 21:36:10 yes, unfortunately. it was felt necessary to be able to supply enough current on the 3v3 Dec 15 21:36:21 still I'm personally not happy with the way the split has been done Dec 15 21:37:27 each time that i think i have something resembling of a grip on these things, something like that comes up... Dec 15 21:37:41 during power down vdd_3v3b remains enabled far too long. however, at that time vsys (supply of the LDOs) has already dropped down enough that it looks like abs max voltage ratings are not being exceeded Dec 15 21:39:30 so in easier terms, a resistor between the transceivers power supply pin and the board is advisable, because the are multiple 3v3s and the wrong one (i.e. not the one powering the CPU) is exposed on the header? Dec 15 21:39:46 https://lh3.googleusercontent.com/-aWEH_7JAEbw/VUBn8aVmaoI/AAAAAAAAACE/5RFxipIqG_E/s1600/dc.png this shows power up and power down sequences at easily accessible terminals except vdd_3v3a (I hadn't realized yet at the time that vdd_3v3a is actually easily accessible for measurement) Dec 15 21:40:53 sgflt: uhh, you don't put a series resistor on a power supply pin obviously Dec 15 21:41:49 right Dec 15 21:42:11 that's why it's not me designing capes =) Dec 15 21:42:40 on the can rx signal, which is driven by the transceiver. such a series resistor (placed near the driving side) is highly recommended on high-speed signals anyway unless the driver is already impedance-matched to the trace Dec 15 21:43:23 on your graph, which color is 3v3a? Dec 15 21:43:26 as a bonus it also limits current in case of screw-ups (like accidently configuring a pin as output) Dec 15 21:45:59 sgflt: as I just said, it's not in this set of measurements Dec 15 21:46:45 ah, i missed that Dec 15 21:47:35 so if i understand this correctly, a resistor is required, but a buffer ic (that delays powering the cape?) has no effect because the way the pins react to outside interference only changes when they are configured through software (which would be much later, after the kernel has been loaded)? Dec 15 21:48:24 I'm wondering if I'm missing some detail, why would he think the buffer ic wouldn't have whatever problem he thinks the transceiver ic would have? Dec 15 21:49:31 i'm not sure, i don't think i understood it correctly i guess Dec 15 21:49:43 a resistor is not required, I just advise it for reasons of signal integrity and peace of mind. there's always the option of placing a 0ohm "resistor" if it's later deemed unnecessary/undesirable Dec 15 21:50:53 ehh, "a buffer ic (that delays powering the cape?)" ... what? Dec 15 21:51:10 that part in parentheses makes no sense Dec 15 21:51:24 well that's the part that i added. figures Dec 15 21:52:13 a buffer is an IC whose function is basically just "output = input" Dec 15 21:52:26 what about the other direction by the way. is there a chance that a CPU starting up might trigger some accidental transmission on the CAN bus this way, if the transceiver was already powered? Dec 15 21:55:02 the pins are high-Z with weak pull-up while the cpu is in reset and afterwards until configured otherwise by software Dec 15 21:56:15 so i'd need to look up what the transceiver would do if it received a constant high signal? Dec 15 21:56:16 during power-up sequence the I/O pins will initially be effectively grounded (when vdd_3v3a is still at 0V) but the transceiver IC won't be powered yet at that time either Dec 15 21:56:39 I'm fairly certain that high = idle for CAN Dec 15 21:57:22 if I remember wrong, you can override the weak pull-up with a stronger pull-down resistor on the pcb (1K - 10K or so) Dec 15 21:57:59 that is very good to know, thanks Dec 15 21:58:32 well, i'm out of ideas. again, thanks for all the feedback, it has been helpful and will be even more so when i pass it on! Dec 15 22:00:08 sgflt: I just looked at one schematic where we implemented CAN Dec 15 22:01:17 oh, is that one open source/hardware by chance? Dec 15 22:01:34 it's worth noting the transceiver we used had two supplies: it had a separate VIO supply for the communications with the microcontroller Dec 15 22:01:53 the other supply being 5V Dec 15 22:02:25 if it did not have that feature then a buffer/level-translator would have been necessary to glue it to the bbb Dec 15 22:02:28 was that with a 5V transceiver chip? Dec 15 22:03:31 MCP2562 Dec 15 22:05:24 I think 5V is standard for CAN ? Dec 15 22:06:41 i think it varies Dec 15 22:06:48 but i may be wrong Dec 15 22:07:28 http://www.ti.com/lit/an/slla337/slla337.pdf this PDF shows 3.3V can transceivers do exist, and the fact this pdf exist to try to reassure people that it's okay suggests it's probably not a standard thing :P Dec 15 22:07:46 we've used the SN65HVD231, powered directly from the BBB Dec 15 22:09:31 i believe a difference of 2.5V is used on the bus (which is conveniently half of 5V?), a little less for 3.3V transceivers Dec 15 22:10:27 and 12 V / 24 V in absolute voltage (is there such a thing in this case)? wild guess though Dec 15 22:14:32 Hello. its my first time att I wil use beaglebone black. my project is about balancing beaglebone black. and it must be controlled by an android smartphone. I'm going to use a USB Bluetooth dongle. but I do not know what should I choice. it must be a normal Bluetooth dongle or ...? thanks Dec 15 22:16:40 sgflt: if you're using one of these powered from the 3v3b then I don't see a clear reason for a buffer Dec 15 22:18:19 zmatt: that was for the prototype, but i think i get what you're hinting at. Dec 15 22:18:41 zmatt: anyway, thanks for all the advice. i need to be off now as well =) Dec 15 22:20:12 anyone can help me ? Dec 15 22:21:10 Jack: haven't used bt yet, sorry Dec 15 22:21:36 ok thnx Dec 16 00:43:14 das beaggg **** ENDING LOGGING AT Fri Dec 16 02:59:59 2016