**** BEGIN LOGGING AT Sat Sep 17 02:59:58 2016
Sep 17 03:19:12 <veremit> nope, nobody here .. only 237 names in the nicklist....
Sep 17 03:19:20 <veremit> http://www.catb.org/esr/faqs/smart-questions.html
Sep 17 05:44:54 <vincentgosselin1> Hi, is there anyone here?
Sep 17 05:48:15 <vincentgosselin1> Am I the only one coding at this time?
Sep 17 05:49:09 <vincentgosselin1> hello?
Sep 17 05:50:59 <vincentgosselin1> hellpo?
Sep 17 15:29:09 <Guest88419> hello,  cannot change GPIO48  from high (which is the default) to low (0) on debian 7 or 8. However it  works on Ubuntu 2014
Sep 17 15:29:47 <Guest88419> GPIO48 is unclaimed. Disabled HDMI on uEnv.txt
Sep 17 15:30:20 <veremit> what configuration? what do the sysfs entries say/do?
Sep 17 15:33:45 <Guest88419> can I have an example of sysfs? is it the output of  echo 48 .. export ?
Sep 17 15:35:22 <Guest88419> sysfs entries show no error
Sep 17 15:36:06 <Guest88419> the same sysfs commands work with over GPIO pins on Debian
Sep 17 15:36:24 <veremit> generally sysfs doesn't error :)
Sep 17 15:38:18 <Guest88419> thank God :)
Sep 17 15:39:04 <Guest88419> I am a noob..so hopefully somethings I say aren't going to be to stupid!
Sep 17 15:39:57 <Guest88419> but I really can't figure out why this pin isn't changing to low
Sep 17 15:40:19 <Guest88419> too* stupid
Sep 17 15:50:08 <veremit> it'll be something subtle .. always is :)
Sep 17 15:54:16 <Guest88419> is the best supported and stable OS for beagle Debian?
Sep 17 15:55:31 <veremit> at the moment, I'd say yes
Sep 17 16:22:39 <vincentgosselin1> Hello, is there anyone here?
Sep 17 16:58:23 <vincentgosselin1> hi?
Sep 17 16:58:28 <vincentgosselin1> is this a chat?
Sep 17 16:59:47 <tlab_> yes
Sep 17 17:00:18 <vincentgosselin1> Hi, wow first time I got an answer back
Sep 17 17:01:31 <vincentgosselin1> I can't figure out why I can't connect to my bbb on 192.168.7.2 with USB
Sep 17 17:02:04 <tlab> by http?
Sep 17 17:02:32 <vincentgosselin1> Ya, I installed the drivers for Mac OSX and I cant connect to it by Http
Sep 17 17:03:16 <vincentgosselin1> The only way I can get into my BBB is by tty.usbmodem2643 115200
Sep 17 17:03:33 <tlab> because it's setup as serial device
Sep 17 17:03:39 <tlab> not ethernet/ip
Sep 17 17:04:10 <vincentgosselin1> ok, when I type ifconfig in BBB I get :
Sep 17 17:04:11 <vincentgosselin1>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)  usb0      Link encap:Ethernet  HWaddr 5e:4c:7a:89:3b:2c           inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252           inet6 addr: fe80::5c4c:7aff:fe89:3b2c/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0 frame:0           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0           
Sep 17 17:04:37 <tlab> can you ping 8.8.8.8
Sep 17 17:05:04 <vincentgosselin1> nop I can't
Sep 17 17:06:00 <vincentgosselin1> It's like the webserver is not active on the BBB, I can't figure out how to activate it
Sep 17 17:06:03 <tlab> are you connecting via serial via a special cable, or just usb
Sep 17 17:06:09 <vincentgosselin1> just USB
Sep 17 17:06:28 <tlab> I don't think you can run serial usb and usb/ethernet at the same time
Sep 17 17:06:56 <tlab> can you hook up bbb to ethernet? it's much easier
Sep 17 17:07:49 <vincentgosselin1> Well I can, thing is my router is pretty far from my lab in my room. Debug sensors at distance isn't the best.
Sep 17 17:09:37 <vincentgosselin1> Is there a way to put my BBB in factory settings so the default webserver at 192.168.7.2 is active?
Sep 17 17:11:45 <vincentgosselin1> I'll be back tlab, brb
Sep 17 17:19:23 <vincentgosselin1> ok I'm back
Sep 17 17:19:28 <tlab> ok
Sep 17 17:19:56 <tlab> you are using debian?
Sep 17 17:20:01 <vincentgosselin1> yes sir
Sep 17 17:20:20 <tlab> in /opt/scripts/boot there is an autoconfigure_usb0.sh
Sep 17 17:20:46 <vincentgosselin1> give me 5min I'll get into it
Sep 17 17:22:06 <tlab> that should setup your usb for network
Sep 17 17:24:39 <vincentgosselin1> thanks for the info, won't be long ill tell you in no time
Sep 17 17:26:01 <tlab> actually looks like I can run both serial port and usb network
Sep 17 17:27:19 <vincentgosselin1> Nop I don't see any autoconfigure_usb0.sh in /boot
Sep 17 17:27:20 <vincentgosselin1> root@beaglebone:/opt/scripts/boot# ls am335x_evm.sh  omap3_beagle.sh
Sep 17 17:28:15 <veremit> if usb gadget is working properly .. and -all- the drivers are installed .. you should see (1) serial (2) ethernet (3) mass storage
Sep 17 17:28:18 <tlab> cat /ID.txt
Sep 17 17:29:39 <vincentgosselin1> whats the full pat of /ID.txt tlab?
Sep 17 17:29:55 <tlab> that is the full path /ID.txt
Sep 17 17:31:14 <vincentgosselin1> Hi veremit, I can only access my BBB by typing  /dev/tty-usbmodem2643 115200, not with 192.168.7.2
Sep 17 17:31:47 <vincentgosselin1> tlab : root@beaglebone:/# cat ID.txt cat: ID.txt: No such file or directory
Sep 17 17:31:53 <veremit> vincentgosselin1: that's because your mac isn't getting an IP address from the BBB
Sep 17 17:33:09 <vincentgosselin1> veremit, here is the ifconfig from BBB :
Sep 17 17:33:20 <vincentgosselin1> inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252           inet6 addr: fe80::9429:a2ff:fe12:3e2b/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0 frame:0           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Sep 17 17:33:20 <veremit> pastebin/bpaste
Sep 17 17:33:42 <veremit> the Zeros are a HUGE giveaway
Sep 17 17:33:58 <vincentgosselin1> Ok we're on something
Sep 17 17:36:13 <veremit> do you have a network interface on the mac for the BBB?
Sep 17 17:36:28 <vincentgosselin1> tlab for your info : root@beaglebone:/# cat /etc/dogtag BeagleBoard.org BeagleBone Debian Image 2014-04-23
Sep 17 17:36:43 <veremit> wow thats old
Sep 17 17:37:00 <tlab> probably what came with the board
Sep 17 17:37:06 <vincentgosselin1> exactly
Sep 17 17:37:10 <veremit> you might wanna update that
Sep 17 17:37:23 <vincentgosselin1> No SDcard ://////
Sep 17 17:40:31 <vincentgosselin1> update with no SDcard, is that possible?
Sep 17 17:40:47 <vincentgosselin1> I got the boot device on my mac containing all the files
Sep 17 17:41:24 <tlab> I don't know, I only use sdcard
Sep 17 17:43:17 <veremit> there is a way in linux to do it over usb .. but the instructions are . old and incomplete
Sep 17 17:43:56 <vincentgosselin1> arghh ok. I'll buy an Sdcard + Usb_to_sdcard to flash
Sep 17 17:43:58 <tlab> brb
Sep 17 17:44:23 <vincentgosselin1> thanks guys so much for your support
Sep 17 17:44:25 <veremit> 4gb should be fine .. they're only a ocuple of $/etc
Sep 17 17:45:32 <vincentgosselin1> I need to do some school stuff now and stop worrying about my BBB :)
Sep 17 17:48:19 <vincentgosselin1> veremit, can I have your email address?
Sep 17 17:48:41 <veremit> generally we all stick to sharing informatin here, and not give out email addreses
Sep 17 17:48:58 <veremit> I like most, hang around here most of the time .. except when asleep :D
Sep 17 17:50:05 <vincentgosselin1> Alright that's perfect, I like communities like that.
Sep 17 17:50:45 <vincentgosselin1> have a great day thanks.
Sep 17 21:24:32 <zmatt> veremit: did I mention yet that the mcasp driven is pretty broken?  I'm actually amazed it even works at all
Sep 17 21:24:36 <zmatt> *driver
Sep 17 21:25:12 <veremit> zmatt: uhoh .. what have you found now?! :P
Sep 17 21:25:30 <veremit> I thought you were actively using it, no?!
Sep 17 21:26:30 <zmatt> yes, and now I was repairing DIT support (direct S/PDIF / AES3 output)
Sep 17 21:26:42 <veremit> rut roh...
Sep 17 21:26:52 <zmatt> yes, lots of nonsense
Sep 17 21:27:23 <zmatt> bad code structure, e.g. the bit-endianness on the wire is not configured anywhere near all other parameters of the format
Sep 17 21:27:58 <jmss> Hi, my XM keeps crashing from time to time (ssh: no route to host). I'm using Ubuntu. Any hints for debugging before recreating the micro-SD card from scratch with Debian?
Sep 17 21:29:29 <zmatt> serial console?
Sep 17 21:30:17 <jmss> I'll try that, but I don't have the serial cable yet.
Sep 17 21:31:04 <jmss> I suppose using the HDMI will not enable to see the same debug output as the serial console?
Sep 17 21:32:03 <zmatt> depends on config and how far it gets in the boot process
Sep 17 21:32:42 <jmss> there should be a way to log the console to a remote machine, I'll check that on Google
Sep 17 21:34:10 <veremit> that depends on whether the logging agent is loaded even ...
Sep 17 21:34:44 <zmatt> netconsole
Sep 17 21:34:58 <veremit> from uboot?
Sep 17 21:35:10 <zmatt> "keeps crashing from time to time"
Sep 17 21:35:16 <jmss> yes, I found netconsole
Sep 17 21:35:33 <zmatt> netconsole will get you the last console log messages before the crash, hopefully
Sep 17 21:35:46 <jmss> yes, I'll try it
Sep 17 21:38:38 <zmatt> even more reliable is simply logging to RAM: iirc the omap3 already had the functionality of preserving external RAM on soft reset (including watchdog).  I don't know however whether anyone ever bothered to put that feature to good use in linux
Sep 17 21:52:49 <joel_> most ARM systems I’ve used use store pstore/ramoops to store kernel logs / oops logs
Sep 17 21:53:28 <joel_> not so much Intel, although there are some systems with BIOS support
Sep 17 21:57:13 <zmatt> well, omap3 / dm37xx supports it: "On a warm reset the SDRC registers and the FSM are not reset, but the external SDRAM memory can be optionally placed in self-refresh mode, depending on configuration"
Sep 17 21:58:15 <zmatt> so I think if you just statically reserve a chunk of RAM you can use it as a buffer that persists across warm resets
Sep 17 21:58:56 <jmss> netconsole in dmesg: netpoll: netconsole: eth0 doesn't support polling, aborting
Sep 17 21:59:23 <zmatt> oh yuck, you don't even have real ethernet of course
Sep 17 21:59:34 <jmss> how so?
Sep 17 21:59:34 <veremit> haha
Sep 17 21:59:43 <zmatt> because it's an omap3
Sep 17 22:00:04 <jmss> hum. because of the revision of the XM?
Sep 17 22:00:13 <jmss> it's an old one?
Sep 17 22:00:20 <zmatt> none of the omaps have Ethernet, it's not a thing often asked for on cellphones
Sep 17 22:00:24 <zmatt> (which is what the OMAPs targeted)
Sep 17 22:00:32 <jmss> ok
Sep 17 22:00:49 <tbr> the XM has a combined usb-hub-ethernet thing
Sep 17 22:00:55 <zmatt> so there's presumably some usb-to-ethernet thingy, just like on the rpi (which is also a mobile SoC)
Sep 17 22:00:55 <jmss> so netconsole is out of the question?
Sep 17 22:00:58 <tbr> SMC-something, something
Sep 17 22:01:24 <joel_> zmatt: yeah so then just a matter of reserving it with memmap= or some U-boot way, and then adding a DT entry for ramoops following: Documentation/devicetree/bindings/misc/ramoops.txt
Sep 17 22:01:26 <tbr> UART rules supreme for embedded debugging :)
Sep 17 22:01:37 <veremit> o no ... not that bloody smsc or lan blah-blah
Sep 17 22:01:44 <zmatt> jmss: well dunno, apparently it needs "netpoll" (I can guess what it is and why it needs it) and the ethernet usb thingy driver doesn't support it
Sep 17 22:02:17 <zmatt> jmss: maybe follow joel_'s hint as long as you don't have a console cable yet
Sep 17 22:02:49 <jmss> so, the OS is not fast enough to write the messages to the micro-SD card when it crashes, correct? otherwise I would see them on syslog after rebooting?
Sep 17 22:02:59 <zmatt> it's not about "fast enough"
Sep 17 22:03:15 <zmatt> writes are cached and performed lazily
Sep 17 22:03:27 <jmss> yes, ok
Sep 17 22:03:50 <zmatt> also, an interrupted write to eMMC is typically gone (best case)
Sep 17 22:04:37 <jmss> it's strange because the heartbeat keeps running even after the crash
Sep 17 22:04:48 <zmatt> how do you know it's a crash?
Sep 17 22:04:59 <zmatt> how do you define "crash" anyway
Sep 17 22:05:10 <jmss> ssh: no route to host
Sep 17 22:05:11 <zmatt> I've even seen activity happen after the system halted due to kernel panic
Sep 17 22:05:16 <zmatt> that's "unreachable"
Sep 17 22:05:18 <zmatt> not "crash"
Sep 17 22:05:31 <jmss> yes, that's why I defined it in the first place :)
Sep 17 22:05:41 <zmatt> are you using dhcp or fixed IPs?
Sep 17 22:05:46 <tbr> and you have checked if there are logs after it stops responding?
Sep 17 22:05:51 <jmss> was using DHCP, now static IP
Sep 17 22:06:06 <jmss> let me check the last log
Sep 17 22:06:30 <tbr> It is known that the SMC chip+driver on the XM would occasionally just go haywire. No clue if that ever got fixed.
Sep 17 22:06:34 <zmatt> tip: install avahi (specifically avahi-daemon and libnss-mdns) on beaglebone and host system, then they shouold be able to find each other by name
Sep 17 22:06:43 <zmatt> tbr: can it be soft-reset?
Sep 17 22:06:52 <zmatt> it sounds it should be easy to detect
Sep 17 22:06:59 <tbr> zmatt: don't remember and I never had an XM
Sep 17 22:07:06 <zmatt> me neither
Sep 17 22:07:27 <jmss> apparently it was running until I pulled out the power cable: Sep 17 20:17:01 arm CRON[1979]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 17 22:07:27 <jmss> Sep 17 21:17:01 arm CRON[1982]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 17 22:07:27 <jmss> Sep 17 22:17:01 arm CRON[1985]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Sep 17 22:07:27 <jmss> Jan  1 00:00:25 arm rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="529" x-info="http://www.rsyslog.com"] start
Sep 17 22:07:29 <tbr> I had Archos devices with all 3 OMAP3 spins
Sep 17 22:08:00 <zmatt> jmss: look back further in the logs for anything network-related?
Sep 17 22:08:07 <tbr> jmss: then it's easy, look in the dmesg log for anything suspicious
Sep 17 22:08:08 <jmss> ok
Sep 17 22:08:41 <jmss> there was a problem wit the printer: Sep 17 06:51:02 arm hp[1937]: io/hpmud/musb.c 1143: unable to open hp:/usb/Officejet_5600_series?serial=CN729D80F104B2
Sep 17 22:08:41 <jmss> Sep 17 06:51:02 arm hp[1937]: prnt/backend/hp.c 745: ERROR: open device failed stat=12: hp:/usb/Officejet_5600_series?serial=CN729D80F104B2
Sep 17 22:08:42 <tbr> it might be dmesg.0 or dmesg.1.gz
Sep 17 22:08:52 <jmss> I only using this as a print server, nothing else
Sep 17 22:09:10 <zmatt> ok, go back further
Sep 17 22:09:44 <remote> gcl-bot: hah!
Sep 17 22:10:04 <remote> 
WHO-owns-gcl-bot?

Sep 17 22:11:04 <zmatt> remote: why are you using a bogus ctcp and why are you asking everyone in the channel instead of just the ops?
Sep 17 22:11:24 <jmss> there was a similar error, about the same time: Sep 17 06:25:04 arm colord: Automatic remove of Officejet_5600-Gray.. from cups-Officejet_5600
Sep 17 22:11:25 <jmss> Sep 17 06:25:04 arm colord: Profile removed: Officejet_5600-Gray..
Sep 17 22:12:00 <zmatt> are those usb or network printers?
Sep 17 22:12:03 <jmss> ok, going back further there was a kernel crash:
Sep 17 22:12:03 <tbr> jmss: could you just use pastebin or a gist and dump all the log around the time you lost network?
Sep 17 22:12:43 <jmss> OK, I'll post syslog.1. there should be no sensible info, right?
Sep 17 22:12:57 <tbr> how about dmesg.1 or whatever?
Sep 17 22:12:59 <veremit> sensitive*
Sep 17 22:13:14 <tbr> syslog has unnecessary fluff at this stage
Sep 17 22:15:00 <jmss> here: http://pastebin.com/uKAJ9kWk
Sep 17 22:18:59 <zmatt> nothing earlier?
Sep 17 22:19:14 <zmatt> ohh that doesn't look good
Sep 17 22:19:26 <jmss> tbr: dmesg's don't seem to reach time 90126.363952 s which was when syslog shows the kernel crash
Sep 17 22:19:40 <zmatt> oh nm that's just the l3 error irq
Sep 17 22:19:56 <zmatt> jmss: go back further
Sep 17 22:20:12 <zmatt> this isn't a crash btw
Sep 17 22:20:27 <zmatt> even though I can understand thinking it is due to seeing a traceback in log
Sep 17 22:21:26 <zmatt> L3 interconnect errors were being generated, presumably by the usb subsystem
Sep 17 22:22:04 <zmatt> for some reason L3 error reporting failed and you got the "irq 26: nobody cared" and traceback
Sep 17 22:22:08 <zmatt> the root problem is: usb died
Sep 17 22:22:16 <zmatt> since both printers and usb-ethernet are dead
Sep 17 22:22:25 <zmatt> the printers are usb-attahed yes?
Sep 17 22:22:36 <jmss> syslog.2 has an absurd number of lines like: Sep 15 06:25:42 arm kernel: [2620580.270690] hub 2-2:1.0: hub_port_status failed (err = -110)
Sep 17 22:22:37 <jmss> Sep 15 06:25:47 arm kernel: [2620585.270751] hub 2-2:1.0: hub_port_status failed (err = -110)
Sep 17 22:22:37 <jmss> Sep 15 06:25:52 arm kernel: [2620590.270507] hub 2-2:1.0: hub_port_status failed (err = -110)
Sep 17 22:22:46 <zmatt> getting closer
Sep 17 22:23:00 <zmatt> again, a large chunk of log in pastebin would be nier
Sep 17 22:23:02 <zmatt> *nicer
Sep 17 22:23:26 <zmatt> sometimes important messages look unimportant and vice versa
Sep 17 22:23:29 <jmss> zmatt: yes, it's just 1 printer (maybe the other entry is the fax in the same printer)
Sep 17 22:23:51 <tbr> btw, which kernel is this?
Sep 17 22:23:53 <jmss> ok, I'll try to post syslog.2
Sep 17 22:24:07 <jmss> # uname -a
Sep 17 22:24:07 <jmss> Linux arm 4.2.7-armv7-x3 #1 SMP Tue Dec 15 01:04:22 WET 2015 armv7l armv7l armv7l GNU/Linux
Sep 17 22:24:57 <tbr> I suspect, as it's "just a print server", triggering on this type of event (e.g. loss of network connectivity or the printers being gone) and rebooting the board, might be the quickest/sanest band-aid
Sep 17 22:25:04 <zmatt> this being musb however, you can look at it in a different way: instead of complaining about every time it failed, celebrate every day it *works*
Sep 17 22:26:14 <tbr> especially on OMAP3 it was a source of never ending "joy"
Sep 17 22:32:19 <jmss> zmatt: lol
Sep 17 22:32:59 <jmss> I'm not being able to post .2 to pastebin
Sep 17 22:33:13 <jmss> I think it truncates lines after a certain limit
Sep 17 22:34:06 <zmatt> paste.debian.org ? hastebin.com ?
Sep 17 22:34:20 <tbr> dmesg output never has long lines IIRC
Sep 17 22:34:28 <tbr> so it's just the crud/fluff anyway
Sep 17 22:34:42 <jmss> gist also limits
Sep 17 22:35:13 <jmss> paste.debian.org does not exist?
Sep 17 22:38:09 <jmss> I'll paste relevant excerpts
Sep 17 22:41:14 <zmatt> I might remember the name wrong... my specific point was there are tons of pastebin-like sites
Sep 17 22:41:20 <zmatt> google can no doubt help out
Sep 17 22:42:28 <jmss> sorry. it was not a limit. there were strange chars in the dump, so copy/paste failed after the strange chars. I've removed the strange chars: http://pastebin.com/4SuPfD8m
Sep 17 22:44:11 <jmss> the strange chars were between lines 620 and 621: maybe they were cause by pulling the power cable?
Sep 17 22:45:00 <jmss> in less, the chars show like ^@^@
Sep 17 22:46:13 <zmatt> those are zero-bytes
Sep 17 22:46:28 <zmatt> and yes, corruption resulting from power failure
Sep 17 22:47:26 <jmss> zmatt: thanks, I've seen those several times before and was not sure about what they were
Sep 17 22:48:04 <jmss> since they are \0 bytes, I suppose, copy/paste interpreted as end of string maybe
Sep 17 22:48:26 <jmss> and ignored the rest
Sep 17 22:49:34 <zmatt> when I saw them they were nice 4 KB blocks
Sep 17 22:51:44 <zmatt> yeah okay so either the smsc95xx died or musb did
Sep 17 22:51:50 <zmatt> but looks like smsc95xx
Sep 17 22:52:25 <zmatt> oh nm, it's not using musb for the host port, you got proper usb
Sep 17 22:52:41 <zmatt> okay, so then: smsc95xx driver died
Sep 17 22:53:49 <zmatt> you could try to see if unloading the module and loading it again (or unbinding and binding again via sysfs) can clear the fault condition, but you'll need to wait till you have some way of working on it when this occurs again
Sep 17 22:54:02 <zmatt> e.g. serial console or via graphical login
Sep 17 22:54:49 <zmatt> also updating the kernel might help (if you prefer not to, you can try googling whether anything has been fixed in that driver any time recent)
Sep 17 22:56:51 <jmss> you were saying that it is expectd that stuff like this happens with a XM?
Sep 17 22:57:06 <jmss> I mean: is it supposed to happen due to faulty h/w?
Sep 17 22:57:30 <jmss> in other words: is it useless to report these bugs?
Sep 17 22:58:24 <zmatt> I don't know if it's a hw problem or a driver bug
Sep 17 22:58:26 <tbr> I don't remember if it's due to the SMC chip being garbage or the driver
Sep 17 22:58:49 <tbr> btw: for future log pasting use https://transfer.sh/
Sep 17 22:58:54 <zmatt> it's never useless to report, if only to keep track of how many people are having the probelem
Sep 17 22:59:48 <jmss> tbr: nice
Sep 17 22:59:50 <jkridner> jmss: which images are you using for xM?
Sep 17 22:59:57 <jmss> zmatt: ok
Sep 17 23:00:02 <jkridner> +1 regarding recording issues.
Sep 17 23:00:12 <jmss> jkridner: let me check, but maybe the one from Robert Nelson
Sep 17 23:00:24 <jkridner> I'm looking to do some super-minor updates to xM.
Sep 17 23:00:26 <tbr> the kernel version looked like it
Sep 17 23:00:43 <tbr> but there should be a newer kernel by now
Sep 17 23:00:45 <zmatt> those smsc devices are quite commonly used right?  so that means there's decent chance problems will eventually (or perhaps are already) resolved
Sep 17 23:00:57 <zmatt> e.g. try a 4.8 kernel
Sep 17 23:01:14 <jkridner> the mainline devs have been pretty good at addressing issues on xM.
Sep 17 23:01:32 <zmatt> yeah Tony's even been doing patches on the omap5
Sep 17 23:01:41 <jkridner> rcn-ee has recently added xM to the weekly test builds.
Sep 17 23:01:56 <jmss> judging from sources.list: deb [arch=armhf] http://repos.rcn-ee.com/ubuntu/ trusty main
Sep 17 23:02:03 <jkridner> zmatt: Yeah, Tony's amazing.
Sep 17 23:02:54 <jmss> but a apt distupgrade should keep me updated?
Sep 17 23:03:00 <tbr> mhm, maybe switch to ubuntu
Sep 17 23:03:02 <tbr> err
Sep 17 23:03:04 <jmss> with the latest from RCN?
Sep 17 23:03:04 <tbr> debian
Sep 17 23:03:07 <jkridner> I don't know if that brings in the newer kernel.s
Sep 17 23:03:15 <jmss> oh
Sep 17 23:03:22 <jkridner> could, I just don't know.
Sep 17 23:03:23 <zmatt> jkridner: btw, I got S/PDIF working (the mcasp driver is really a mess)... if we can figure out how to tell the hdmi framer to expect s/pdif audio (it supports it) then that would free up two pins
Sep 17 23:03:52 <zmatt> i.e. you'd only have tx_hclk (from audio osc) the data pin
Sep 17 23:03:56 <jkridner> certainly it gets the regular package feeds, but I think he keeps separate packages for the kernels, not a single package with versions.
Sep 17 23:04:38 <tbr> yes
Sep 17 23:04:42 <jkridner> zmatt: Black? Using an HDMI-to-SPDIF splitter?
Sep 17 23:04:53 <zmatt> jkridner: no, *to* the hdmi framer
Sep 17 23:05:13 <zmatt> right now it uses I2S, which steals 3 pins in addition to the one occupied by the audio osc
Sep 17 23:05:14 <jkridner> zmatt: yeah, I'm talking about how do you get the SPDIF data out of the HDMI stream.
Sep 17 23:05:27 <jkridner> zmatt: or is this for TVs?
Sep 17 23:05:56 <zmatt> S/PDIF is just a different way of transporting audio data, I think it would probably end up the same on the cable as hdmi will reframe it again anyway
Sep 17 23:06:32 <zmatt> but S/PDIF uses 2 pins less, and supports non-PCM formats like dolby digital
Sep 17 23:07:08 <zmatt> not just TVs, I've seen hdmi monitors with speakers (or audio output plug at least)
Sep 17 23:08:35 <zmatt> with that change, the hdmi+audio "cape" would occupy fewer pins, which is always a good thing
Sep 17 23:09:47 <jkridner> zmatt: well, I hope you can work it out with the HDMI framer.... The Arrow BBBI has a different framer (ADI vs. NXP).
Sep 17 23:10:09 <zmatt> ah, to keep things simple
Sep 17 23:15:16 <jmss> ok, thank you guys, I now have a few more hints and info to tackle this problem, thanks for the support
Sep 17 23:16:45 <zmatt> yw
Sep 17 23:17:33 <zmatt> jkridner: of course it doesn't *have* to be portable to the BBBI... it can just be a freebie for BBB users, "here ya go, two extra I/Os available without being forced to disable HDMI audio"
Sep 17 23:21:26 <zmatt> jkridner: also took some scope pics when I was testing aes (pro s/pdif),  as an educational example of what happens then you omit the terminator on a sufficiently long transmission line ;)  -> https://gerbil.xs4all.nl/aes3/
Sep 17 23:22:01 <jkridner> pretty (ugly) :-)
Sep 17 23:22:51 <zmatt> yeah, even the terminated one isn't *that* nice since somebody at the office was too lazy to locate proper cable and used microphone cable instead
Sep 17 23:23:01 <zmatt> at least that's one possible cause
Sep 17 23:23:39 <zmatt> not important though, the terminated signals are loud and clear
Sep 18 02:03:41 <nooooooob> hello
Sep 18 02:05:20 <veremit> bye!
Sep 18 02:55:49 <crazyM> I'm trying to read serial data from header UART4 on a BBG and can't seem to read or write anything across serial. I've seen documentation on the BBB that says you have to enable the additional header UART's, but haven't found anything similar on the BBG. Has anyone used the header UART's on BBG?
**** ENDING LOGGING AT Sun Sep 18 02:59:58 2016