**** BEGIN LOGGING AT Sat Apr 16 02:59:58 2016
Apr 16 04:27:28 <yplus> I'm getting ""Network Error: Software Caused Connection Abort" when i do apt-get update. Any idea what could be the issue?
Apr 16 04:30:02 <tbr> how is your BBB connected to the internet?
Apr 16 04:31:48 <yplus> ethernet
Apr 16 04:32:06 <yplus> Logs doesnt seem to say anything
Apr 16 04:32:07 <yplus> http://pastebin.com/kj0TcLm4
Apr 16 04:34:46 <tbr> does that error happen for all servers or only for one particular repository?
Apr 16 04:36:24 <yplus> not all. sometime the apt-get fetches from 95% of repositories and sometimes 15%. I dont think its the problem of internet or the repositories.
Apr 16 04:36:44 <yplus> Infact it shows the same error when I run wicd-curses to setup Wifi
Apr 16 04:37:00 <yplus> I'm wondering it could be a permissions issue.
Apr 16 04:37:11 <yplus> Any idea how to find that out?
Apr 16 04:39:59 <tbr> sounds like unreliable network to me though
Apr 16 04:41:06 <yplus> i have connected beaglebone to win machine over usb. do you think usb drivers could be causing connection problem
Apr 16 04:42:09 <tbr> you said the connection to the internet is via the BBBs ethernet port?
Apr 16 04:43:35 <yplus> yea. i tried usb earlier. was not working. now ethernet. the network here is good. doesn't seem unreliable
Apr 16 04:44:17 <yplus> connection is uninterrupted until i do a run a command
Apr 16 04:44:59 <yplus> but when i run, it says errror
Apr 16 04:45:29 <yplus> is there connection keep alive setting in debian config
Apr 16 13:36:03 <Geof> If a .dtbo file is "built" into the image that I'm running, is there a way to override the dtbo with a new one in /lib/firmware?  It appears that it doesn't load the one I put in /lib/firmware.
Apr 16 13:39:44 <zmatt> there's no such thing as a "built-in dtbo file"
Apr 16 13:41:41 <zmatt> there's just the main dtb from /boot/dtbs and overlays typically loaded from /lib/firmware
Apr 16 13:42:11 <Geof> Hmm...  I have a cape plugged in, and I want to update the dtbo for that cape.  I built it and put the dtbo in /lib/firmware and nothing changed.  I'll look in /boot/dtbs.
Apr 16 13:43:15 <Geof> Ok, not in /boot/dtbs.  I'll keep playing around.
Apr 16 13:43:44 <zmatt> did you reboot?
Apr 16 13:43:50 <Geof> Yes.
Apr 16 13:44:18 <Geof> There may be something still wrong in the dts.  The one you worked with me on works fine.  I'll play and find it.
Apr 16 13:44:37 <zmatt> be sure to also check for errors in the kernel log
Apr 16 13:45:18 <Geof> will do.
Apr 16 13:56:08 <mausy5043> Hi. Trying to get BBB going on the jessie image from beagleboard.org. (Debian 8.3)
Apr 16 13:56:15 <mausy5043> Having some trouble
Apr 16 13:56:44 <mausy5043> Are there any known issues with `nfs-common` package?
Apr 16 13:57:10 <mausy5043> After installing this package I can't get the board booted up again
Apr 16 13:58:38 <mausy5043> It's headless so can't see what *is* going on
Apr 16 13:58:43 <mausy5043> :-(
Apr 16 14:05:02 <Mausy504_> ...
Apr 16 14:18:04 <Mausy504_> any nfs related problem?
Apr 16 14:26:31 <Mausy504_> installing 'nfs-common' added the packages:
Apr 16 14:26:47 <Mausy504_>    libnfsidmap2 (0.25-5)
Apr 16 14:26:47 <Mausy504_>    libtirpc1 (0.2.5-1)
Apr 16 14:26:47 <Mausy504_>    nfs-common (1.2.8-9)
Apr 16 14:26:49 <Mausy504_>    rpcbind (0.2.1-6+deb8u1)
Apr 16 14:28:15 <Mausy504_> after reboot the heart-beat LED is working.
Apr 16 14:28:30 <Mausy504_> all others are off
Apr 16 14:28:51 <Mausy504_> Ethernet LED (green) is flashing
Apr 16 14:31:11 <Mausy504_> On the DNS I can see the BBB releasing its DHCP lease. No signs of it trying to re-acquire an IP-address
Apr 16 14:33:20 <Mausy504_> after the reboot.
Apr 16 14:33:37 <Mausy504_> So, anyone seen any issues with those packages?
Apr 16 14:58:17 <mausy5043> awfully quiet inhere
Apr 16 15:02:57 <tbr> mausy5043: log in through the serial console?
Apr 16 15:03:53 <mausy5043> OK thanks. WIll give it a try
Apr 16 15:28:56 <Mausy5043> logs are here: http://pastebin.com/AwHxGGL4
Apr 16 15:29:16 <Mausy5043> wonder if anyone sees the cause
Apr 16 15:35:13 <tbr> hmmm many network interfaces...
Apr 16 15:53:25 <Mausy504_> yeah but ifconfig only shows usb0 and lo
Apr 16 15:56:19 <Mausy504_> I think I found it.
Apr 16 15:56:38 <Mausy504_> In /etc/network/interfaces the eth0 entry was commented out.
Apr 16 15:56:45 <Mausy504_> is this the default?
Apr 16 16:09:49 <Geof> zmatt: Figured it out.  I was using Nimbelink's NL-AB-BBBC cape and dts file.  They had the version number as 00D0 instead of 00A0.  I'm not sure why, but the system is not very forgiving of a version other than 00A0 from what I can tell.
Apr 16 16:11:37 <toby1> hello
Apr 16 16:11:48 <toby1> i installed openbsd 5.8 on my beaglebone black and it works great
Apr 16 16:12:13 <toby1> compiling fossil now so i can have a source repo on it
Apr 16 16:14:18 <toby1> zmatt, will I be able to force 1080x1920 resolution if I output vga somehow, instead of hdmi?
Apr 16 16:15:34 <zmatt> "output vga somehow" ?
Apr 16 16:16:04 <toby1> yeah, do give it the ol razzle dazzle with some cables and a breadboard
Apr 16 16:16:16 <zmatt> there's no analog video output on the BBB
Apr 16 16:16:34 <ogra_> just boot with vga=somehow on the kernel cmdline ?
Apr 16 16:16:56 <zmatt> your best bet would be a proper HDMI to VGA converter, and then it should work transparently
Apr 16 16:17:10 <zmatt> (i.e. it should correctly detect monitor resolutions supported)
Apr 16 16:17:32 <toby1> check this out https://www.youtube.com/watch?v=miefLPwZgOg
Apr 16 16:17:40 <toby1> someone did it on an attiny85
Apr 16 16:17:52 <toby1> i reckon it probably works on beaglebone
Apr 16 16:18:40 <zmatt> sure you can output vga with some creativity, but unless you make it into a kernel driver the kernel will obviously not know about it or be able to consider it a video output
Apr 16 16:19:27 <toby1> zmatt, but if I do make a kernel driver, will it be able to output hd video at 60 fps? or is there a physical limiatation preventing it?
Apr 16 16:20:10 <zmatt> yes, there's no way in hell you'll manage that kind of resolution
Apr 16 16:20:11 <toby1> i know about the pixel rate and whatnot, but does that apply to output means other than hdmi?
Apr 16 16:20:14 <toby1> oh ok
Apr 16 16:23:46 <zmatt> you might be able to hack something onto the LCD controller signals... like taking the most significant bit of each color component, combine with an appropriate output driver and somehow shoehorn the sync in (after working around the fact LCDC can't actually quite generate VESA-compliant sync signals)
Apr 16 16:24:36 <zmatt> and then you'll have made a very very crappy digital video to VGA converter... you still won't get higher pixel clock rates than LCDC normally gets
Apr 16 16:24:44 <zmatt> :P
Apr 16 16:24:47 <toby1> i understand
Apr 16 16:24:50 <toby1> thanks for the info
Apr 16 16:25:46 <zmatt> lcdc has pretty much the fastest "normal" outputs on the am335x (i.e. not counting things with special drivers like DDR3 or USB)
Apr 16 16:26:48 <mausy5043> OK problem solved. Thanks for listening!
Apr 16 16:29:22 <mausy5043> Next problem:
Apr 16 16:30:02 <mausy5043> what happened to `/sys/devices/bone_capemgr.9/slots`
Apr 16 16:31:04 <zmatt> assuming you have a standard (-bone or -ti) kernel and dtb it should still be there (possibly with a different number instead of "9", that one is arbitrary
Apr 16 16:31:34 <zmatt> there's additionally a new (and arguably cleaner) mechanism for overlays via configfs
Apr 16 16:31:52 <mausy5043> In wheezy I could
Apr 16 16:31:59 <mausy5043> # la /sys/devices/
Apr 16 16:31:59 <mausy5043> total 0
Apr 16 16:31:59 <mausy5043> drwxr-xr-x 10 root root 0 Apr 16 18:29 .
Apr 16 16:32:01 <mausy5043> dr-xr-xr-x 12 root root 0 Apr 16 18:29 ..
Apr 16 16:32:03 <mausy5043> drwxr-xr-x  3 root root 0 Apr 16 18:29 armv7_cortex_a8
Apr 16 16:32:05 <mausy5043> drwxr-xr-x  3 root root 0 Apr 16 18:29 breakpoint
Apr 16 16:32:07 <mausy5043> drwxr-xr-x 17 root root 0 Apr 16 18:29 platform
Apr 16 16:32:09 <mausy5043> drwxr-xr-x  3 root root 0 Apr 16 18:29 soc0
Apr 16 16:32:11 <mausy5043> drwxr-xr-x  3 root root 0 Apr 16 18:29 software
Apr 16 16:32:13 <mausy5043> drwxr-xr-x  6 root root 0 Apr 16 18:29 system
Apr 16 16:32:15 <mausy5043> drwxr-xr-x  3 root root 0 Apr 16 18:29 tracepoint
Apr 16 16:32:17 <zmatt> never copy-paste anything more than 1 or 2 lines
Apr 16 16:32:17 <mausy5043> drwxr-xr-x 15 root root 0 Apr 16 18:29 virtual
Apr 16 16:32:22 <mausy5043> OK
Apr 16 16:32:23 <zmatt> use pastebin or similar sites
Apr 16 16:32:27 <mausy5043> sorry
Apr 16 16:33:08 <zmatt> what kernel and dtb?
Apr 16 16:33:23 <mausy5043> In wheezy I would register my cape with: `echo nocape-w1 > /sys/devices/bone_capemgr.9/slots`
Apr 16 16:33:29 <mausy5043> How do I do this in jessie?
Apr 16 16:34:00 <mausy5043> Linux bbone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 armv7l GNU/Linux
Apr 16 16:34:18 <zmatt> same afaik, or using configfs, both should work
Apr 16 16:34:21 <mausy5043> dtb?
Apr 16 16:34:41 <mausy5043> who do I determine that?
Apr 16 16:34:50 <zmatt> grep '^dtb' /boot/uEnv.txt
Apr 16 16:35:10 <mausy5043> dtb=am335x-boneblack-overlay.dtb
Apr 16 16:36:08 <mausy5043> I want to install a 1-wire dtb that I've just compiled
Apr 16 16:38:37 <zmatt> capemgr should still work as normal, I have no idea why it's not showing for you... did you check /sys/devices/platform/ ?
Apr 16 16:39:02 <zmatt> I don't use it myself so I'm not sure what its normal location is
Apr 16 16:39:50 <mausy5043> Oh yeah it seems to have moved to /s/d/platform
Apr 16 16:39:52 <mausy5043> Duh!
Apr 16 16:39:58 <mausy5043> ;-)
Apr 16 16:42:15 <mausy5043> Hmmm...
Apr 16 16:42:20 <mausy5043> not working
Apr 16 16:45:38 <Geof> Does BBB require version 00A0 for Cape DTS files?  I tried one that used 00D0 and that seemd to be what was causing problems?
Apr 16 16:46:04 <zmatt> it must match the version reported by the CAPE EEPROM
Apr 16 16:48:28 <Geof> When I go to do 'echo NL-AB-BBC > $SLOTS' it only will load a file with rev 00A0 from what I can tell.
Apr 16 16:48:42 <zmatt> that's not a CAPE though
Apr 16 16:49:20 <zmatt> note that capemgr isn't meant to lay overlays as such, it's meant to *automatically* load overlays based on CAPE autodetection via I2C
Apr 16 16:50:09 <zmatt> using it to load cape-unrelated overlays is technically abuse, but for a long time there was no other way to load DT overlays
Apr 16 16:50:40 <Geof> Ok.  But... I made a modified dtbo with 00D0.  Rebooted, and the mappings of the GPIOs etc didn't show up in your showPinsV3 the same way as they do if I do it for 00A0.
Apr 16 16:51:00 <zmatt> if you force-load an overlay it'll assume 00A0
Apr 16 16:51:17 <zmatt> if you use the new configfs mechanism, then those versions and other CAPE metadata have disappeared entirely
Apr 16 16:53:02 <Geof> So while not completely accurate that it must be 00A0, 00A0 works better in some ways.  Ok, I get it.
Apr 16 16:53:20 <Geof> Where do I go to learn about configfs?
Apr 16 16:53:58 <zmatt> ehm, there's a doc somewhere I think, but it's fairly straightforward... the dtbos are still the same as before (except the metadata is irrelevant and ignored)
Apr 16 16:54:43 <Geof> Ok, that makes sense.  I'm back in business anyway with my new understanding etc.  Thanks for your help and guidance.
Apr 16 16:55:10 <zmatt> cd /sys/kernel/config/device-tree/
Apr 16 16:55:12 <zmatt> mkdir foo
Apr 16 16:55:13 <zmatt> cd foo
Apr 16 16:55:22 <zmatt> sorry
Apr 16 16:55:25 <zmatt> cd /sys/kernel/config/device-tree/overlays/
Apr 16 16:55:40 <zmatt> wait I'll make a transcript and pastebin it
Apr 16 17:03:10 <zmatt> http://pastebin.com/YnAfZci9
Apr 16 17:03:57 <zmatt> bbl, shopping
Apr 16 17:05:05 <Geof> Thanks!
Apr 16 17:23:37 <mausy5043> Thanks @zmatt
Apr 16 17:23:45 <mausy5043> I'll give that a try too
**** ENDING LOGGING AT Sun Apr 17 02:59:58 2016