**** BEGIN LOGGING AT Sun Sep 11 02:59:58 2016 Sep 11 03:02:08 maybe try moving the TT3201 overlay out of /lib/firmware (to prevent automatic loading of it) and reboot... sometimes meddling too much with overlays can muck state up Sep 11 03:02:13 well I know this all works on an old debian release with 3.8 kernel Sep 11 03:02:36 because someone put in the effort to make it work Sep 11 03:02:45 and they clearly never bothered to maintain it :P Sep 11 03:02:51 yeah I tried that and still doesn't work Sep 11 03:03:06 this is weird though, it really shouldn't be this hard to get it working Sep 11 03:03:09 before I had can0 and can1 Sep 11 03:03:26 now just can0 in ifconfig Sep 11 03:03:33 and I tried all 3 connectors again Sep 11 03:03:49 it's annoying they don't document which is which Sep 11 03:03:49 I even tried swapping can high/low on one Sep 11 03:05:39 well the old dts shows dcan on p924-26 Sep 11 03:06:13 yes same as in mine (can1) Sep 11 03:08:21 I have emailed support, but I haven't heard back from them, but was only 1-2 days ago Sep 11 03:08:51 can you check on a known-working config which of the ports they actually mapped to which? Sep 11 03:09:13 yeah I am loading on working one now Sep 11 03:09:21 will have to redownload your tools Sep 11 03:09:56 show-pins you mean... I'm not sure it'll give you anything useful Sep 11 03:10:24 I'm checking right now how you can see which actual hardware peripheral corresponds to which can interface Sep 11 03:14:58 realpath /sys/class/net/can0 Sep 11 03:15:02 http://pastebin.com/dSx0SUy7 Sep 11 03:15:58 (none of this conflicts with eMMC or HDMI btw, only with HDMI audio) Sep 11 03:20:19 can you check ls -ld /sys/class/net/can* Sep 11 03:20:55 on working or not working system? Sep 11 03:20:58 working Sep 11 03:21:11 so we know which is which on this cape Sep 11 03:21:27 lrwxrwxrwx 1 root root 0 Jun 15 20:44 /sys/class/net/can0 -> ../../devices/ocp.3/481d0000.d_can/net/can0 Sep 11 03:21:27 lrwxrwxrwx 1 root root 0 Jun 15 20:44 /sys/class/net/can1 -> ../../devices/ocp.3/481a0000.spi/spi_master/spi1/spi1.0/net/can1 Sep 11 03:21:27 lrwxrwxrwx 1 root root 0 Jun 15 20:44 /sys/class/net/can2 -> ../../devices/ocp.3/481a0000.spi/spi_master/spi1/spi1.1/net/can2 Sep 11 03:21:34 yay I guessed right Sep 11 03:21:47 and this is the "kernel 3.8+" numbering right? Sep 11 03:22:08 yeah Sep 11 03:22:31 trying to double check, have to reinstall can-utils Sep 11 03:22:32 ah wait no, boo I guessed wrong Sep 11 03:22:40 that's weird though Sep 11 03:23:28 I can't imagine how kernel 3.2 managed to get the two controllers on spi on can2 and can0 then Sep 11 03:23:43 (also, wow that's genuinely ancient) Sep 11 03:31:46 ok, I can see why the mcp2515 controllers won't work Sep 11 03:34:36 I'm not using an old image Sep 11 03:35:03 no the "genuinely ancient" was referring to the website listing kernel 3.2 Sep 11 03:35:17 I'm using debian 7 dated 6-15-2016 Sep 11 03:35:31 well 3.8 is also genuinely ancient, it's just being kept alive by unnatural forces :P Sep 11 03:35:49 can0 is on pins 3-4, like kernel 3.2 Sep 11 03:36:02 but I have 3.8.13 kernel Sep 11 03:36:14 doesn't matter, as I said it's actually unpredictable Sep 11 03:36:32 but then my assumptions make sense again Sep 11 03:39:44 neither of the mcp251x channels are working Sep 11 03:39:45 I'm trying to make an updated overlay based on the mcp2515 devicetree binding docs in kernel 4.4 Sep 11 03:39:52 on old or new kernel? Sep 11 03:40:32 3.8 Sep 11 03:44:30 ahh now I have all 3 can working Sep 11 03:46:59 debian bbb 6-15-2016 works Sep 11 03:47:11 I think I nearly have an updated overlay Sep 11 03:48:00 debian 8 didn't seem to work Sep 11 03:52:05 well the debian version usually doesn't matter much, the kernel version does Sep 11 03:58:43 ugh I thought I put a non-flasher sd card in, but evidently it's reflashing Sep 11 04:15:57 ok, overlay loads without error, the can interface of the am335x comes up, spi does too Sep 11 04:16:10 with a bit of luck this might work Sep 11 04:16:17 ok Sep 11 04:18:42 what is eqep0-2 ? Sep 11 04:19:01 platform 48300180.eqep: Cannot lookup hwmod 'eqep0' Sep 11 04:19:09 quadrature decoders, also usable for pulse counting etc Sep 11 04:19:22 that's harmless Sep 11 04:19:41 ok I pushed to overlay-utils on github Sep 11 04:20:21 make TT3201-001-01.dtsi ? Sep 11 04:20:24 .dtbo Sep 11 04:21:21 sec I think I need to disable audio Sep 11 04:21:38 http://pastebin.com/raw/7gcWeSxA <-- if you first make a udev rule like that and do udevadm control --reload then it should respect the ifname properties I created in the overlay Sep 11 04:21:52 yes hdmi audio pin-conflicts Sep 11 04:23:09 this is the documentation I used for the mcp2515 devicetree binding btw: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.19-ti-r41/Documentation/devicetree/bindings/net/can/microchip%2Cmcp251x.txt Sep 11 04:23:30 I hope it matches reality :P Sep 11 04:24:51 http://pastebin.com/nM96JFmn Sep 11 04:25:43 this is on 4.x kernel? you made sure no conflicting overlays were loaded? Sep 11 04:26:08 Linux beaglebone 4.4.9-ti-r25 #1 SMP Thu May 5 23:08:13 UTC 2016 armv7l GNU/Linux Sep 11 04:26:40 ahh override is on Sep 11 04:26:46 cape-universal Sep 11 04:26:50 blegh :P Sep 11 04:28:39 well it shows can0 Sep 11 04:28:41 only Sep 11 04:29:42 you checked kernel log for errors? Sep 11 04:30:32 dmesg or syslog? Sep 11 04:30:43 dmesg is the kernel log Sep 11 04:32:06 you can also keep a running log of everything that's going on open using sudo journalctl -f Sep 11 04:32:20 [ 36.079963] c_can_platform 481d0000.can: c_can_platform device registered (regs=fa1d0000, irq=198) Sep 11 04:32:20 [ 65.047985] c_can_platform 481d0000.can can0: setting BTR=1c05 BRPE=0000 Sep 11 04:32:23 or adding the -k option restricts to just kernel log messages Sep 11 04:32:30 yeah that's the good news Sep 11 04:32:40 but nothing about spi? Sep 11 04:32:52 no spi Sep 11 04:33:06 pru stuff before it Sep 11 04:33:19 even on my beaglebone spi got enabled and muxed Sep 11 04:34:30 and /sys/bus/spi/devices/ shows the two devices, although it didn't get any further due to lack of driver (I'm running a fairly lean configured kernel) Sep 11 04:35:10 should I copy TT*dtbo to lib/firmware Sep 11 04:35:17 or just start it with add-overlay Sep 11 04:35:23 not necessary if you use add-overlay Sep 11 04:35:47 in fact better to avoid having it in /lib/firmware/ since that would probably get it auto-loaded by capemgr, which is not what you want yet Sep 11 04:36:17 lrwxrwxrwx 1 root root 0 Sep 11 04:36 spi2.0 -> ../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.0 Sep 11 04:36:18 lrwxrwxrwx 1 root root 0 Sep 11 04:36 spi2.1 -> ../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.1 Sep 11 04:36:45 ok so they do exist Sep 11 04:37:04 no can1 or can2 in ifconfig -a Sep 11 04:37:08 inside one of those dirs, does it list a driver (symlink) Sep 11 04:37:27 http://pastebin.com/TZn9YPQp Sep 11 04:37:56 are you sure cape-universal is disabled? Sep 11 04:38:29 0: P----- -1 TT3201 CAN Cape,01,TowerTech,TT3201-001 Sep 11 04:38:35 only thing showing Sep 11 04:39:04 hmm, I have no idea how to read a slots file... that means it didn't find a dtb I hope? Sep 11 04:40:38 I have no idea, certainly muxing the spi pins Works For Me, and if there's something going wrong there the kernel should have issued complaints Sep 11 04:40:50 I'm afraid I'm running kinda out of energy for now Sep 11 04:40:53 cdlrwxrwxrwx 1 root root 0 Sep 11 04:40 of_node -> ../../../../../../../firmware/devicetree/base/ocp/spi@481a0000/can@0 Sep 11 04:41:12 yeah I'm getting tired too Sep 11 04:41:13 yeah, that's the back link to the of_node Sep 11 04:41:29 a perk of newer kernels, and the reason I could easily make the udev rule I mentioned earlier Sep 11 04:41:36 lrwxrwxrwx 1 root root 0 Sep 11 04:40 subsystem -> ../../../../../../../bus/spi Sep 11 04:41:48 no a driver link as in, literally named 'driver' Sep 11 04:41:56 but, right now the pins aren't even muxed Sep 11 04:42:14 no but Sep 11 04:42:36 ohh crap hold on Sep 11 04:42:38 :/sys/bus/spi/drivers/mcp251x is there Sep 11 04:43:18 I have an idea Sep 11 04:44:10 yes, for some reason the main dtb enables spi0 already :( Sep 11 04:44:25 at which point it doesn't have pinmux yet Sep 11 04:44:41 http://pastebin.com/TZn9YPQp ya it doesn't show active Sep 11 04:44:43 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.19-ti-r41/arch/arm/boot/dts/am33xx-overlay-edma-fix.dtsi Sep 11 04:45:12 no explanation of why this is done (i.e. what exactly it "fixes", since it also breaks stuff badly) Sep 11 04:45:21 ok, we can work around it Sep 11 04:47:19 echo 481a0000.spi >/sys/bus/platform/drivers/omap2_mcspi/unbind Sep 11 04:47:22 echo 481a0000.spi >/sys/bus/platform/drivers/omap2_mcspi/bind Sep 11 04:47:35 that'll reprobe the whole spi controller Sep 11 04:48:02 (I'm literally tearing its driver off and sticking it back on ^_^ ) Sep 11 04:48:33 http://pastebin.com/yfWRmNDu **** BEGIN LOGGING AT Sun Sep 11 04:50:30 2016 Sep 11 04:51:01 yeah Sep 11 04:53:38 possibly a better order would be: unbind, load overlay, bind (if that's still necessary, it's possible the overlay automatically rebinds it) Sep 11 04:55:08 I really don't like how they casually broke pretty much everything, often for not very clear reasons :/ Sep 11 04:56:19 ok, rebooted, unbind, add overlay, bind and still kernel error Sep 11 04:56:54 Internal error: : 1028 [#1] SMP THUMB2 Sep 11 04:57:42 what about if you don't have the overlay at all, just unbind and bind? Sep 11 04:58:49 same error Sep 11 04:58:59 ok, so it's just a problem with mcspi in this kernel version Sep 11 04:59:02 I'm using a lot newer kernel Sep 11 04:59:28 http://pastebin.com/Rb76ka09 Sep 11 04:59:58 yeah, without overlay there's no pinmux info Sep 11 05:00:12 http://pastebin.com/wyjQQiD2 Sep 11 05:00:31 I need to goto bed, can work on tomorrow maybe Sep 11 05:00:32 you can try a newer kernel, e.g. 4.4.19-ti-r41 Sep 11 05:00:35 yeah Sep 11 05:00:50 or just a dtb that doesn't much things up Sep 11 05:01:13 I just have the kernel from the image, I can try a newer image (weekly maybe) Sep 11 05:01:13 check if am335x-boneblack-custom.dtb is in /boot/dtbs/$kernelversion, might be worth trying Sep 11 05:02:01 you can also easily update the kernel, just apt-get update && apt-get install linux-image-4.4.19-ti-r41 Sep 11 05:02:14 http://pastebin.com/2Upcd5kP Sep 11 05:03:04 it might be new-ish, e.g. included with 4.4.19-ti-r41 Sep 11 05:03:10 anyhow Sep 11 05:03:17 good luck :P Sep 11 05:03:32 you can also try the mailing list to see if anyone can help you further Sep 11 05:03:33 thanks, I'm learning somethings Sep 11 05:05:32 your current roadblock is: whatever am33xx-overlay-edma-fix.dtsi fixes, it's breaking spi config via an overlay (since the driver gets enabled way too early before it has all needed DT config) Sep 11 05:09:37 well updated the kernel, still no go Sep 11 05:11:43 thanks for the help Sep 11 10:52:44 Hi all. Has anyone tried running the latest weekly debian image on an ipv6 network? Sep 11 10:53:36 I get "could not get link local address" in systemctl status networking.service after boot Sep 11 10:55:09 Looks related to debian bug #832264 Sep 11 11:07:53 Soo... "ip -6 -o a s dev "eth0" scope link -tentative" says -tentative is garbage Sep 11 11:44:38 Changing to Debian Testing and updating iproute2 fixes the garbage message. Now booting just takes hours. The "Raise network interfaces" start job runs for over a minute... Hmm Sep 11 13:57:00 Hello , can someone help me to find official RoHS approval for MPN:102010027 Sep 11 13:57:34 Beaglebone Green Sitara AM3358BZCZ MPU ARM Sep 11 17:58:25 has anyone used artik.io ? or any other cloud platforms to connect BBB? i need suggestions so that i can choose between them appropriate for my application Sep 11 18:39:18 Hi all. Is there a Jessie stable console only image? Sep 11 18:45:23 wotfan: I'd suggest upgrading to debian stretch and switch from ifupdown to systemd-networkd Sep 11 18:46:34 (starting from e.g. the latest jessie console image) Sep 11 18:48:31 Really? Is that the way it's likely to go in the future? Sep 11 18:49:03 I have no idea but it works excellent for me Sep 11 18:50:05 zmatt: hah okay Sep 11 18:50:09 Thanks Sep 11 18:50:21 at least it'll solve your boot time issue Sep 11 18:50:27 Are you on an IPv6 network? Sep 11 18:51:36 you're always on an IPv6 network (at the very least link-local) ;) Sep 11 18:51:59 but yeah at home I also have a global prefix and I noticed it does in fact use ipv6 when I ssh to a beaglebone Sep 11 18:52:40 Indeed, but do you have an IPv6 dhcp server? ;) Sep 11 18:53:02 I'm on an IPv6 only network here Sep 11 18:53:15 Which makes all of this quite interesting Sep 11 18:53:29 no, I have no idea why anyone would use DHCPv6, it should work fine though Sep 11 18:54:24 Haha not my choice. Lots of stuff just stops working in a v6 only network Sep 11 18:55:52 "v6 only" does not imply the use of DHCPv6, normally v6 just uses NDP Sep 11 18:57:40 but again it should work fine either way Sep 11 18:59:42 I'll try it at some point! As you say, it should work Sep 11 19:00:53 and systemd-networkd doesn't stall the boot process like ifupdown Sep 11 19:01:20 upgrading to stretch is needed to get liberated from the ancient packages in jessie, including a too-old systemd :P Sep 11 19:02:28 Hah cool. Anything I should watch out for in the upgrade? Sep 11 19:03:48 iirc if starting with a console image the upgrade itself is uneventful Sep 11 19:04:15 obviously fewer packages = fewer opportunities for trouble Sep 11 19:05:05 Yep I'm starting from the latest console image. So just do the usual changes to sources and dust-upgrade Sep 11 19:08:25 this would be a basic config for networkd: http://pastebin.com/raw/gKSnLUwp Sep 11 19:08:55 DHCPv6 is automatically enabled if a router advertises its use Sep 11 19:09:12 (hence it's not enabled in the .network file explicitly) Sep 11 19:10:22 Awesome, thanks! Yep the router here has its advertisements set up right Sep 11 19:11:04 then systemctl enable systemd-networkd systemd-resolved Sep 11 19:11:11 apt-get remove ifupdown Sep 11 19:11:14 reboot and pray ;) Sep 11 19:13:08 oh and replace /etc/resolv.conf with a symlink to /run/systemd/resolve/resolv.conf Sep 11 20:12:42 Sweet, now running systemd networkd **** ENDING LOGGING AT Mon Sep 12 02:59:58 2016