**** BEGIN LOGGING AT Fri May 27 02:59:58 2016 May 27 04:14:59 hey beagsssssssssssssss May 27 08:01:21 hi, I have connected bbb with dongle and my wifi dongle is successfully accessing internet by following some steps of network connection but now I want to automate this process. I mean to say that whenever I turned on bbb , my dongle should access to internet automatically. For this I have saved ifconfig and default route ip in /etc/rc.local file and after reboot it shows its connectivity through 'ping 8.8.8.8' and after this it ha May 27 08:01:37 and then no ping. So my question is that what should I do to resolve this problem? May 27 08:11:32 you are probably racing with some network control daemon May 27 08:11:44 you should either use that to bring up your interface or disable it May 27 08:18:25 ok.. but how to do so? May 27 08:22:49 morning beagles May 27 08:25:14 does the BBB board speak ACPI, ie does a press of the power botton on the board send a "shutdown signal" to the kernel? May 27 08:47:35 ScrumpyJack: no it does by default not have any idea about ACPI. Yes the Power button can be configured by the OS to shut down the OS. May 27 08:47:50 those things are perpendicular May 27 08:48:50 cool, i'll use acpid May 27 10:18:46 the BBB does not use acpi May 27 10:18:52 acpi is an x86 thign May 27 10:19:22 the power button is delivered as an input event which is recognized by systemd and can trigger a shutdown May 27 10:22:19 Hi guys, I got a problem on the SPI... The /dev/spidev2.0 is correctly created, but nothing is coming out on the pin itself (either SCL or SDA) May 27 10:22:44 you're confused, SCL/SDA are i2c pins, not spi May 27 10:23:41 yeah, sorry, i meant D0 and Sclk May 27 10:24:33 you can verify your pin settings with http://gerbil.xs4all.nl/show-pins-v3.pl.tgz May 27 10:26:11 based on the device name you seem to be trying to use spi1 (the +1 is due to some kernel idiocy, I've patched mine to fix it) May 27 10:26:30 yeah, it worked when I had dev0 for spi0 May 27 10:26:44 spidev1 for spi0 ;) May 27 10:27:23 so check the pinmux of P9.28-31 May 27 10:27:54 if i go in here: /sys/kernel/debug/pinctrl/44e10800.pinmux# and list the pins, i can see the pinmux right? May 27 10:28:08 last month I checked for the availability of any cnc/machinekit capes/boards etc, and after mailing around to various suppliers, none have responded with an answer, let alone an option to actually buy one May 27 10:28:24 that's the hard way yes, the easy way is to use my perl script which goes in there and nicely formats the output May 27 10:28:28 does anyone have a cape lying around? or know anyone who does? May 27 10:29:21 right now, pins 100 to 103 are all unclaimed May 27 10:29:43 well there's your issue then :) May 27 10:30:19 I use the dts BB-SPIDEV, with the correct pinmux May 27 10:31:34 could you do: grep -vP '^#|^$' /boot/uEnv.txt May 27 10:31:40 to list your boot config May 27 10:32:09 failbaitr: sorry, no idea May 27 10:32:46 uname_r=4.1.17-ti-r45 dtb=am335x-boneblack-emmc-overlay.dtb May 27 10:33:27 is cape_universal being enabled in cmdline? May 27 10:34:48 no, but how is it a problem since I load my own cape? May 27 10:35:01 it isn't, it would be a problem if it is enabled May 27 10:35:17 which it is by default on current images, which is why I asked May 27 10:35:43 ok, I see :) May 27 10:36:19 then the only conclusion left is that the pinmux declaration in the overlay is in fact incorrect May 27 10:38:10 here is it: 0x190 0x33 /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 */ 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ May 27 10:38:50 it's the latest version from bb-overlay May 27 10:40:54 so, the 0x33 is not loaded in pinmux, while no error is generated, either at the compile of the dts or at the loading May 27 10:43:36 I have no idea whether that's right or not, I use constants and macros to make my device tree muckery semi-readable :P May 27 10:46:02 is there another way to change the pinmux? Like build-in the kernel? May 27 10:46:21 can you try this? http://pastebin.com/geQnYnB2 May 27 10:46:36 (make sure there's no conflicting overlay loaded at the same time) May 27 10:48:04 beware btw that the numbering of spi devices by the kernel is currently not stable.. it just assigns them "spidev1", "spidev2", etc in the order it encounters them May 27 10:48:34 which means that if for whatever reason it sees spi1 before it sees spi0, then spidev1 would be spi1 and spidev2 would be spi0 May 27 10:50:07 (the fix turned out to be really easy... https://github.com/dutchanddutch/bb-kernel/blob/5cc13dce6c49604659a62cba1b8c7c8b24d436c9/patches/fixes/0001-spi-omap2-mcspi-leave-bus_num-allocation-to-spi-core.patch ) May 27 10:50:47 i get a "no rule to make target spi1.dtbo" May 27 10:51:16 you're in the "dts" directory of my py-uio project and downloaded spi1.dtsi there? May 27 10:51:30 yep May 27 10:51:40 nop May 27 10:51:43 my bad ^^ May 27 10:51:46 lol May 27 10:52:00 the makefile there has a .dtsi -> .dtbo rule May 27 10:52:41 alright, done May 27 10:52:51 check pinmux status now? May 27 10:53:15 9assuming the add-overlay reported no error) May 27 10:53:32 still unclaimed May 27 10:53:41 check kernel log for errors? May 27 10:54:02 [ 1001.874171] of_resolve_phandles: Could not find symbol 'pinctrl' [ 1001.880320] create_overlay: Failed to resolve tree May 27 10:54:09 oh that's my bad May 27 10:55:14 bin/rm-overlay spi1 May 27 10:55:29 get the dtsi again (I've fixed and reuploaded it) May 27 10:56:26 sorry I have a custom dts altogether and some names don't match the ones in the standard dts, I forgot to correct for that May 27 10:59:09 if you still have trouble, try rebooting ;) I've noticed that removing overlays has a tendency to leave it in a somewhat confused state, not uncommonly even leading to kernel panic on removal or reinsertion of an overlay May 27 10:59:26 *leave it = leave the kernel May 27 10:59:52 okay, mux still unclaimed, i'll reboot to see if it works better May 27 11:00:13 but the overlay didn't really load the first time May 27 11:00:18 ah ok May 27 11:00:28 add-overlay didn't give an error? May 27 11:00:33 no May 27 11:00:36 then it loaded May 27 11:01:00 note that my scripts use the new configfs mechanism, not bone_capemgr May 27 11:01:17 okay, so it doesn't display in the bone_capemgr list May 27 11:01:37 the two ultimately use the same kernel machinery, but they're not really aware of each other May 27 11:01:56 so, right now, the pins are still in the default status May 27 11:02:58 I'll try it here too May 27 11:03:30 (rebooting into 4.1 kernel with am335x-boneblack-emmc-overlay.dtb now) May 27 11:04:10 there is a post on the forum under SPI that seems to be the same issue May 27 11:05:27 I'm pretty sure I've used spi1 before without problem May 27 11:05:49 I did too, on another beagle May 27 11:06:01 with kernel 4.1 May 27 11:06:43 here, I installed an updated kernel (4.4) and the spi didn't work anymore May 27 11:06:52 so I came back to my 4.1 kernel May 27 11:07:17 and here I am now May 27 11:07:59 also, I'm an idiot and now my bbb won't boot (and I know why since this is the second time I've made the mistake) May 27 11:08:08 I haven't used 4.1 in ages really May 27 11:08:18 4.4-bone for a long time, and now on 4.6-bone May 27 11:08:35 and spi working fine for you? May 27 11:10:08 there, fixed my bbb again, let's see May 27 11:12:26 aaand it's not working May 27 11:12:32 lol May 27 11:12:48 don't you just love the kernel May 27 11:13:00 I do. Or not. May 27 11:13:06 https://archlinuxarm.org/forum/viewtopic.php?f=48&t=9899 May 27 11:13:16 here is the only link i found related to the same issue May 27 11:13:17 oi, what's that nonsense pinmux on P9.42 doing there May 27 11:13:55 he's talking about a driver issue, the driver isn't the problem May 27 11:14:55 But the configuration fails and the SPI pins are still configured as GPIO pins (0x37) . May 27 11:15:22 well... seems like his driver was loading but config of the pin failed May 27 11:15:55 ok what am I missing here... May 27 11:20:04 same problem on 4.4.9-bone10, wtf May 27 11:20:42 yep, I had the same May 27 11:20:50 that why I downgraded to 4.1 May 27 11:23:23 ok it does work in my custom kernel+dtb May 27 11:23:28 very odd May 27 11:23:51 is there a way to see the differences between your kernel and the 4.4 on the spi config? May 27 11:24:19 the difference is I'm not using an overlay but include it in the main dts May 27 11:24:59 that spi1.dtsi is however exactly the same as the one I'm using (up to the name of the pinmux node, which I fixed) May 27 11:25:51 so... like nothing else is different, but spi is working on one and not the other? May 27 11:26:02 basically yes May 27 11:26:07 lemme check the main dts May 27 11:26:11 loving it May 27 11:27:45 wait it doesn't really even make sense to check the main dts... if there was a problem with the spi node itself it wouldn't load at all and there would be no spidev node May 27 11:28:11 also, it looks fine to me May 27 11:28:33 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.1.25-ti-r62/arch/arm/boot/dts/am33xx.dtsi#L513 May 27 11:29:01 spi0 and spi1 are really the same up to the relevant differences in address/irqs/dmas May 27 11:29:55 so the driver's loading, no errors in kernel log, there's pinmux associated with it... but that pinmux ain't being applied May 27 11:30:38 see, crap like this is why I switched from using overlays to building my own dts pretty early on :P May 27 11:31:07 well, it was working on earlier kernel with overlays May 27 11:31:22 you win the "baffled zmatt" merit badge, congrats May 27 11:31:40 I'm gonna make tea May 27 13:18:47 Hey May 27 13:19:32 I do have a problem booting with a custom cape. Anyone of you have experience with using the hdmi pins on P8 when disabling HDMI via uEnv.txt? May 27 13:22:08 yes, I used hdmi pins for a LCD May 27 13:22:55 do you have problems booting with the lcd connected May 27 13:23:30 no, none May 27 13:24:43 can you take a look at my bootlog pls May 27 13:25:07 sure May 27 13:25:19 http://pastebin.com/Li5UC34R May 27 13:26:58 pin 21 seems to be used somewhere else May 27 13:29:46 pin 21 on the header p9 or p8? May 27 13:30:24 i do not use it on p9 but i do on 99 May 27 13:30:27 p9 May 27 13:30:45 still it does start with p9 plugged in May 27 13:31:41 have you tried loading the overlay manually and not at boot? May 27 13:34:59 which overlay? May 27 13:37:11 the one from your custom cape May 27 13:37:31 I have Debian OS running on my beaglebone with lot of scripts in it. What I want to do is create an image of this Debian OS and flash it on other beaglebones so that they will also have same set of files. Can someone please help me with this? May 27 13:38:01 i do load those needed manually May 27 13:38:36 @Aks: check this http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents May 27 13:38:40 @Aks: check this http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents May 27 13:39:47 Thanks I will check that link. May 27 13:42:58 Pin 21 error is also coming up without cape (http://pastebin.com/7GJZZqX8 clean boot) May 27 13:52:57 ideas? May 27 13:52:59 anyone? May 27 18:09:53 lol, I just found the cause of the weird bursts of cpu usage when ethernet is not plugged in... it's the driver workaround for the PHY's power-saving mode. disabling it reduces activity on an idle system to the 1 Hz tick and moreover removes the link detection delay when plugging in ethernet May 27 18:10:03 (disabling it = disabling the powersave mode) May 27 18:10:25 I wonder whether it actually even saves any power with that workaround May 27 18:33:22 zmatt: mwoar haxors May 27 19:10:26 yes very nice workaround... http://lxr.free-electrons.com/source/drivers/net/phy/smsc.c#L101 May 27 19:11:09 it polls for 640 ms, and this seems to be done every second or so May 27 19:12:05 purportedly to save 220 mW... for the remaining 360 ms at least, minus the extra power consumption by the cpu May 27 19:16:21 lol May 27 19:17:19 anyhow, I was actually trying to hunt down who/what is responsible for resetting the phy late in boot May 27 19:18:32 that's turning my 4.8 second boot into 7.8 second boot May 27 19:18:43 if time till network reachable is considered boot time May 27 19:18:56 painfull May 27 19:19:13 wow 8 sec boot .. ouch. May 27 19:19:27 yes, especially since the link was already fucking up May 27 19:19:28 why even boot .. just suspend to .. May 27 19:19:37 and the phy already reset... twice May 27 19:19:44 hehe May 27 19:20:28 veremit: resuming from eMMC is probably much slower than booting, but I'd still want to test that some day May 27 19:20:29 talk about 1st world problems .. lol May 27 19:20:46 could let u-boot reset it at his end of life ,, then during kernel init the chip is resetting to his pleasure May 27 19:21:18 rob_w: it requires exactly 0 resets other than the hardware reset that happens implicitly during power on May 27 19:21:25 it'll then automatically perform link negotiation May 27 19:21:41 neither u-boot nor the kernel has any business resetting it again May 27 19:21:43 warm starts then wont ? May 27 19:21:58 no, why would they need to? May 27 19:22:19 you'd just have a few seconds of packet loss :P May 27 19:22:40 well ,, resetting sometimes helps fixing buggy rom codes ;-) May 27 19:23:40 this ethernet phy actually can get in various fucked-up states May 27 19:23:47 ^^ May 27 19:23:49 but none of those can be solved by a software reset May 27 19:23:57 i had my pains with him .. May 27 19:24:49 they should have used GPIOs for phy reset and phy irq (the latter is missing too, so the cpu needs to poll for link state) May 27 19:25:19 "fortunately" the mdio controller has that polling functionality built in May 27 19:25:21 but i totally agree with your argument .. May 27 19:26:30 I really need to make some "if you're going to make another BBB clone, please fix the following" list :P May 27 19:27:48 its so cheap .. moneytizing those isnt fun May 27 20:29:50 Hi everyone! Is there any way to disable mass storage in Beaglebone Debian? I tried to remove attributes from modprobe invocation in /opt/scripts/boot/am335x_evm.sh (leaving only $g_network) but it seems that g_multi won't get up without them. Any suggestions? May 27 21:13:06 mrknife: use g_ether instead of g_multi May 27 21:13:40 (or libcomposite but that's more effort) May 27 21:13:51 any documentation on libcomposite? May 27 21:14:22 I will try with g_ether May 27 21:14:24 Thanks! May 27 21:16:47 there are examples about May 27 21:17:00 getting rndis to work driver-free on windows can be a hassle May 27 21:18:16 in theory it should be possible to make an rndis+ecm composite working on windows, linux, and mac... (except apparently osx 10.11) May 27 21:18:40 if you only care about linux hosts, eem is probably a better choice than either rndis or ecm May 27 21:20:25 but although EEM is crazy simple and standardized by the USB consortium in 2005, neither microsoft nor apple seems to have bothered to implement it (yet) May 27 21:22:52 unfortunately, my working machine is a 11.11 mac May 27 21:23:22 then I'd try an ECM-only config May 27 21:24:06 ok, thanks May 27 21:24:09 afaik the problem 10.11 has is with the compositeness or something, so pure ECM *should* work May 27 21:24:50 unfortunately to change g_ether to use ECM you'd need to recompile the kernel, so libcomposite (gadget config via configfs) may be simpler then May 27 21:25:49 well, I have a lot of time this weekend :) May 27 21:25:59 I kinda need to go now, but I'll be back in an hour or two and look up the script I already made once May 27 21:26:44 that would be great! May 27 21:27:41 it's not very hard once you understand what's going on, but it's still fairly magical unless you're much deeper into usb then I'd consider good for one mental health May 27 21:27:51 *one's May 27 21:30:34 I just started a hobby project involving ATmega with V-USB library so I don't mind looking deeper at USB :) May 27 21:31:51 it's a horrible protocol May 27 21:32:05 I wish I could get away with # CONFIG_USB is not set May 27 21:32:16 I actually did for a while on the BBB ;) May 27 21:32:34 anyhow, bbl May 27 21:33:03 see you! May 27 21:54:00 ~~~~~~~~~9033 May 27 21:54:12 +. May 27 21:54:30 ↵ xddddddddd4wqwqqqq`- May 27 21:55:15 oops May 27 21:55:26 sorry, new keyboard :) May 27 22:10:02 lol May 27 22:12:10 mrknife: g_ether *might* actually work out of the box with OSX, but you'd just need to try that May 27 22:12:43 recompiling the kernel is actually also a piece of cake if you have access to a decently fast linux box May 27 22:13:42 I think g_ether with the default config used on BBB kernels is composite RNDIS+ECN May 27 22:13:59 but I can't check easily until I arrive at work May 27 22:14:06 (in train currently) May 27 22:14:34 on unrelated note, this is really an epic hack -> https://www.youtube.com/watch?v=hB6eY73sLV0 May 27 22:15:01 (explanation of some of what's going on -> https://www.youtube.com/watch?v=TqK-2jUQBUY ) May 27 22:15:37 zmatt: you got an irc bouncer? or just some cunningness..... May 27 22:16:08 hmm? irssi running in screen May 27 22:17:15 ahh May 27 22:21:44 zmatt: fortunately for those of us without fast Linux box there is always AWS or Digitalocean May 27 22:21:45 On-demand VPNs are the best thing since sliced-bread ;) May 27 22:22:01 I will check it but need to get some sleep first May 27 22:22:47 its quite late here May 27 22:22:52 https://github.com/RobertCNelson/bb-kernel that's the tree with build scripts for the -bone kernel series (select branch for the specific version series) May 27 22:24:15 https://github.com/RobertCNelson/ti-linux-kernel-dev same for -ti kernel series May 27 22:25:25 afk May 27 22:25:27 Nice! Thank you for everything! I will probably be back so see you later! :) May 27 23:01:14 what is the projected ship date for beaglebone black? May 27 23:12:48 back May 27 23:13:04 josh98: eh, it's been shipping for a long time already May 27 23:14:51 if you meant the beagleboard-x15 instead, then no idea... I've not heard news since "didn't pass FCC, need to make adjustments, trying to get this done asap" May 27 23:18:50 veremit: seen the youtube vids? :D May 27 23:19:31 naa I'm pulling apart a package and its patchfiles May 27 23:21:17 they're short, watch 'em May 28 00:08:58 oops yes ty zmatt May 28 00:10:38 josh98, zmatt http://www.elinux.org/Beagleboard:BeagleBoard-X15 might have some details on where they stand on x15 May 28 00:13:33 so, one month from now provided the FCC deities can be appeased May 28 00:18:15 I'm thinking Christmas then .. :D May 28 00:19:00 zmatt, i am hoping to get a b1 asap to finish up the s/w story.. i hope in a week or two.. May 28 00:19:41 cool May 28 00:20:21 naw, rcn took the alpha x15 offline it seems, I can't ssh in anymore May 28 00:21:47 uggh... May 28 00:22:44 http://www.ti.com/tool/tmdsevm572x might be an option, a bit more pricier... May 28 00:22:59 however i hear they should be available. May 28 00:24:45 I don't really need access to one, I was just curious whether my ssh account still worked May 28 00:24:56 aah May 28 00:25:16 * NishanthMenon should probably leave office now.. ttyl folks.. have a great weekend May 28 00:25:37 I was working on poking around undocumented stuff, but it's tricky doing that remotely May 28 00:25:53 plus it was really early hw, I think silicon 1.0 even maybe May 28 00:26:12 have a nice weekend May 28 00:26:29 zmatt, yeah old es1.0 was painful a bit.. 1.1s and 2.0s are better off that way.. May 28 00:26:31 ttyl **** ENDING LOGGING AT Sat May 28 02:59:58 2016