**** BEGIN LOGGING AT Mon Feb 01 02:59:58 2016 Feb 01 02:59:59 -.- Feb 01 03:09:26 always fun with alsa :D Feb 01 03:09:33 zmatt: just reading through https://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/06/bbb--building-a-dac which looks interesting, but possibly not very relevant lol Feb 01 03:10:46 someone else suggesting i2s on the mcasp davinci driver is. ... quirky Feb 01 03:11:27 filt3r: do you happen to know the magic DT incantation to configure McASP for tx as clk/fs master but external hclk? Feb 01 03:13:47 ok time for zzz .. nite folks .. g/l zmatt! Feb 01 03:14:28 nite veremit Feb 01 03:16:20 well its not possible from the DT, a platform driver has to call snd_soc_dai_set_sysclk(..., ..., ..., ..., SND_SOC_CLOCK_IN); Feb 01 03:16:35 simple audio card seems to be doing this Feb 01 03:16:44 I'm using simple audio card Feb 01 03:16:48 https://gist.github.com/pietrmar/aa35704c03f18e283652 Feb 01 03:16:53 try this, this has worked for me Feb 01 03:19:04 or i think it might be the default state as input and when you specify the mclk_fs property it sets it up as ouput, would be my guess from looking at the simple-card.c source now Feb 01 03:19:18 I don't think I'm setting that one Feb 01 03:21:05 unless I accidently uncommented it again... I've tried many things, the docs are clear as mud and the sources aren't very easy to navigate either given that I still have absolutely no overview how all this fits together :/ Feb 01 03:21:26 ah crap I did Feb 01 03:21:52 ye i spend like one whole afternoot to get the simple-audio-card to work :D Feb 01 03:22:20 and i still don't think it was worth it, because it's not really flexible for any more advanced stuff Feb 01 03:22:47 this is just a stopgap... they need audio out only for now, and they kinda need it urgent Feb 01 03:23:14 so I figured just 1 serializer as output, ought to be doable :P Feb 01 03:33:32 it is configuring hclk as input now... Feb 01 03:35:36 isnt that what you wanted? Feb 01 03:35:53 yeah, but your example didn't actually work otherwise (it configured 0 slots) Feb 01 03:36:08 but mixing what I had with yours seems like it might be working Feb 01 03:37:06 hmm strange Feb 01 03:37:22 ohh ye Feb 01 03:37:52 oh nvm :D Feb 01 03:38:06 actually it still gets the clock divider wrong Feb 01 03:38:11 I think... Feb 01 03:38:35 you have to set system-clock-frequency in the simple audio card to your external clock Feb 01 03:38:50 at least that was what i had to do Feb 01 03:38:59 I did, but probably in the wrong place Feb 01 03:39:39 also this patch was based on mainline kernel 4.4 so maybe you stuff does not work right for your kernel Feb 01 03:39:45 *your Feb 01 03:40:14 yeah I tried 4.1 out of curiosity but it doesn't seem to comprehend anything about your or my version Feb 01 03:40:42 unfortunate since afaik 4.1 still has relevant non-mainlined bugfixes for other stuff Feb 01 03:40:46 (4.1-ti) Feb 01 03:41:03 though I'd personally prefer to move on to 4.4 also Feb 01 04:01:29 I’m working on having a beagle bone black to interface with a door-entry buzzer. Multimeter reads ~18.45V from the button already installed, sending a ground signal when pressed. Any more experienced tinkerers think using this circuit setup( http://www.instructables.com/id/Web-Enabled-Garage-Door-Raspberry-Pi/?ALLSTEPS ) will fry my beagle bone? Feb 01 04:09:28 filt3r: I think it's working! modulo some signal integrity issues (hopefully just the general flakiness of the setup) and I'll need to create a "codec" (rolls eyes) anyway since DIT doesn't allow 32-bit slots Feb 01 04:09:39 yes Feb 01 04:09:46 or just hack dit to allow 32 bit :D Feb 01 04:09:49 its one line Feb 01 04:09:51 true Feb 01 04:09:53 you have to add Feb 01 04:10:06 yeah I've seen the line already Feb 01 04:10:07 at least tahts what i did the last time i used dit :D Feb 01 04:10:24 it's a stopgap measure anyway Feb 01 04:11:43 I have McASP working on baremetal but that's without dma, I've used edma before from userspace but that was just a static circular buffer... this time a bit more construction will be needed Feb 01 04:12:57 so McASP from userspace needs a bit more time, but until then at least they'll have this simple case working Feb 01 04:13:16 thanks for your help! Feb 01 04:13:31 sure :D Feb 01 04:14:08 I just realized that the pins they used (on P8) have those damned inexplicable capacitors on them... I hope those aren't going to give trouble... Feb 01 04:14:15 then again, if it can pass video, it can pass audio Feb 01 04:18:43 if i flash an sdcard, place it in bbb0, boot it up and run it (including connecting to the wired eth), is there any reason i could not subsequently put that same scard in bbb1 and successfully run it (including network connectivity)? Feb 01 04:19:03 let's just say i flash it with a standard debian build Feb 01 04:19:49 i.e., does the board/network i/f somehow "mate" to that sdcard or the filesystem thereon? Feb 01 04:20:04 yates: I've seen some remark about that somewhere Feb 01 04:20:32 so that network connectivity is not available when running it on another bbb ? Feb 01 04:20:35 persistent-net.rules Feb 01 04:20:51 it renames the interface Feb 01 04:20:53 oh. Feb 01 04:20:57 because it thinks it's a different network card Feb 01 04:21:55 https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone Feb 01 04:22:21 something went wrong on that page clearly though :P Feb 01 04:22:57 so, going by my example, running the same sdcard on bbb1 will create both a eth0 and an eth1, with the actual real phy being eth1, and you lose connnectivity because things normally connect to eth0? Feb 01 04:23:22 depends on what you're using Feb 01 04:23:35 (i.e. ifupdown, connman, NetworkManager, systemd-networkd) Feb 01 04:24:15 the middle two will probably connect anyway, ifupdown sucks, systemd-networkd depends on config Feb 01 04:24:16 no, it's there. i didn't understand it and thus didn't implement it. Feb 01 04:24:38 nothing, just the normal system bootup - whatever it uses Feb 01 04:24:47 depends on what image you started with Feb 01 04:25:02 I think console still uses ifupdown but I'm not sure Feb 01 04:25:21 the last time I saw an lxqt image it used connman Feb 01 04:25:21 doesn't the network get connected prior to login? Feb 01 04:25:34 I mean the console images from rcn Feb 01 04:25:49 /join ##electronics Feb 01 04:26:13 my personal preference goes to systemd-networkd but for that you need stretch, the version in jessie is still too sucky Feb 01 04:28:12 well that must certainly be the problem. zmatt, you're a super-bug-killer! Feb 01 04:28:20 thanks! Feb 01 04:28:38 you're welcome Feb 01 04:29:30 so even though you have NOTHING in your /etc/network/interfaces about eth1, one gets created? Feb 01 04:30:03 /etc/network/interfaces is not responsible for creation/naming of devices Feb 01 04:30:03 that stinks Feb 01 04:30:24 it's there to provide configuration for them Feb 01 04:30:29 the device name is used in it, it doesn't DEFINE it? Feb 01 04:31:00 of course not, how can you *define* an ethernet interface? will an extra port grow on the board if you add another line? Feb 01 04:31:55 the problem here is an udev rule that is triggered by the appearance of the device and helpfully renames it to avoid a clash with the other network card it saw earlier (the eth of the previous bbb) Feb 01 04:32:21 it is certainly within reason to expect the file to have n interface definitions if the board had n interfaces. that is the way i was assuming it worked. Feb 01 04:32:48 it just provides configuration based on interface name Feb 01 04:32:57 the problem is the interface being renamed Feb 01 04:33:07 but that's not ifupdown's fault Feb 01 04:33:11 i see that now Feb 01 04:33:21 what decides what the itnerface name is? Feb 01 04:33:40 initially the kernel, but udev can override that, and persistent-net.rules does exactly that Feb 01 04:34:33 putting a blank file with that name in /etc/udev/rules.d/ hopefully fixes the problem (by overriding the one in /lib/udev/rules.d/ ) Feb 01 04:38:40 ok, working on it. Feb 01 04:39:42 one painfaul aspect of our situation is that me and the tester are separated by about a 1.5 hour drive, and my uplink is only 100 KB/s. So if i have to ship him a whole new image, it takes ~2.5 hours~ Feb 01 04:39:58 ship == upload to a web server Feb 01 04:40:06 plus the download time Feb 01 04:43:23 zmatt: rcn's site doesn't say to generate a blank file there, rather it has a specific line to add. search that page for "persistent" Feb 01 04:43:58 I just looked, I got the name of the file in the code block (ditto with many other code blocks) Feb 01 04:44:23 that's why I said 05:22 < zmatt> something went wrong on that page clearly though :P Feb 01 04:47:28 sorry zmatt, i can't understnd what you just wrote. what do you mean by "code block"? are you saying rcn's directions on the udev rule there are wrong and you should just create a blank file? Feb 01 04:48:30 is my browser having issues and is the page looking different for you? Feb 01 04:50:42 http://www.digitalsignallabs.com/net.png Feb 01 04:51:02 weird Feb 01 04:51:32 that rule is horrible though, it just blindly renames any eth* device to eth0... Feb 01 04:51:44 even though its name will originally have been eth0 to begin with Feb 01 04:51:58 i can live with that... as long as it works Feb 01 04:52:24 but actually, let me ask another very relevent question. Feb 01 04:53:29 i'm goign to setup a ppp through the cellular module. how does that get named, and what would I do in the /etc/network/interfaces with it (if anything), and what about 70-persistent-net.rules for it? Feb 01 04:53:56 it'll be ppp0 probably, I don't think I've ever used ppp on linux Feb 01 04:54:30 I still wonder where the renaming is originally happening, I don't see an immediate suspect Feb 01 04:56:30 did you already have an /etc/udev/rules.d/70-persistent-net.rules btw? Feb 01 04:56:54 since apparently that's actually where such renaming rules are deposited (not sure yet by whom) Feb 01 04:57:10 checkign now Feb 01 04:58:35 yes. http://ur1.ca/oguhj -> http://paste.fedoraproject.org/316988/02707145 Feb 01 04:58:57 aha. Feb 01 04:59:01 it's got the mac address there Feb 01 04:59:16 at least the culprit is polite enough to identify itself Feb 01 04:59:39 I see no persistent-net-generator.rules though Feb 01 05:00:44 so if this file is auto-generated by whatever, wouldn't a default initial rootfs file just get overwritten? Feb 01 05:00:48 remove the file and replace it by a symlink to /dev/null, problem solved ;) Feb 01 05:01:13 is it? does it get regenerated on boot? Feb 01 05:01:18 it gets auto-updated when it sees a new network interface it hasn't seen before Feb 01 05:01:22 no, why would it? Feb 01 05:01:28 it might try to append a rule Feb 01 05:01:31 ... to /dev/null Feb 01 05:02:32 killing whatever is triggering the writes in the first place would be better, but I'm too lazy to dig into that right now Feb 01 05:03:20 ok, so it appends. assuming you don't point it to /dev/null, doesn't the problem then come back ifyou had added rcn's rule? first time you reboot? i.e., it would add a second rule overriding the first one Feb 01 05:03:39 no idea Feb 01 05:03:51 I don't think I have that mechanism to begin with Feb 01 05:04:03 none of those files mentioned are on my system Feb 01 05:04:21 i'm running 4.4.bone2 Feb 01 05:04:26 jessie Feb 01 05:04:31 (isn't it?) Feb 01 05:04:57 both are irrelevant, can you do dpkg-query --search /lib/udev/write_net_rules Feb 01 05:05:08 (assuming you do have that file) Feb 01 05:06:13 and then what? remove it? Feb 01 05:06:17 it's there Feb 01 05:06:25 http://ur1.ca/ogui6 -> http://paste.fedoraproject.org/316991/43031821 Feb 01 05:06:44 then dpkg-query --search dpkg-query --search Feb 01 05:06:45 eh Feb 01 05:06:50 then dpkg-query --search /lib/udev/write_net_rules Feb 01 05:07:03 to see which package is responsible Feb 01 05:07:55 and potentially remove it. Feb 01 05:08:11 I'm mostly just curious Feb 01 05:08:29 hang on - had to reboot my other card Feb 01 05:23:23 zmatt: is there a way to run a debian .img file on desktop linux (fedora) as a debian virtual machine (VirtualBox)? Feb 01 05:24:20 that may be a stupid question... Feb 01 05:25:26 nm Feb 01 05:37:45 Hi all, I am having a bit of a problem here connecting to BBB using remote systems on eclipse Feb 01 05:37:49 I have been following your informative blog for awhile. However, I am facing a bit of an issue while trying to connect and have access to the BBB through remote systems. The problem is, when I try to connect to BBB, a windows pops up indicating that "Default username password [debian:temppwd]", then once I click "OK" I am prompted to enter a password to have access to BBB. Why is it prompting for a password when I haven't sent any?. A Feb 01 07:38:33 Hello everyone!) Feb 01 08:12:04 How to change the default username and password on BBB? Feb 01 08:12:43 'passwd' 'adduser' Feb 01 08:12:54 for more details consult any beginners guide to linux Feb 01 08:16:22 ok fine Feb 01 08:27:41 \Leave Feb 01 08:40:54 :q Feb 01 08:41:02 ww Feb 01 11:11:13 hi all Feb 01 16:21:20 I'm wondering what is the best strategy to implement update strategy for applications running on the beaglebone black. I speak about python embedded applications that control the beaglebone Feb 01 16:26:35 Hello, I have a BeagleBoard-X15 and I would like to develop for it. Is there any support for it on beagleboard.org Feb 01 16:27:36 http://www.elinux.org/Beagleboard:BeagleBoard-X15 Feb 01 16:36:31 Is the SDK ready for use for the BeagleBoard-X15? Feb 01 17:31:29 Hello, Is it correct to assume that the OS image for the BeagleBoard-X15 has not been released yet? If not, when is it expected to be relased? Feb 01 17:32:25 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BeagleBoard-X15_weekly Feb 01 19:04:57 who Feb 01 19:05:02 #help Feb 01 19:05:17 try "/help" Feb 01 19:05:21 thanx Feb 01 21:16:04 Hello..I am using Yocto Project with Beaglebone Black Feb 01 21:16:33 I bitbaked core-image-sato and was trying to boot it from SD card Feb 01 21:17:00 But..the booting process stopped and can't resume Feb 01 21:17:16 None of the USER LEDs glow Feb 01 21:17:26 Can someone plz hel Feb 01 21:17:29 help* **** ENDING LOGGING AT Tue Feb 02 02:59:58 2016