**** BEGIN LOGGING AT Mon Jan 19 02:59:58 2015 Jan 19 03:49:09 Hiya, I'm new to Beaglebone, I was trying to setup the VNC like shown on a number of websites, but when I try to run opkg it's not found. Jan 19 04:26:22 I would believe there is a number of sites telling you what to do, but I would not have access to that very data.. Jan 19 04:26:53 So telling what you actually did and what problems you have, would probably e a better experience :) Jan 19 05:16:42 lo. what is the http serv running on port 80 by default on the BBB? netstat just lists it as systemd Jan 19 08:55:44 hi Jan 19 08:56:18 lo Jan 19 09:25:00 hiz Jan 19 09:25:15 nc Jan 19 10:36:45 hi Jan 19 13:40:19 I get watchdog soft lock ups using 3.19.0-rc4-bone2 Jan 19 13:46:01 kernel:[ 8180.571889] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:0:6657] Jan 19 13:55:07 my beaglebone does not put output anything to any of the headers, including GPIO and the normal 5v, 3.3v and gnd lines. anyone know why this might be? Jan 19 13:55:15 it shipped like this. Jan 19 14:18:16 where should I report BBB kernel bug? Jan 19 14:20:09 even at really low frame rate the camera capes i mentioned yesterday are pretty disapointing Jan 19 14:20:42 i don't care about frame rate but the latency sucks. and the fact that they won't ever be popular us a minus too Jan 19 14:21:05 av500: here? Jan 19 14:22:14 jo Jan 19 14:22:56 was up? Jan 19 14:23:26 maybe you have a clue as to what to do Jan 19 14:24:13 bug report? Jan 19 14:24:18 send to the mailing list Jan 19 14:24:29 right, which one? Jan 19 14:25:14 o ok I see its a known cpufreq issue Jan 19 15:33:56 hello. i can program, but what would be a good start for a newbie into this device as i need to learn basic digital electronics. how volts and amps all work together, etc ? Jan 19 15:37:53 google? Jan 19 15:37:59 a book on electronics? Jan 19 15:40:14 an arduino might be a good stepping stone to be honest Jan 19 15:40:45 imho it doesnt really matter if u use an arduino or just that node-js thingy provided by bb ... Jan 19 15:41:18 bb is fried easier than an arduino, though Jan 19 15:42:19 yes but arduino has a lot of support and there are a lot of example projects that are almost pure electronics Jan 19 15:42:44 plus yeah arduino is harder to fry and also less costly to fry Jan 19 15:47:30 cityoflights2: http://github.com/beagleboard/linux or http://beagleboard.org/discuss Jan 19 15:47:49 10x Jan 19 15:53:10 well, i was wanting to play with Mono as well on it and eventually use it like a device with a touchscreen. but if u think audrino is the way to go first (as more project for 'electronics, and I may fry the Beagle, then that is probably what i should do first. Jan 19 15:53:41 you can certainly jump in with BBB and there's tutorials etc Jan 19 15:53:43 (and a bit chaper) Jan 19 15:54:17 well. an arduino made in china will cost u lke 5 bucks. u could just give it a try Jan 19 15:54:52 just personally i feel that arduino project tutorials are more likely to give insight to fundamental electronics Jan 19 15:55:26 however the hobby projects i envisage myself doing (down the track) will want more power as Ive heard of people reaching the limit of audrion (however they seem to be experianced in the field) Jan 19 15:55:59 well. if u really need more power than arduino you _will_ be able to use a bb Jan 19 15:56:15 johnwalkr, yes i do need a more fundamental understanding of electronics first. Jan 19 15:56:24 i tend to agree with johnwalkr ... arduinos are def a good start. Jan 19 15:58:36 Hell everyone, what are the project focuses for gsoc 2015 Jan 19 15:58:48 sorry* i mean hello Jan 19 16:03:09 udara28: "rename beaglebone to beägleböne for increased heavymetalness!" Jan 19 16:08:02 why is it, that when I'm pulling (git) from https://github.com/beagleboard/linux I *always* get conflicts? Jan 19 16:08:34 I'll run a git fetch every couple of days, and then pull into my local branch and it inevitably bombs out with a million merge conflicts Jan 19 16:09:34 I always end up having to run fetch to get all the changes Jan 19 16:10:11 then create a temporary branch tracking origin/3.14, drop my local 3.14 branch, then rename my temorary branch back to 3.14 Jan 19 16:10:46 it is seriously a pain in the ass, and I have no clue how the git history is getting so screwed up in that repo, such that you can't simply pull Jan 19 16:11:11 does anyone else have this pain? Jan 19 16:13:12 pull --rebase? Jan 19 16:13:23 do you have your own commits? Jan 19 16:13:38 av500, none Jan 19 16:14:14 I'll give a rebase a shot next time I fetch Jan 19 16:16:15 what branch? Jan 19 16:18:54 av500, 3.14 Jan 19 16:19:40 I'm copying my (lengthy) conflict output. I get similar issues every time I attempt to pull from 3.14 Jan 19 16:19:58 and again, no local commits. Jan 19 16:21:28 KaaK_: that tree is rebased constantly. Jan 19 16:23:13 jkridner, what is the benefit of that workflow? It just makes tracking its changes a huge headache and unclear (IMO) Jan 19 16:23:54 generally, it brings in bug fixes from the stable tree. Jan 19 16:24:08 we re-apply the patches on top of what is going in upstream. Jan 19 16:24:28 it makes sure you can tell what the deltas are from upstream. Jan 19 16:24:49 jkridner, I see Jan 19 16:40:27 jkridner, av500: https://dl.dropboxusercontent.com/u/44252060/conflicts Jan 19 16:40:45 an example of what happens when I pull Jan 19 16:42:34 KaaK_: if you don't have local patches, why not just switch to the new branch? Jan 19 16:42:58 KaaK_: if you do have local patches, you should switch to the new branch and merge/cherry-pick them onto the new branch. Jan 19 16:44:17 honestly, probably mostly due to my ignorance with git. I usually just fetch, re-track the remove 3.14 as `3.14-tmp`, then delete my local 3.14, and rename `3.14-tmp` back to 3.14 Jan 19 16:44:37 s/remove/remote/g Jan 19 17:42:21 mosfets are charge-switched, aren't they? Jan 19 17:42:42 so there shouldn't be much current flowing through the gate Jan 19 17:50:18 KaaK_: git reset origin/3.14 --hard Jan 19 17:50:51 KaaK_: will reset your local tree to be inline with the upstream 3.14; just make sure you don't have any commits locally that you want to keep Jan 19 18:12:54 hello Jan 19 18:29:46 jackmitchell, thanks! Jan 19 19:24:22 hello - is there a way I can access system time from the PRU? Jan 19 20:25:40 rcn-ee! Jan 19 20:26:40 remember I ask so many questions about 3.19 gpio ? Jan 19 20:26:54 well, I posted this guide for the rest of us: https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/IAkyHQOp8VA Jan 19 20:27:45 so I just wanted to thank you, for your help Jan 19 20:37:18 perhaps I am misunderstanding the SD boot switch, but my BBB will continue to boot from SD even when I am not holding the SD boot switch. Jan 19 20:37:25 what would cause that? Jan 19 20:38:53 defalt bootloader behaviour Ithinkkkkkkk.. for some configs.. is to check the uSD first regardless Jan 19 20:45:19 I've got the SRM, and it says differently in figure 36. MMC0 (uSD) is in both boot sequences, but the non-SD boot sequence absolutly has MMC1 (eMMC) ahead of SD Jan 19 20:46:23 KaaK_, on power up eMMC is first.. But u-boot checks microSD first to see if it's a valid boot option before moving on to eMMC.. Jan 19 20:50:54 tc rcn-ee .. as I suspected :) Jan 19 20:51:00 its a patch to uboot iirc ;P Jan 19 20:54:55 rcn-ee, that answers that, thanks! Jan 19 20:55:50 KaaK_, it's a big complex/convoluted mess, to ensure a lot of 3rd party images boot reliably. ;) Jan 19 20:57:25 rcn .. is there a way of overriding that without re-programming uboot? Jan 19 20:57:33 is it the uboot script or .. ? Jan 19 20:58:15 veremit, it looks for 4 different scripts: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#Boot_Partition_.28omap4.2B_.28am335x.29.29 (in many partitions) Jan 19 20:59:06 yikes Jan 19 20:59:16 it's also pretty vocal, it'll give you a hint on what path it's taking.. Jan 19 21:00:40 yeah but you can easily get into knots with mmcblk0/1 :p Jan 19 21:00:49 I have .. regularly :) Jan 19 21:01:06 that's when fdisk seems to come in handy Jan 19 21:01:27 yeap... just wish uuid's could be used in mainline kernel without an initramfs... Jan 19 21:01:45 think there's some way to go before that happens Jan 19 21:01:49 Or the mmc guys would let us hard code the mmc name based on the mmc port.. Jan 19 21:01:57 (dt guys) Jan 19 21:01:58 I wanna get uuids working for usb boot Jan 19 21:02:14 but thats initramfs territory too Jan 19 21:02:25 (not on the beagle, btw) Jan 19 21:02:26 ahh, that explains the initramfs Jan 19 21:02:43 veremit, well you can use the gpt uuid label.. Jan 19 21:02:58 (doesn't work on msdos formated partitions) Jan 19 21:04:18 yeah dont' get me started on gpt .. and it doesn't play so nice with grub1 .. one thing at a time .. :p Jan 19 21:04:25 u-boot has support for it now: http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=5b782e3f4ca8784c6439d5ca5b620ad6ec073e51 Jan 19 21:04:41 although I will get around to grub2 properly for multi-boot some day soon .. WITH initramfs Jan 19 21:05:09 rcn-ee, do you see any way to reconcile the the arch/arm/boot/dts/* situation? Even if it was a simple doc explaining it, it would make wrapping my head around much easier. Jan 19 21:05:18 I just wonder why the kernel can't decode uuid's, haven't found anyone say no to it... Nor anyone adding a patch for it.. Jan 19 21:06:01 KaaK_, that's the future.. at some point, it'll be external firmware... (and no longer in the kernel.org tree) Jan 19 21:06:02 its tied into udev atm.. which i suspect is a bit of a bodge Jan 19 21:06:25 so was kernel firmware loading.. :) not anymore... Jan 19 21:06:35 I guess it means moving some stuff around Jan 19 21:07:35 where to report a kernel crash for 3.19.0-rc2-bone2 ? Jan 19 21:07:56 is there migration away from dt in ARM? Jan 19 21:07:58 does it also happen on rc5? should be in the repo right now.. Jan 19 21:08:12 KaaK_, oh we migrated from board files to dt... Jan 19 21:08:47 rcn-ee, you mentioned external firmware -- is that not partially what dt servers? Jan 19 21:09:02 KaaK_, dt = fimware. ;) Jan 19 21:09:12 device tree 'blob" dtb... Jan 19 21:09:26 external firmware as in not a data structure. I know alot of people don't like the data-only DT approach for shitty hardware :) Jan 19 21:09:56 min Jan 19 21:10:36 KaaK_, on arm64, they are talking about acpi... I'll take dt any day. ;) Jan 19 21:11:37 yikes acpi ew Jan 19 21:13:04 heh, my only probably with DT in the github linux repo is how convoluted it is. The capes add alot of noise ... Jan 19 21:14:09 as opposed to the mainline repo -- its much easier to grok without the huge chains of includes Jan 19 21:15:06 any plans to incorporate the dynamic DT overlays that made into the mainline? I feel like they'd help separate the base DT with the different capes (IMO) Jan 19 21:15:25 The #include setup in 3.14.x is just for my sanity, there's lots of repeat structures. Jan 19 21:16:17 yeah, there is alot of duplication :( Jan 19 21:16:31 KaaK_, it "finally" hit as of v3.19-rcX.. pantelis went thru more re-writes then probally anyone still sane could.. Jan 19 21:17:16 I went through the logs on it (in anticipation) and there is a ton of work there Jan 19 21:17:48 well, I lost connection t the BBB. just power cycled it Jan 19 21:18:42 I'm hopeful I will be able to maintain much of my DT needs outside of the kernel trees, and keep them closer to the hardware they belong to Jan 19 21:19:19 Jan 19 22:48:18 osbo2 kernel: Modules linked in: binfmt_misc ctr ccm usb_f_acm u_serial g_serial libcomposite arc4 ath9k_htc ath9k_common ath9k_hw ath mac80211 cfg80211 omap_sham omap_aes Jan 19 21:19:23 KaaK_, just fork this project, https://github.com/RobertCNelson/dtb-rebuilder Jan 19 21:20:07 http://nopaste.info/fc2e7b625c.html Jan 19 21:20:51 KaaK_ see the link I posted above, for using the dtb-rebuilder Jan 19 21:21:30 It hooked me at `It is synced regularly with mainline Linux.` Jan 19 21:21:59 I've found the DT source much more straight forward there. Jan 19 21:22:11 Its not completly fair, because they don't deal with capes Jan 19 21:22:20 KaaK_, well the one that's auto-synced is this one: https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ Jan 19 21:22:26 yep, and now poll() on a GPIO works, it stopped working in 3.8 Jan 19 21:22:34 (it's also got all *.dtb options for every target..) Jan 19 21:28:07 cityLights, that looks like the general omap-IRQ problem discussed on linux-omap, no solution has hit mainline quite yet... Jan 19 22:58:40 How do I enable a timer from c on the ARM to cause interrupts on the ARM? Jan 19 23:08:59 rcn-ee : this crash didn't happen in 3.8 and it actually freezes the BBB Jan 19 23:09:10 when is rc5 due? Jan 19 23:09:37 cityLights, it's being built right now.. http://rcn-ee.homeip.net:81/farm/deb/?C=M;O=D Jan 19 23:09:40 also, I had some issue with rsyslog used in the debian 8.0 image you provide Jan 19 23:10:21 I notice that rc4 has no news for BBB users Jan 19 23:10:37 cityLights: are you monitoring the console, and do you have kernel debugging enabled? Jan 19 23:11:23 thurgood_ I am monitoring the console, how to turn kernel debugging on? Jan 19 23:11:25 sometimes the stack traces it spits on panic can be helpful Jan 19 23:11:33 cityLights, sudo apt-get update ; sudo apt-get install linux-image-3.19-rc5-bone2 should work.. if it doesn't it just hasn't been synced out to repos.rcn-ee.net yet.. Jan 19 23:12:47 cityLights, ah, it's working on 3.18.3 first, rc5 will begin after that... Jan 19 23:12:56 you need to grab the kernel sources and make menuconfig to modify the kernel settings if it's not already set Jan 19 23:13:37 aha, well, I rather not get to building the kernel now Jan 19 23:14:12 by the way what is dcan1 ? a counter? Jan 19 23:14:13 ok Jan 19 23:14:25 can bus Jan 19 23:18:17 rcn: my ubuntu image with kernel 3.8.13-bone62 has /dev/i2c-1 Jan 19 23:18:43 on the debian 8.0 with kernel 3.19-rc4 I only see /dev/i2c-1 Jan 19 23:18:46 on the debian 8.0 with kernel 3.19-rc4 I only see /dev/i2c-0 Jan 19 23:19:02 how to add i2c-1 to 3.19 ? Jan 19 23:25:53 that's the cape bus, i need to add that to v3.19, it's not enabled yet by default. Jan 19 23:26:47 well, love to hear when its in and I can use it Jan 19 23:27:00 its suppose to be a simple dtsi, right? Jan 19 23:51:27 good night Jan 20 02:49:47 hello - how can I enable a timer (say, 1ms) as an interupt on the ARM processor? Jan 20 02:52:25 what is it for? Jan 20 02:52:34 a driver? Jan 20 02:53:05 a userspace irq handler to timestamp data with sub-ms accuracy Jan 20 02:53:26 the kernel already has sub-ms timestamps available Jan 20 02:53:38 you cannot guarantee that kind of timing in userspace Jan 20 02:53:41 yup Jan 20 02:53:45 move to the kernel Jan 20 02:54:03 irq handler also has a few microseconds (~10us) delay Jan 20 02:54:46 the plan is to use an external clock to trigger an irq which, in userspace, will call clock_gettime and the value of the write pointer of a ring buffer then release. later, that pairing will be logged. Jan 20 02:55:10 maybe you'd be interested in the pps framework Jan 20 02:55:23 just write it in the kernel and be done with Jan 20 02:55:31 it's designed for one pulse per second Jan 20 02:55:33 these userland shannigans are a waste of time. Jan 20 02:55:44 pps-gpio is the kernel module Jan 20 02:56:06 the goal is that every few samples, i get a timestamp associated with one of them. I am collecting data (with the PRU) at >20MHz so I want to timestamp at every 10 ms or so Jan 20 02:56:41 where is the data coming rom? Jan 20 02:56:42 from Jan 20 02:56:47 adc Jan 20 02:57:08 adc->pru->12k shared memory->arm->file Jan 20 02:57:31 *20KHz, sorry Jan 20 02:58:08 you should be able to get ~1ms accuracy by just calling gettimeofday in userland Jan 20 02:58:22 as long as there's no scheduling conflicts Jan 20 02:58:52 getting the timestamp in the kernel would be more accurate Jan 20 02:59:34 I need microsecond at least, which clock_gettime can do, but in between getting the time and getting the write_pointer the kernel could move exection to a different thread and the time I get wouldn't actually correspond with the sample number **** ENDING LOGGING AT Tue Jan 20 02:59:59 2015