**** BEGIN LOGGING AT Wed Dec 23 02:59:58 2015 Dec 23 03:39:34 ocamlman : not what you asked for but I catch events from the PRU Dec 23 03:40:26 oh, no I don't Dec 23 03:40:29 I just busy wait :p Dec 23 03:40:52 oh - in the other one I do Dec 23 03:40:57 mov r31.b0, 32+PRU1_ARM_INTERRUPT Dec 23 03:41:06 on pru1 Dec 23 03:41:36 in C: prussdrv_pru_wait_event(PRU_EVTOUT_1); Dec 23 03:41:40 that's it Dec 23 06:50:48 CareBear\: hm, ocamlman left but you can use uio to deliver irqs to userspace Dec 23 06:51:19 not really pru-specific, you can get irqs on GPIOs and such too Dec 23 06:51:48 although I think the uio_pruss driver had some specific code related to the pru interrupt controller Dec 23 11:26:51 whats the best way to get the PWM signal up to 5V from the 3.3V coming out? Dec 23 11:28:00 one of the numerous driver/level-shifter ICs found on this earth Dec 23 11:29:00 it matters also what pwm frequency you run on Dec 23 11:30:05 do you really need 5V swing btw? what are you driving? Dec 23 11:31:23 many recipients of a PWM signal (e.g. a fan controller) are fine with 3.3V pwm signal even if they run on higher voltage themselves Dec 23 11:31:28 zmatt: I've got a speed controller for an RC car here. Dec 23 11:31:41 It operates at 5V 1A (output) and the signal is 1 Khz Dec 23 11:31:58 and it doesn't accept a 3.3V input>? Dec 23 11:31:59 I'm seeing the beagle outputting the correct wave, but I dont see any movement on the controller itself Dec 23 11:32:06 hmm Dec 23 11:32:12 https://www.conrad.de/de/modelcraft-207368-carbon-series-fahrtregler-belastbarkeit-60-a-50-a-35-a-motorlimit-20-turns-207368.html Dec 23 11:32:17 ^ its that one Dec 23 11:32:34 Arduino works fine :\ Dec 23 11:32:49 kind of weird, I might write them and ask whether it works with the 3.3v from the beagle Dec 23 11:33:27 you said you're seeing the beagle outputting the correct wave... what voltage does it reach? Dec 23 11:33:42 since if the controller draws significant current you may end up with much less than 3.3V Dec 23 11:34:31 I guess a datasheet is too much to ask for... :P Dec 23 11:35:56 The controller itself is supplying the beagle with 5v 1a Dec 23 11:36:05 its and ESC with a BEC Dec 23 11:41:01 the goal is to make the BBB have the role the receiver would normally have? Dec 23 11:42:01 yes Dec 23 11:42:48 period should be 20ms, duty cycle max 2ms right? Dec 23 11:43:25 I've only once previously worked with a servo, and it had actual specs Dec 23 11:44:11 yeah, mine worked with the arduino servo lib with operates a period of 20ms and duty cycle 1-2.5ms Dec 23 11:46:13 apparently most RC servos care only about pulse duration and not really the interval Dec 23 11:47:04 still no electrical info though... did you check what voltage is reached by the BBB output (when connected to the servo) ? Dec 23 11:47:50 since the current that a BBB output can deliver is quite limited Dec 23 11:47:55 BBB output is max 3.3 Dec 23 11:47:58 got it on the voltmeter here Dec 23 11:48:05 periods are working perfectly fine from the beagle Dec 23 11:48:20 I might give the servo a quick test with the arduino now and then check the beagle with a smaller servo I still have here Dec 23 11:48:43 if it reaches full 3.3V then it ought to be fine... Dec 23 11:50:32 the ESC is also supposed to make a weird sound (do re mi) when being connected to a steady PWM Dec 23 11:50:38 I'll check the components again Dec 23 11:52:26 Hell yeah! It's working now! Dec 23 11:52:33 Had the wheels turning! Dec 23 11:52:44 apparently 1.1-1.9 ms is "100% ATV" Dec 23 11:52:46 for JR Dec 23 11:52:49 according for some site Dec 23 11:53:15 with "150% ATV" (0.9-2.1 ms) the max Dec 23 11:53:30 Seems the ESC/BEC needs to be connected to the BBB first, then before any other output it needs 1.5ms duty at 20ms period and gives the strange tone Dec 23 11:53:33 then its operational Dec 23 11:53:47 :D Dec 23 11:53:56 Now, I need to solder the stuff :D Dec 23 11:54:06 So the 3.3v are absolutely sufficient Dec 23 11:54:13 it seems. Dec 23 11:54:45 yeah no surprise there Dec 23 11:56:00 The beagle already has 3G, GPS and camera on it working. Dec 23 11:56:23 We'll see how long the 4600mAh nimh can support the motors, beagle and usb hub :D Dec 23 11:56:29 I hope its more than 10 minutes :D Dec 23 11:56:56 * zmatt is afk Dec 23 11:58:38 derjanni: Why not a separate power source for the motors? Dec 23 12:25:27 Defiant: that's what the ESC with integrated BEC are doing. I don't want to run a SYS battery and a Motor battery. Dec 23 12:25:43 Defiant: I'd rather smash two batteries in Dec 23 12:26:09 BECs are delivering constant 5V 1A beside pushing the motors up to 20A Dec 23 12:26:38 Anyhow, thanks everybody. I'll get it all soldered onto the wires now. Dec 23 12:26:53 Any issues with the BBB and vibration in general? Dec 23 14:43:40 derjanni, well, its not designed for it .. :) Dec 23 14:56:09 derjanni: ask me again in a few months or so... given that they're going to end up in these... https://dutchdutch.com/professional/pro-fidelity-s18c Dec 23 14:56:12 ;) Dec 23 14:57:12 ethernet audio!? wtf's that? and where does the Beagle fit in ... :p Dec 23 14:57:28 bbl, train to catch Dec 23 15:00:46 zmatt: http://i.imgur.com/vksMXdv.jpg Dec 23 15:01:39 zmatt: http://i.imgur.com/npLNHf0.jpg Dec 23 15:27:37 rcn-ee: btw, I noticed the -bone kernels as of 4.4-rc6-bone0 still have broken lcdc pclk calculation... Dec 23 15:30:27 stt_michael: actually audio-over-ethernet is still wishful thinking :P the bbb is currently mainly for supervisory tasks, programming the dsp, providing (web-)management, etc Dec 23 15:32:32 rcn-ee: is 4.4-ti stable-ish btw or should I really stick to 4.1 ? ... it's a bit annoying there's such a big jump with nothing inbetween... Dec 23 15:35:33 zmatt, there is a 4.4-ti (it's not much different then the bone 4.4-rc at this point) Dec 23 15:36:03 http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.4.y Dec 23 15:36:23 oh crap, it's not like 4.1-ti ... Dec 23 15:36:48 meh, I don't want to be stuck at 4.1 Dec 23 15:37:02 well, things seem to be frozen at ti, for an sdk release.. Dec 23 15:37:13 i'd expect them to switch to 4.4 after linus releases it.. Dec 23 15:37:35 need to switch trains, back online in 45 mins or so Dec 23 15:37:39 bbl Dec 23 15:40:02 I really haven't looked much, what differs the ti patchset? Dec 23 15:41:33 Spidler, for the black, not much, and most i cherry picked to the bone series.. Dec 23 15:42:11 but it's supported by ti. ;) so we can bug someone on bugs directly. ;) Dec 23 15:42:23 That's always nice! Dec 23 15:43:21 Which reminds me that I should look up what this bloody error message is. Dec 23 15:43:29 [Dec23 12:40] musb_ep_program 896: broken !rx_reinit, ep2 csr 0003 Dec 23 15:43:30 [Dec23 13:04] musb_host_rx 1762: Rx interrupt with no errors or packet! Dec 23 15:43:30 [Dec23 15:30] musb_host_rx 1762: Rx interrupt with no errors or packet! Dec 23 15:43:39 And so on and so forth. *sigh* Dec 23 15:43:56 Spidler, what kernel? uname -r Dec 23 15:44:28 4.1.13-bone16 Dec 23 15:45:43 hum... you've swapped the usb cable? (musb patches have been quiet, not much in 4.1-ti's vs mainline 4.1.x) Dec 23 15:46:12 and your using the 5volt dc jack right? Dec 23 15:46:23 Not recently, the machine isn't accessible. And yes, powered over 5 volt Dec 23 15:47:18 Got the same problem on a machine nearby though, exact same setup Dec 23 15:47:26 So I can swap the cable and see if that fixes it here. Dec 23 15:47:34 what usb device do you have plugged in? Dec 23 15:50:35 an ftdi usb to serial Dec 23 15:51:14 Replaced the cabling in the one I have here to a different brand, time to wait a few days and see if it happens again Dec 23 15:51:25 how to build a proper rootfs for bbb, for example using buildroot? I have built one, and got it booting with fresh kernel and u-boot, but I serial is renamed to ttyS0 instead of ttyO0, and probably some other things are not working too, because apperantly the custom dtb's are not getting loaded Dec 23 15:52:33 Spidler, how many ftdi chips (seems common to musb) which ones, and how many: lsusb -t Dec 23 15:52:36 serial is now back to S0 Dec 23 15:52:41 in latest kernels Dec 23 15:52:42 afaik Dec 23 15:52:43 I want to boot over nfs and do some sily kernel stuff, do I even need that funcionality? Dec 23 15:52:58 I would recommend a serial Dec 23 15:53:02 always for kernel work Dec 23 15:53:13 rcn-ee: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M Dec 23 15:53:14 all you need it a $2 FTDI or clone Dec 23 15:53:41 janisg, "custom overlays' are out side of the kernel in 4.1.x.. https://github.com/beagleboard/bb.org-overlays Dec 23 15:53:51 av500: I got fresh bb shipped from farnell and the image loaded on it uses ttyO0 Dec 23 15:53:59 that's because of old image? Dec 23 15:54:09 janisg, that's 3.8.. and back then it was that default.. Dec 23 15:54:20 oh :> Dec 23 15:54:26 janisg: yes Dec 23 15:54:31 TI cannot decide what to use :) Dec 23 15:54:40 S->O->S Dec 23 15:54:41 SOS Dec 23 15:55:05 rcn-ee: If not using the overlays, what functionality I'll be missing? Dec 23 15:55:08 Spidler, similar situation, no answer yet.. http://www.spinics.net/lists/linux-omap/msg121053.html Dec 23 15:55:39 janisg, it's the other way.. i need this "functionality", what "overlay" do i load? ;) Dec 23 15:55:54 rcn-ee: Yea, I found that too. And dug up the messages. I'm seeing it on several board with same hardware, but not on all of them. Dec 23 15:56:25 it looks even starting to debug it with printk's made the problem go away.. oh fun. ;) Dec 23 15:57:05 The bestest-est-est kind of problems Dec 23 15:57:12 how are the overlays loaded? As I understand then cape manager does it? Dec 23 15:57:39 rcn-ee: if you have any ideas, I'm all ears. Otherwise, I'm going back to some last-minute debugging before christmas eve. Dec 23 15:57:47 janisg, bone_capemanager loads them based on i2c-eeprom, bootargs, either from /lib/firmware or the initrd Dec 23 15:59:22 rcn-ee: no additional config setup is required for that? and how do I test if they get loaded? Dec 23 15:59:48 janisg, dmesg | grep bone Dec 23 16:00:50 so pricey compared to pi Dec 23 16:01:32 :> Dec 23 16:02:16 :'( Dec 23 16:02:21 rootsudo, they have to be cheap, as it can't compete with the pru's gpio. ;) Dec 23 16:02:24 rootsudo: then dont buy it Dec 23 16:03:35 rcn-ee++ Dec 23 16:04:02 rcn-ee: this is what I get with rootfs - http://pastebin.com/ushdM6mE Dec 23 16:04:57 janisg, it looks fine.. what are you actually expecting, or what do you want it to load? Dec 23 16:07:04 well for the factory image I got this : http://pastebin.com/p3XM1dxx Dec 23 16:07:31 that's because of some slot configuration? Dec 23 16:08:16 janisg, the mmc subsystem bombs as on overlay in 4.1, and didn't care to move the hdmi/hdmi-audio out of the default *.dtb... Dec 23 16:08:43 janisg, for lcd users, we have an 'overlay' dtb with eMMC/hdmi disabled... towards bottom of: https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md Dec 23 16:10:05 and audio is broken as an overlay... thus the only way to get hdmi-audio working was in it's default *.dtb configruation . ;) Dec 23 16:11:03 it's funny that the comment says HDMI(Audio/Video) but the .dtb says emmc. (grin) Dec 23 16:11:32 rcn-ee: thnks Dec 23 16:11:40 Ragnorok, it's inverted. ;) i blame machinekit's config-io, i mirrored their naming.. (un-convention)... Dec 23 16:11:47 lol Dec 23 16:12:13 So emmc will keep that but disable HDMI, etc? Dec 23 16:12:39 Ragnorok, correct. ;) Dec 23 16:12:53 Aha! Thanks! Dec 23 16:13:25 * Ragnorok has been reluctant to mess around in uEnv all willy-nilly Dec 23 16:13:32 for most capes, there's 3 subsystems that can get in the way, eMMC, hdmi (video+audio) and ndmi (video).. so the naming just leaves that on system eanbled.. (i wasn't upto the e! combinations).. Dec 23 19:20:01 Hello! Dec 23 19:21:02 I'm new with BBB and start developing software for it. I want to know where to find the cross-toolchain that can be installed on CentOS or Windows. Dec 23 19:21:31 rcn-ee: whoops, failed a bit in the getting online again part Dec 23 19:21:48 Especially the sysroot that should include some major libraries like Qt,boost... Dec 23 19:21:56 rcn-ee: my main concern is that the lcdc fixes present in 4.1-ti somehow still haven't found their way upstream apparently Dec 23 19:22:17 zmatt, yeah, there was a rfc on that.. Dec 23 19:22:20 even though the old code had about 50% chance of working for any particular pixel clock rate Dec 23 19:23:29 searching... Tomi took some, but wanted changes on others.. Dec 23 19:25:20 meanwhile we're at 4.4 and still have very broken clock calculation Dec 23 19:26:38 don't get me wrong, the whole code could use much more cleanup (see also the experimental branch https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=ti/lcdc-fixing-4.1 ) Dec 23 19:26:49 but fixing the clock calculation was iirc pretty much a one-liner Dec 23 19:27:40 zmatt, like: http://www.spinics.net/lists/dri-devel/msg96919.html Dec 23 19:28:21 http://www.spinics.net/lists/dri-devel/msg96959.html Dec 23 19:28:55 rcn-ee: it's a rather unclean patch Dec 23 19:29:05 the essential change is Dec 23 19:29:09 - div = lcd_clk / (crtc->mode.clock * 1000); Dec 23 19:29:15 + div = 2; Dec 23 19:29:39 but he renamed it clkdiv for some reason Dec 23 19:29:51 and combined with misc other changes Dec 23 19:30:18 yeap, usually ti quality, change/rewrite all in one patch .;) Dec 23 19:30:48 looks like none of them have hit tomi's for-next branch.. Dec 23 19:31:14 well it also seems to me that if priv->clk and priv->disp_clk are the same then merging them makes sense (this is assuming for a moment they are they same, but they seem to be) Dec 23 19:31:38 well, assuming default muxing Dec 23 19:31:42 gotta bring my bbb in here, check out some rs485 patches ... Dec 23 19:32:29 rcn-ee: it's a pretty essential fix, and my screen wouldn't even work without it Dec 23 19:33:11 without it, due to rounding, div may end up set to 1 Dec 23 19:33:40 which is not a good substitute for 1.999 Dec 23 19:34:41 the code already uses clk_set_rate to desired_pclk * 2 Dec 23 19:35:11 do then doing div = clk_get_rate() / desired_pclk is bogus Dec 23 19:35:16 the answer is 2 Dec 23 19:35:23 up to rounding error Dec 23 19:37:43 there are deeper problems in that whole driver, but this one is low-hanging fruit :P Dec 23 19:39:12 zmatt do you have a diff laying around.. i'm pushing a few other patches today.. Dec 23 19:39:28 not a clean one no, I'm just using the 4.1-ti branch atm Dec 23 19:40:05 git diff ./drivers/.. | pastebinit is clean enough. ;) Dec 23 19:40:30 * zmatt has a bit too much things going on at the same time right now Dec 23 19:41:44 yeap, last minute stuff before everyone disapperas for holidays. ;) Dec 23 19:43:08 get to it :p lol Dec 23 19:43:19 bugger .. missing soldering iron :\ Dec 23 19:44:42 stt_michael, i think we finally get rs485 on 8250_omap: https://lkml.org/lkml/2015/12/21/378 Dec 23 19:52:06 what was wrong again with the omap-serial driver? Dec 23 19:54:37 everything it did over 8250, (in 2.6.32) the 8250 has since implemented genericly... Dec 23 19:55:25 rcn-ee, you What?! lol Dec 23 19:56:32 ah so that was the full implementation of 485 via 8250 with the omap variations .. yes, that was what I thought would eventualyl happen Dec 23 19:57:00 rcn-ee: the 8250 driver is otoh a crawling horror that no sane person would touch since it's used in so many variants on so many platforms that whatever change you make probably breaks something for someone Dec 23 19:57:40 oh shup zmatt Dec 23 19:57:52 half the kernel (if you look closely) is a complete *** of *** Dec 23 19:57:53 lol Dec 23 19:58:02 * zmatt shrugs Dec 23 19:58:06 if it works .. lets just be happy lol Dec 23 19:58:16 if I ever need it for any serious application I'd use it directly from userspace anyway Dec 23 19:58:25 find your patch for rcn-ee lol Dec 23 19:58:52 rcn-ee, any sign of that orange-pi yet?! wanna get mainline uboot flying on it .. and a good kernel .. hehe Dec 23 20:00:03 rcn-ee, did those patches actually get comitted? Dec 23 20:00:58 stt_michael, rs285 set, no compaintes on r6, hopefully they do. ;) Dec 23 20:01:24 I'll apply then test here when it does Dec 23 20:01:37 its only a matter of checking TXEN timing vs data Dec 23 20:01:48 stt_michael, the h3 u-boot support still looks funny, looks like smp support is interesting.. Dec 23 20:03:12 rcn-ee, it Is :) Dec 23 20:04:08 stt_michael, everything is so blackbox/undocumented. ;) Dec 23 20:04:38 yeah like well .. we ain't seen that before .. Dec 23 20:07:34 ok time to GTFO .. back in a bit Dec 23 20:51:13 Does anyone know what the default username/password is for fresh ubuntu 14.04.3 installations? I thought it was supposed to be ubuntu/temppwd but that is not working. Dec 23 20:53:28 ah, nevermind Dec 23 20:53:34 i sorted it out Dec 23 21:44:51 * GenTooMan brushes the bits off the floor. Dec 23 21:59:09 Hello in there, not sure if I am in the right place but I am having trouble connecting to my beaglebone black. 192.168.7.2 shows nothing in browser and can't be pinged. The board does show up as a USB device though. Dec 23 21:59:40 brian-the-lame, did you reflash it? Dec 23 22:00:54 I have not reflashed it, haven't done anything to it yet. Dec 23 22:01:39 brian-the-lame, is your desktop pc running: linux, windows, mac ? Dec 23 22:02:08 Ubuntu 15.10 Dec 23 22:02:38 brian-the-lame, : sudo ifconfig -a ; #look at interfaces, ; sudo eth dhclient Dec 23 22:03:51 hmm I have no eth interfaces Dec 23 22:04:49 I have an enp0s25 and enx84eb18989a74 interface showing up as well as local and wireless connections Dec 23 22:05:21 brian-the-lame, the "enx84eb18989a74" Dec 23 22:08:08 what should I do with the enx84eb18989a74? sorry Dec 23 22:10:27 do "sudo dhclient enx84eb18989a74" Dec 23 22:11:55 felon-: oh wow I seem to have got things working. under my network config I had a wired connection set up with enp0s25, under the drop down I could select enx84eb18989a74.. so I did.. and now it all seems to be working! Dec 23 22:12:11 thank rcn-ee Dec 23 22:12:13 :D Dec 23 22:12:33 i just happened to check my pc atm Dec 23 22:12:41 thank you rcn-ee! Dec 23 22:12:42 and saw you were waiting for a response Dec 23 22:12:51 Just needed some one to point me in the right direction :) Dec 23 22:13:06 i had a very similar issue when i first got my bbb :) Dec 23 22:13:15 i was like wtf! Dec 23 22:13:29 nice case of interface naming there Dec 23 22:13:45 haha yea cryptic isn't it? Dec 23 22:13:45 felon-: yea exactly! all my searching basicly showed up people saying "Just go to 192.168.7.2 and it'll work"... so finally ended up here Dec 23 22:13:58 brian-the-lame: all good :) Dec 23 22:14:07 usb gadget is a picky beast Dec 23 22:14:18 like woman Dec 23 22:14:21 brian-the-lame, pre-systemd it would show up as ethX and network-manager would auto dhcp.. but systemd naming makes it fun.. Dec 23 22:14:25 worse... Dec 23 22:14:44 brian-the-lame, and unless you have the 'latest' image that enxXYZ changes... Dec 23 22:15:42 rcn-ee .. dynamic mac address? Dec 23 22:16:59 Have to run, have a christmas coffee date to attend! Only just got the BBB and today is my first day off work in a while so thought it was a good morning to plug in and have a poke around... glad I got to this point before having to head out! Dec 23 22:17:43 thanks again. I have no doubt I'll end up back here in the future... Dec 23 22:20:28 have fun Dec 23 22:25:29 not a coffee person but tea yes. Dec 23 22:40:03 Can someone tell me where I can find the operating temperature spec on the Beagle Bone black? Dec 23 22:45:41 Guest67078: operating temps are part specific, which is why the BBB has a range of approximately -10C to 70C Dec 23 22:46:03 Guest67078: but if you swap out some parts, you can get it down to -20C I believe Dec 23 22:58:54 wmat .. that's heading towards industrial temp range, rathern than commercial :) Dec 23 23:05:15 the bigger point is that it varies. Variables such as whether there's a cape, if it's enclosed, etc. etc. Dec 23 23:05:25 also, the Element14 clones are different Dec 23 23:05:29 wmat.. indeed. Dec 23 23:07:00 special computing has a BBB listed at -40C to 85C with some modifications for industrial use Dec 23 23:07:23 I thought I'd seen an "industrial" variant somewhere.... though I thought it mighta been ele14 Dec 23 23:07:34 https://specialcomp.com/beaglebone/ Dec 23 23:48:21 I need to verify my understanding: If I edit uenv.txt on my beaglebone black by connecting it to my PC, and the SD card is in the black, then uEnv.txt will be ignored if I do not hold down the boot button, because uboot is loading from emmc Dec 23 23:59:42 Anyone know the answer to uboot questions? Dec 24 00:07:38 just ask.. Dec 24 00:13:42 bminuk yes you must hold the boot button down w/ power for it to boot off the sdhc card, if no boot button it boots the emmc Dec 24 00:14:10 if i remember correctly. Dec 24 00:16:04 it depends which uEnv.txt he was referring to.. nothing stopping you editing the one on the emmc via ssh/terminal/serial/etc Dec 24 00:17:18 technically its the chip that's deciding where to boot from .. it hasn't Got to uboot yet :) but its all academic.. couldn't be bothered to wait for an answer Dec 24 01:11:52 it would be useful to have a good overview Dec 24 01:12:31 especially the afwul cross-boot scenarios where you could get an u-boot + kernel from mmc but rootfs from sd Dec 24 01:15:18 zmatt.. yea there are some crazy combinations Dec 24 01:18:03 the BBB SDRAM is x16 correct? Dec 24 01:25:39 yes Dec 24 01:25:55 single chip, single rank, everything point-to-point Dec 24 01:26:07 easiest scenario possible Dec 24 01:27:41 it's also why it doesn't need a VTT rail Dec 24 01:38:45 i am trying since hours to find a reliable example on how to configure pruss r30 pins through a device tree overlay on kernel 4.1 bb, any idea where to look Dec 24 01:44:21 tat: http://www.ofitselfso.com/BeagleNotes/UsingDeviceTreesToConfigurePRUIOPins.php Dec 24 01:46:15 tat: http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#dtogenerator **** ENDING LOGGING AT Thu Dec 24 02:59:59 2015