**** BEGIN LOGGING AT Fri Oct 26 02:59:59 2018 Oct 26 03:56:53 can you pastebin your device tree definitions? Oct 26 03:57:46 zmatt: me? :) Oct 26 03:57:57 who else? Oct 26 03:58:25 didn't know if I'd missed mesages, bit of a gap :) Oct 26 03:58:49 ah Oct 26 03:58:50 https://paste.debian.net/1049082/ Oct 26 03:59:45 adau1977-adc is the machine driver I've written, just following their example Oct 26 03:59:51 it gets loaded Oct 26 04:00:06 machine driver? o.O Oct 26 04:00:27 this doesn't look like any alsa definitions I've ever seen Oct 26 04:00:49 normally sound{} would be a simple-audio-card instance Oct 26 04:02:28 okay, the TI examples suggest modifying their EVM to add the driver and the Analog suggests creating a machine driver https://www.kernel.org/doc/html/v4.16/sound/soc/machine.html Oct 26 04:03:13 I've seen the evm driver but my impression is that it's some legacy thing that's still around for backwards compat reasons Oct 26 04:03:28 so I just used their example machine driver and changed the names where appropriate for the Oct 26 04:03:43 simple-audio-card doesn't require any coding, it's configured via DT properties Oct 26 04:03:48 ahh, yeah i was wondering why nothing was mentioning the simple-audio-card Oct 26 04:04:08 you don't want to have to write kernel code for every possible way you connect some codec to a SoC Oct 26 04:04:28 yeah Oct 26 04:04:46 was a little suprised that was the recommended way :) Oct 26 04:05:13 I attempted to try simple-audio-card and that's when I got the machine to not boot :) Oct 26 04:06:51 https://paste.debian.net/1049083/ that's the simple-audio-card dts Oct 26 04:07:02 I suspect it's the way I specified clocking that's the issue Oct 26 04:08:34 https://pastebin.com/VmHHXagD Oct 26 04:10:37 hmm, I don't see very obvious problems with your dts at first glance Oct 26 04:11:44 although #sound-dai-cells doesn't belong in the codec child of your sound card, it belongs in the codec itself (i.e. in &adau1977) Oct 26 04:12:58 it indicates how many arguments are expected after <&adau1977> in the sound-dai property Oct 26 04:13:02 i.e. none Oct 26 04:13:46 ahh okay Oct 26 04:14:49 should I have another bash with the simple-audio-card version? I'm a bit scared of it now ;) Oct 26 04:15:02 the other version is loading all the modules and everything in /sys/ looks correct Oct 26 04:15:04 i2c etc Oct 26 04:15:10 but nothing in alsao Oct 26 04:15:23 oops, asound in proc Oct 26 04:15:38 simple-audio-card works perfectly for me Oct 26 04:15:56 and DT mistakes can always result in boot failure Oct 26 04:17:41 but recovery is so easy, messing up boot is not really something to be concerned about Oct 26 04:17:56 if it happens, boot from sd card and undo the mistake Oct 26 04:18:06 should I connect up console uart to get some logging on what is failing? Oct 26 04:18:11 absolutely Oct 26 04:18:28 that's where your diagnostics are going Oct 26 04:18:32 is it only on the other header pins or somewhere on the normal p8 / p9 headers? Oct 26 04:18:52 because they other header is really hard to get to with the the other board plugged in... Oct 26 04:20:01 I'm fortunate enough to have one of these for situations like that => https://www.tindie.com/products/spirilis/beaglebone-black-ftdi-friction-fit/ Oct 26 04:20:48 ahh :) Oct 26 04:20:49 since the header is through-hole, you could solder onto the other side Oct 26 04:21:12 (only three pins of the pins matter) Oct 26 04:21:25 hah, i just picked it up to look at the other side to see if it was clear :) Oct 26 04:21:50 that's probably the easiest option Oct 26 04:22:23 in theory you could use a different uart, one that's on the P9/P8 headers, but then you'd need to modify and recompile u-boot Oct 26 04:22:23 unmating the BB from the main board takes a while... pins are pretty tight. Oct 26 04:22:33 ahh yeah Oct 26 04:23:22 otherwise you wouldn't be able to have the console until the kernel has set up your new console pins based on DT... which might not be useful if you're debugging DT problems ;) Oct 26 04:23:37 or overlay problems Oct 26 04:25:38 I'm pretty sure target = <&scm_clocks> is going to be the problem with the simple-audio-card part Oct 26 04:25:53 just because I don't really understand what's going on there Oct 26 04:25:59 I don't see why, although I also don't see why you'd put it there Oct 26 04:26:08 but it's a fixed-clock so it doesn't really matter much where you put it Oct 26 04:26:41 yeah, also think it might be wrong. Because I don't know how to reference the codec's clock Oct 26 04:27:27 did you look at my example? Oct 26 04:28:32 note btw that having everything directly inside the /sound node and prefixed with simple-audio-card, is also valid, I just prefer creating an explicit simple-audio-card,dai-link node and use non-prefixed properties in there Oct 26 04:28:35 yeah, but I'm not sure where audio_osc_ck is defined Oct 26 04:29:19 in your example Oct 26 04:29:27 oh depends on the setup. it's either a gpio-gate-clock that controls the beaglebone's audio osc when I use that, or it's a fixed-clock if it's an externally provided clock Oct 26 04:30:15 ahh okay, so it is defined elsewhere like the fixed clock is Oct 26 04:30:29 in my example Oct 26 04:30:49 yeah, I probably tossed it into / or something, dunno Oct 26 04:31:52 ah I created a "clocks" node in / (declared as simple-bus) to hold all my misc clocks... purely for to have them together for aesthetic reasons ;) Oct 26 04:32:23 so only change is the sound-dai-cells which I guess would break things if the default was to expect parameters Oct 26 04:32:30 so really the #sound-dai-cells is the only big wrong thing I see Oct 26 04:32:30 yes Oct 26 04:33:04 here's a real-world example illustrating how those #property-cells things work: https://pastebin.com/ef6R6g1J Oct 26 04:35:22 so it's an array of &node followed by exactly as many arguments as the #interrupt-cells of that node specifies Oct 26 04:36:01 so without those #interrupt-cells, the property is just an unparseable array of numbers Oct 26 04:36:49 there are lots of properties that use this format, e.g. gpios (#gpio-cells), dmas (#dma-cells), pwms (#pwm-cells), etc Oct 26 04:38:02 and of course #address-cells and #size-cells which are needed to be able to parse the "reg" and "ranges" properties Oct 26 04:38:31 anyway, I really need to get some sleep Oct 26 04:45:15 ahh neat, thanks for the info. Sleep well Oct 26 04:45:19 Lunch time for me! Oct 26 07:14:28 so the only debugging i'm getting on the console during boot is failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND any idea how to work out what is going on? Oct 26 07:34:47 Hello BBB people. I'm trying to build an custom image to run on BeagleBoard-X15 REVC. For this I'm using TI AM57XX processor SDK. I have managed to build a Yocto image with custom device tree where I have changed cmem size, pools and dsp1 adress. Oct 26 07:35:11 hi.. Oct 26 07:35:22 anyone online? Oct 26 07:35:44 Enver is Oct 26 07:36:46 i am using beaglebone blue and encountering problems connecting adafruit led display Oct 26 07:37:02 But it seems like I'm missing something. I have tried to connect to DSP1 with XDS2xx usb debugger through CCS but get the error: PRSC module failed to write to a router register. Oct 26 07:38:23 Do I need to include debugss module in order to make JTAG debug work? Oct 26 07:46:45 Enver: possibly Oct 26 07:47:00 Enver: what are you running on the board? Oct 26 07:47:13 Enver: Linux? Oct 26 07:47:44 Yocto Oct 26 07:47:53 same thing Oct 26 07:47:57 ok Oct 26 07:48:37 iirc, the linux kernel after booting might "idle" the debugss and then you get no jtag access... Oct 26 07:48:49 I'm actually able do debug DSP1 with the prebuild BBB image that commes with the board. Oct 26 07:49:19 but not with your yocto image Oct 26 07:49:29 Nopp Oct 26 07:50:03 I have been comparing dtb files to se if there is any JTAG clock configuration that I'm missing Oct 26 07:50:12 no Oct 26 07:50:19 But couldn't find anything stange Oct 26 07:50:38 not jtag, but I guess the dtb needs to have a node that prevents the debugss hwmod to idle Oct 26 07:51:05 let me check, I have a snippet somewhere Oct 26 07:53:00 Enver: you don't have a more detailed error report than what you posted up there? Oct 26 07:53:04 Ok, maybe it is worth mentioning that I don't think that debugss module is installed on BBB original image. Because when running dsptop it says: Can not open debugss module device_name sysfs entry for reading Oct 26 07:54:11 Nope, I can try to give you more information. What else do you need to know? Oct 26 07:54:11 then probably this is not the right track.. Oct 26 07:54:25 more details about what actually goes wrong Oct 26 07:55:37 The only information I get when trying to connect to the DSP1 is the output printed in the CCS console. There is nothing printed in dmesg or so Oct 26 07:55:59 Here is the exact message: C66xx_DSP1: Error connecting to the target: (Error -6305) PRSC module failed to write to a router register. (Emulation package 8.0.27.9) Oct 26 07:56:14 Enver: you're using CCS? Oct 26 07:56:26 Enver: then likely you should ask on the TI E2E forum Oct 26 07:57:22 Enver: I have no idea what a PRSC is, and I can only guess that "router" means the icepick jtag router Oct 26 07:57:31 Hmmm Oct 26 07:57:55 which may mean CCS is not able to, for whatever reason, insert the jtag tap of the DSP1 into the chain Oct 26 07:58:33 I was more wondering if you build the original BBB image with any specific module or kernel setting in order to make sure that remotproc debuging works Oct 26 08:00:08 Also is there any instructions to follow if I would like to recreate the original BBB image. Oct 26 08:00:09 ? Oct 26 08:05:37 Enver: never done that... Oct 26 08:08:03 Alright, thanks for your time. Oct 26 08:08:40 Enver: just stick around, others on the channel may be able to help you better, but I encourage you to ask on the e2e forums Oct 26 08:15:27 thinkfat_: Ok. I will try to ask in e2e but it is not as easy or nice to ask question on e2e as it is here :P Oct 26 08:16:34 BTW is there any way to sort out messages directed to after couple hours of random people login logout messages? Oct 26 08:21:48 Enver: grep? Oct 26 08:23:49 I meant here in the chat window Oct 26 08:24:23 Ctrl+f worked fine, never mind :) Oct 26 08:25:03 I can just ask my chat client to not display join/leave/nick events (except for watched nicks) Oct 26 08:25:22 then it becomes much more silent Oct 26 08:25:58 but if course it's impractical as you won't notice if a chat partner changed nick or just left ;) Oct 26 11:50:45 Hello guys, I would like to get a confirmation about something for my company. I've read that the beaglebone is free of use and can be implemented in our machines but i can't find the same information about the distribution debian 9.5 does anyone know where I can get this info ? Oct 26 11:56:15 debian.org is their main domain. Please note that open source license compliance for software is non-trivial. Oct 26 14:23:11 tbr: do you have any example cases where it's a gotcha Oct 26 14:44:09 ayjay_t: it's just a lot of work to put all the stuff together. One of the reasons why I do see value in setups that can generate all that for you to the largest possible degree. Like OpenEmbedded or BuildRoot. Oct 26 14:44:53 ayjay_t: I have been on the side of keeping companies honest regarding the software that they ship and it's far from trivial. Oct 26 14:48:06 I guess if they're trying to claim proprietary? Oct 26 14:48:37 my office isn't even going to to try. We have some stuff that links libc, obviously, but I'm pretty sure we can close source that? Oct 26 14:48:47 But the whole platform is open source Oct 26 14:51:20 regardless if you have also closed source stuff Oct 26 14:52:07 compliance in writing your closed stuff is of course also important, but that's more like an "do and check as you go" thing Oct 26 14:59:46 oh man Oct 26 14:59:57 huh i was just gonna ship the whole platform as is Oct 26 15:02:58 ayjay_t: It might be a good idea to ask RCN if he has dealt with anything in this context. He might have more concrete things to share. Oct 26 15:03:23 yeah, it'll go on the list Oct 26 15:06:00 ayjay_t: also it's more about not ignoring things. An intermediate step that would probably be great to cover your bases is to be able to reproduce things from source where necessary. That would be kernel, U-Boot and maybe some bits and bobs. Check what's coming from Debian itself, that you can chalk off as covered as you should be able to get away by taking their sources etc. Oct 26 15:07:04 ha ill end up just building the whole system with gentoo, its my daily driver anyway Oct 26 15:14:36 fair enough, that should also make it easy enough to comply Oct 26 15:45:09 i mean our surface area is too small for me to care right now Oct 26 15:45:13 we're deploying like 3 devices Oct 26 15:45:30 everyone has an opinion about how i should be spending my time Oct 26 15:51:37 :) Oct 26 15:52:29 right, then if you are using the official images you should be able to justify the risk of "having to deal with things afterwards" instead of upfront Oct 26 18:38:20 right i mean its an integral right Oct 26 18:38:34 or a sum of products, actually Oct 26 18:39:09 ( (% risk of prosecution) * (no. of products) ) * (consequences of prosecution) Oct 26 18:39:41 I have Beagleboardx15. I am still quite new to it. I have flashed the latest Ubuntu. I do have some serious issues: Oct 26 18:40:26 The ethernet is extremely slow: 30mb (instead of 700mb as other computers connected to the network) Oct 26 18:40:48 The board sometimes dies. Oct 26 18:41:10 Here are some questions: Oct 26 18:41:33 Is there a diagnostics app? Google did not help me on this Oct 26 18:42:09 Is there a programming C/C++ reference manual Oct 26 18:50:54 the reference manual is the so called TRM - Technical Reference Manual for the SoC Oct 26 18:51:07 there is probably also a SRM, S as in System Oct 26 18:53:08 DreamHiker: How have you determined that the onboard Enet is extremely slow? Oct 26 18:57:46 Dear tbr, could you please send me an url for the TRM Oct 26 18:59:43 http://www.ti.com/product/AM5728 - it's the official processor documentation, easy to find… Oct 26 19:00:08 Ethernet Speed> I have checked it with Speakeasy.net. Youtube bad quality confirms it. Oct 26 19:00:54 erm, that piles a desktop environment and a browser on… Oct 26 19:01:34 you might want to use something more sensible like 'iperf' against a machine on the local network Oct 26 19:08:18 Absolutely. My X15 onboard Enet port #1 (not #2) gets a gigabit connection to my switch....and appears to be bitchin' fast. Oct 26 19:08:50 I'll test out onboard enet #2 later on but I expect little difference. Oct 26 19:11:15 I have no problem pulling 80Mbit/s sustained full motion video from my security camera. And that's ALOT of data. Oct 26 19:44:23 DreamHiker: have you tried the normal debian image instead of ubuntu? I don't think I've ever heard of anyone running ubuntu on an x15 Oct 26 19:44:30 DreamHiker: what kernel does it use? Oct 26 19:51:43 yeah I just tested it, I have no trouble flooding my beagleboard-x15's gigabit ethernet connection Oct 26 20:01:26 using either of the two ports Oct 26 20:06:23 https://pastebin.com/raw/z0hNXvux Oct 26 20:06:35 (note that those speeds are in megabyte/s, not megabit/s) Oct 26 20:13:54 hello, has anyone been able to install the 64-bit driver on a windows 10 pc? Oct 26 20:14:32 Jaz: you don't need to install a driver Oct 26 20:14:49 any sufficiently recent image should work plug&play Oct 26 20:15:10 see https://beagleboard.org/getting-started Oct 26 21:16:58 so 100Mbytes = 800Mbits.... yep. gotta watch vendors and their poor nomenclature. Oct 26 21:24:51 zmatt: how did you generate a 1gig file full of zeros? Oct 26 21:32:26 touch 1G-zeros; fallocate -z -l 1G 1G-zeros Oct 26 21:32:36 it results in a sparse file, so it doesn't actually take up any space Oct 26 21:33:12 rather, the data you read from it is zero-filled on the fly by the kernel Oct 26 21:39:31 ok. cool. I'll note that. Oct 26 21:40:00 I plan to have my x15 positioned as a mitm passing packets to/from my homenet. Oct 26 21:40:17 so I'll be using both enet ports .... Oct 26 21:53:01 Thank you for your help. Is this the best place to ask BB x15 questions? It seems my previous chat session got closed. Can I get back to it? Is there a log? Oct 26 21:53:30 ehh, your session still seems to be open Oct 26 21:55:00 Great! How can I get back to it. I do not see it in the browser Oct 26 21:55:40 maybe freenode's web gateway simply hasn't realized yet that you're gone Oct 26 21:55:58 anyway, here's a log: https://pastebin.com/raw/pT54mCrJ Oct 26 21:57:56 Cool! How did you get this url, so the next time I can do it myself? Oct 26 21:58:15 I just copy/pasted it from my own log into pastebin Oct 26 21:58:31 there should also be online irclogs of this channel, but I don't know whether any are working currently or what their url is Oct 26 22:00:03 bbl Oct 26 22:01:11 Thanks again for the answers. Per the suggestions, I have troubleshooted the ethernet. Oct 26 22:01:43 iperf3 gave me 650Mbit/sec, which is probably good Oct 26 22:02:51 I have tried speedtest-cli. It gave me 250 Mbit/sec download and 80 MBit/sec upload, which probably is good too. Would you agree? Oct 26 22:03:56 I am puzzled why speakeasy.net gives 36MBit/sec and crashes. I am using the default chromium browser Oct 26 22:04:25 The RAM size is not the issue (per htop) Oct 26 22:05:24 When the BBX15 debian crashes, does it give any crash log? Oct 26 22:13:42 anytime your speedtest uses a resource outside your own homenet...like a website out in the wild somewhere you are subject to bottlenecks you have no control over. Oct 26 22:15:14 especially time of day. The dinner hour is gonna be the slowest. Oct 26 22:15:30 8-10pm will be slow too. Oct 26 22:41:14 Snert, thank you for the suggestion. I have compared speedtest-cli against speedtest-cli running on a powerful laptop. The speeds are basicaly the same. Which is good. Oct 26 22:42:01 My question still is why why speakeasy.net gives 36MBit/sec and crashes. I am using the default chromium browser Oct 26 22:51:30 DreamHiker: "crashes" ? Oct 26 22:52:06 crash in what sense? Oct 26 22:52:11 Yes, not always, but quiet often the board crashes Oct 26 22:53:43 have you tried the (normal) debian image instead of the (rarely used, rarely tested) ubuntu image? Oct 26 22:54:35 though even then, I suspect very few people use a desktop environment on their beagleboard... I certainly don't :D Oct 26 22:54:55 and modern web browsers are extremely heavy applications Oct 26 22:56:46 what do you mean by "the board crashes" ? what happens exactly? Oct 26 22:57:22 does the entire gui freeze? is there still led activity? does vt switching still work? Oct 26 22:59:53 I am so sorry. I have mistyped. I am using debian Oct 26 22:59:59 ok Oct 26 23:00:13 a recent image? Oct 26 23:01:40 I have flashed the latest debian: uname -a says: Oct 26 23:02:11 Linux BeagleBoard-X15 4.14.71-ti-r80 ... Oct 26 23:02:16 ok Oct 26 23:03:21 My main concern is not whether I can use chromium, but rather why the system crashes Oct 26 23:05:11 And if it is useful, I have tried to upgrade chromium to the latest one (from 67 to 69). Then chromium does not launch at all - crashes Oct 26 23:05:27 So I have downgraded it back to 67 Oct 26 23:05:55 I'm still waiting for answers to my questions about what exactly you mean by crash Oct 26 23:07:23 i.e. just chromium crashing is a very different thing from the whole system crashing Oct 26 23:07:58 Let me try to crash it again. What is vt switching? Oct 26 23:08:03 (sorry, I meant "e.g.", not "i.e.") Oct 26 23:08:31 ctrl-alt-Fn Oct 26 23:09:34 the gui is traditionally vt 7 (i.e. ctrl-alt-F7 to switch to it), the others are virtual terminals Oct 26 23:10:31 a better thing to try actually is ssh'ing to it Oct 26 23:12:40 if the whole system has crashed (all led activity ceases) then it might be a kernel panic and you'll need to check the serial console to see what's going on Oct 26 23:13:16 if the system is still running in some degree then you can probably still log in via ssh and use that for diagnosis Oct 26 23:16:28 zmatt, Just crashed the board again. Only 1 red led next to the power is on Oct 26 23:16:50 huh, you mean it spontaneously powers off? Oct 26 23:19:09 yeah, if the board is powered on there are two amber leds on, while only one remains on when it's powered off Oct 26 23:19:20 that's interesting Oct 26 23:19:38 are you using an adequate power supply? Oct 26 23:19:50 I have started youtube, playing a video. It took ~ 30 sec to crash Oct 26 23:21:19 Thank you for mentioning about ctrl-alt-f keys. I was unaware of those Oct 26 23:24:15 so, in the future try to describe your actual symptoms (screen goes black, all but one of the board's leds turn off) rather than saying something like "it crashes" Oct 26 23:25:05 simply saying what you see (rather than your guess to what it means) would have immediately made it apparent that the board spontaneously powers off, which is not remotely the same thing as a "crash" (any flavor of that vague word) Oct 26 23:26:02 thus saving time and increasing your probability of getting useful help Oct 26 23:28:44 cool! Thanks! Oct 26 23:30:24 of course now the question is why it powers off. the obvious first suspect would be the power supply, although it's a bit odd it still takes 30 seconds to crash Oct 26 23:31:11 unless maybe at that point some additional activity happens (data in write-cache being written out to eMMC?) Oct 26 23:31:35 another suspect on my mind would be thermal issues from the heavy load caused by chromium Oct 26 23:31:57 although I'm not sure what exactly happens when the system overheats, i.e. I don't know if it powers off or merely resets Oct 26 23:32:33 The power supply is CUI INC 12V 5A. Is it OK? Oct 26 23:33:32 I would certainly hope so Oct 26 23:33:49 The board stay open in the air. No heat-sink. Oct 26 23:35:10 Are you aware of any diagnostics tools that show the tempreature of the components? Oct 26 23:35:19 hmm, interesting => https://github.com/beagleboard/beagleboard-x15/issues/7 Oct 26 23:36:27 I would think that a continual ping against the x15 would stop if that were the problem. Oct 26 23:36:39 Snert__: ? Oct 26 23:36:54 Snert__: his board powers off Oct 26 23:37:03 x15 crashes. Stops responding to a ping against it. Oct 26 23:37:17 or shuts down...same thing....ping stops. Oct 26 23:37:40 Snert__: I'm confused, what are you trying to say? why are you talking about pinging it? Oct 26 23:38:06 I'd run a continual ping against the x15 from a different machine. Oct 26 23:38:06 and crash and poweroff are not remotely the same thing Oct 26 23:38:11 why? Oct 26 23:38:14 the board powers off Oct 26 23:38:20 the power-on led turns off Oct 26 23:38:21 if it powers off, the ping will stop. Oct 26 23:38:38 there's no question about the board powering off, the question is why it powers off Oct 26 23:39:07 I don't understand what hope to accomplish by pinging it Oct 26 23:39:12 *what you hope Oct 26 23:39:25 I always use an outside proof from a different angle. Oct 26 23:39:45 and if the x15 is not in the same room as you it's useful. Oct 26 23:40:00 he's using a web browser on it, of course it's in the same room Oct 26 23:40:17 that can't be assumed though. Oct 26 23:40:21 ??? Oct 26 23:40:27 are you trying to troll? Oct 26 23:40:53 not doing that. Oct 26 23:42:24 DreamHiker_: yeah there should be a bunch of temperature sensors that can be read out Oct 26 23:45:12 DreamHiker_: any standard tools to monitor system temperatures probably work, but you can also just dump the numbers manually with: Oct 26 23:45:17 for i in /sys/class/thermal/thermal_zone*; do echo "$(cat $i/temp) $(cat $i/type)"; done Oct 26 23:45:31 values are in milidegrees celcius Oct 26 23:48:13 if the thermal shutdown is done by linux then there may also be log entries about that Oct 26 23:48:37 try: journalctl -b-1 -n 20 Oct 26 23:48:51 this asks for the last 20 log entries of the previous boot Oct 26 23:50:15 zmatt, I have carefully read the post. I also have run my simple tests: 4 programs: each running an infinte loop. Ran for 30 minutes. 2 cores are 100% busy. But no issues Oct 26 23:51:26 "the post" ? Oct 26 23:53:27 keeping a core active can be trickier than you think. a simple infinite loop only exercises a small part of the processor (unlike for example video decoding, which causes heavy memory traffic and most likely keeps the Neon unit busy) Oct 26 23:53:49 I meant the post you have provided: https://github.com/beagleboard/beagleboard-x15/issues/7 Oct 26 23:55:11 I was just pointing to it because it interestingly reported similar problems as you (spontaneous poweroff when using chrome on certain "heavy" sites)... though curiously he said his problem went away with an update of chrome Oct 26 23:55:34 I can't draw any useful conclusion from it, I just found it interesting Oct 26 23:55:37 I know that the loop does not exercise the core totally. In fact, I was surprised that 2 loop took 100% of each core :) Oct 26 23:56:26 well linux will report 100% simply because your process is active continuously Oct 26 23:56:39 that doesn't mean it is effective in keeping the core busy Oct 26 23:57:32 in fact it's not even that hard to keep the core almost idle while simultaneously using "100%" cpu load (e.g. continuously doing memory accesses that miss cache) Oct 27 00:02:45 Just checked, When it powers down on Chromium, ping breaks Oct 27 00:03:10 well duh Oct 27 01:20:51 hi guy, any suggestions for ESC + DC motor models or specifications which will be possible to integrate with beagle bone blue? Oct 27 01:25:07 autono: All! Oct 27 01:25:43 I bet that you can configure most, if not all, ESCs and DC motors w/ your BBBlue. Oct 27 01:26:24 I did find some info. a while back on people using the Robotics Cape/BBBlue for driving motors. Let me see if I can find it. Oct 27 01:30:39 https://beagleboard.org/p/jkridner/beaglebone-blue-220mm-quadcopter-9801d8 is something that is coming up now. Oct 27 01:30:56 I have had some trouble w/ arducopter before but it may work for you. Oct 27 01:36:08 Use a 2 Cell LiPo for your power input for the BBBlue. I think they are around 7.4v if I am not mistaken. Oct 27 01:36:09 ... Oct 27 01:36:32 The DC motor outputs are on the back of it. There are four of them. Oct 27 01:37:48 Now...onto specifications. Oct 27 01:38:20 he left Oct 27 01:38:25 No! Oct 27 01:38:32 thank you again, zmatt. Oct 27 01:38:55 Damn smarties leaving too early. I was just getting to the nitty-gritty. Oct 27 01:49:52 _set: my connection got broken did i miss something Oct 27 01:50:12 hgsfn: Do you already use the BBBlue for motor control? Oct 27 01:50:57 _set: yes, i am looking to use BBBlue on a rc car which will come with ESC & DC motor with its own amp rating Oct 27 01:51:43 Oh. Oct 27 01:51:54 Okay. So, we need to find out what now? Oct 27 01:52:06 The battery input or something like that? Oct 27 01:52:30 Or...do you need an idea like what software to use? Oct 27 01:53:18 https://github.com/mcdeoliveira/rcpy/blob/master/examples/rcpy_test_motors.py is something I came across. Oct 27 01:53:39 So, you can just call the library and use it. Oct 27 01:53:48 _set: i dont have rc or esc + dc motor, i have seen concerns in stack overflow getting motor to work, sometime talking about the need of program card Oct 27 01:54:18 _set: i dont have rc car or esc + dc motor to start with, i have to make the investment Oct 27 01:54:27 Hmm. Okay! Oct 27 01:54:32 Do you have a BBBlue? Oct 27 01:55:24 yes i do have BBBlue, want to make sure i dont end up fiddling with dc motor for long Oct 27 01:55:35 Oh. Oct 27 01:55:38 Okay. Oct 27 01:56:09 So, you need to know if the wiring is difficult to handle or if motors work w/ the BBBlue? Oct 27 01:56:11 ... Oct 27 01:56:18 https://robotics.stackexchange.com/questions/7057/how-to-control-brushless-motoresc-with-beaglebone Oct 27 01:56:21 I am asking these questions to get a background. Oct 27 01:56:39 I will read that and be right back. Oct 27 01:58:10 Okay and now you need to figure out PWM and GPIO or you want to use something else like a UART connection? Oct 27 01:58:50 hgsfn: I am just trying to better understand. I am not messing w/ on purpose. Oct 27 01:59:03 ... Oct 27 01:59:04 wiring is one thing which i can figure or ask the helpful souls like you here later...for now i want to make a good investment on buying esc + dc motor , which has a good chance to work right away Oct 27 01:59:21 Oh. Oct 27 01:59:57 set_: i think the concern would be figuring out the pwm timings Oct 27 02:00:37 PWM, depending on your library, may work well or not at all. What library are you going to use or did you make up one? Oct 27 02:01:15 I am asking b/c I only know so much. I have only experience w/ so many libraries and ideas. Oct 27 02:02:26 hgsfn: If you are not completely bored w/ me yet, please look here: https://www.hackster.io/jkridner/beaglebone-blue-220mm-quadcopter-9801d8. Oct 27 02:02:35 ... Oct 27 02:02:41 set_: sorry i am new to BBBlue or the TI chip that is being used in it, i have to figure things out..but how do we know the pwm timing information that is required on the esc/dc motor site Oct 27 02:03:09 hgsfn: the blue has a variety of options... it has four integrated motor drivers as well as 8 digital outputs (3.3v) which can generate pretty much any kind of signal depending on software used Oct 27 02:03:57 (and a whole bunch of other i/o) Oct 27 02:04:46 zmatt: ok but i guess it has limitation on the amount of current it can give to motor?? Oct 27 02:05:02 for the four motor outputs? yeah, it's probably spec'd somewhere Oct 27 02:05:24 zmatt: any available capes to handle the additional current requiements, because i see rc car motors are rated 45 amp etc Oct 27 02:05:39 the blue doesn't support capes Oct 27 02:05:58 but you can use all sorts of external motor drivers/controllers of course Oct 27 02:06:10 as long as they accept 3.3v inputs Oct 27 02:06:16 i meant cape which take power from a seperate battery for the dc motor alone Oct 27 02:06:20 Use the Sabertooth 2 x 12. Oct 27 02:06:27 I found a nice library. Oct 27 02:07:04 a "cape" is a board designed to plug into the two 2x23-pin expansion headers that other beaglebone family boards have Oct 27 02:07:14 the blue doesn't have these headers Oct 27 02:07:22 Or...you can use the MotorCape w/ a BBB or BBBW! Oct 27 02:08:43 hgsfn: Look here please...https://github.com/silver2row/sabertooth. That is my idea of putting the Sabertooth to work w/ the BBGW! Oct 27 02:09:01 I can put in 24v w/ that extension. Oct 27 02:10:09 But specifications...that is something completely different. That takes math. I would have to write stuff down. No! Oct 27 02:10:19 zmatt: ok cape is not the right word, just a addon card as you had explained Oct 27 02:10:26 set_: thanks Oct 27 02:10:31 Yeppers! Oct 27 02:10:44 like I said, it can interface with all sorts of things Oct 27 02:10:59 TI's LaunchPad boards! Oct 27 02:11:00 that sabertooth one is an example (which uses a serial protocol) Oct 27 02:11:13 Yep! Still cool...right? Oct 27 02:11:39 set_: price is not cool.. Oct 27 02:11:59 For launchPad? Oh...sabertooth. I know! Oct 27 02:12:04 Too expensive. Oct 27 02:12:32 $3.00 shipping from their site, though. It is hard to beat. Oct 27 02:13:06 I ordered from another place. They charged S & H to the amount of SH$#! Oct 27 02:13:11 Oh well. Oct 27 02:13:22 Back to the BBBlue and the Launchpads. Oct 27 02:13:39 LaunchPad boards are fairly inexpensive. Oct 27 02:15:24 or those other boards from Arduino. Oct 27 02:15:35 You can attach one of those to your BBBlue if necessary. Oct 27 02:15:58 hgsfn: apparently the integrated motor outputs are "1.2A continuous, 3.2A peak" Oct 27 02:17:38 Or a BBB! Oct 27 02:22:42 set_ & zmatt: thanks looks like i have to figure things out.. Oct 27 02:29:11 oyat **** ENDING LOGGING AT Sat Oct 27 03:00:00 2018