**** BEGIN LOGGING AT Sat Nov 12 03:00:00 2016 Nov 12 04:41:36 Hi I am trying to remote monitor an Horner PLC using an beaglebone black can anyone help me with it? Nov 12 09:10:32 .o0(why would one need to monitor a plc?) Nov 12 09:25:48 why not1? :P Nov 12 09:26:27 because they can monitor themselves Nov 12 09:26:38 and then? Nov 12 09:26:43 if you fear that it might break, then you bought some chinese crap Nov 12 09:27:29 -surprise- Nov 12 09:27:32 not. Nov 12 09:28:33 right .. bbiab gonna sort a new install o nhere ;P Nov 12 09:30:58 KotH: well we "monitor" a plc too, because the bbb runs the user interface :P Nov 12 09:31:31 zmatt: and why not use the bbb for the control too? Nov 12 09:32:25 I suspect they trust the plc more, and/or that part was designed by someone familiar with plcs Nov 12 09:36:11 it also adds an inherent safety layer if the (networked) bbb cannot directly interfere with the process control Nov 12 11:30:59 <_av500_> sell it to the Iranians :) Nov 12 12:23:28 lol Nov 12 13:24:20 I'm trying to get pin 107 setup. in pingroups it shows up, but in pinmux-pins it doesn't show up. Nov 12 13:24:28 Using program show-pins it doesn't show up Nov 12 13:33:37 show-pins -v can be used to show more pins (not just the expansion header), or -vv for really all pins in the array even if absolutely of no interest Nov 12 13:34:37 107 should normally show up though Nov 12 13:34:42 since it's an expansion header pin Nov 12 13:34:50 and it does in fact show up for me Nov 12 13:35:06 it shows up in the list, but nothing is connect to it Nov 12 13:35:21 P9.25 / audio osc 107 fast rx down 7 gpio 3.21 Nov 12 13:35:40 yeah that shows up Nov 12 13:35:49 do you want to enable it as audio osc output or use it for other purposes? Nov 12 13:36:05 other purposes Nov 12 13:36:54 hdmi (or at least hdmi-audio) is disabled? Nov 12 13:37:22 yeah I believe so, I'm loading my own dtb Nov 12 13:37:42 ok, you can double-check the audio osc enable via show-pins -v (pin 27) Nov 12 13:38:06 in that case it should just be usable just as any other pin Nov 12 13:38:15 audio osc enable 27 fast rx down 7 gpio 1.27 Nov 12 13:39:34 so looks it be disabled Nov 12 13:39:59 yeah that's fine. maybe hogging it to output 0 would give a bit more assurance but I've never bothered Nov 12 13:41:01 well then you should be able to mux the pin just like any other, there's nothing magical about pin 107 from the kernel's point of view Nov 12 13:41:55 yeah, it works on older 3.8 kernel Nov 12 13:42:04 P9.25 / audio osc 107 fast rx up 7 gpio 3.21 << hi mcp251x-irq (pinmux_bone_tt3201_1_mcp2515_pins) Nov 12 13:42:09 it also works for me on 4.x kernels Nov 12 13:42:30 ah that's not a pinmux issue (it is muxed to gpio) Nov 12 13:43:01 that's a problem of the driver apparently not loading, or at least not requesting the irq Nov 12 13:43:39 hm, actually it's not getting muxed properly either I suppose if you're still seeing "down" instead of "up" Nov 12 13:44:17 well on kernel 4.4* P9.25 / audio osc 107 fast rx up 7 gpio 3.21 Nov 12 13:44:27 ok, so it is in fact muxed correctly Nov 12 13:44:29 pinmux worked Nov 12 13:44:53 but driver probe failed Nov 12 13:45:32 I think that's pretty much the conclusion last time, when you started adding debug messages to try to narrow down *where* exactly it fails Nov 12 13:47:06 the company finally sent me files, but they semi work Nov 12 13:47:41 I can get all 3 cans up, I send can messages on all 3 cans, but the 3rd can will only send 1 message, after that it stops working Nov 12 13:48:08 is that the built-in can ? Nov 12 13:48:38 no I believe it's the mcp251x, but I'd have to double check Nov 12 13:49:04 that's weird if one mcp251x works and the other doesn't Nov 12 13:50:03 yeah I was thinking the cs wasn't working, but the irq line isn't getting set for one of mcp251 Nov 12 13:50:50 ohh, so the driver in fact successfully probes Nov 12 13:51:07 but doesn't request the irq line... but only on one of the two; that *is* odd Nov 12 13:51:22 can I see the relevant parts of the DT ? Nov 12 13:55:17 https://github.com/travlytle/bbb_dtb/blob/master/am335x-tt3201.dts Nov 12 13:56:58 note that the eMMC reset line doesn't actually work (by default anyway) Nov 12 13:58:27 does that effect what I'm working on? Nov 12 13:58:30 no Nov 12 13:58:47 I just noticed it as I was reading the file Nov 12 14:02:42 so I can get rid of the EMMC section. how about the &mmc1 mmc-supply Nov 12 14:03:18 why would you disable eMMC anyway? you absolutely require those pins for other purposes? Nov 12 14:04:01 (I'm still checking the dts btw, but being slowed down a bit since I'm simultaneously reformatting it to be readable) Nov 12 14:04:05 so I need to leave the emmc in reset section? Nov 12 14:04:16 haha thanks Nov 12 14:05:42 why would you disable eMMC anyway? you absolutely require those pins for other purposes? Nov 12 14:06:04 because you said the reset line doesn't work Nov 12 14:06:33 eh, I asked the question because I saw you were asserting eMMC reset Nov 12 14:06:40 (trying to anyway) Nov 12 14:06:59 it's copied code Nov 12 14:08:54 I believe it came from am335x-boneblack-nhdmi-overlay Nov 12 14:08:55 if you want to be able to use eMMC then the reset block should be replaced by something like this: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.19-ti-r41/arch/arm/boot/dts/am335x-boneblack-emmc-overlay.dts#L49-L55 Nov 12 14:12:55 you're using cs-gpios yet not muxing the chip select pins to gpio Nov 12 14:16:22 ok, you mean something like this: mcp251x,irq-gpios = <&gpio3 17 0>; Nov 12 14:17:37 I guess I don't understand what interrupt-parent/interrupts differs from mcp251x,irq-gpios Nov 12 14:18:15 sorry I understand I should focus on the irq, but I was just reporting stuff I stumbled over while reading the dts whenever I stumble over it (the chip select remark has nothing to do with irqs) Nov 12 14:19:46 I don't see any difference between the irqs... I do see that only one of the two has an "mcp251x,enable-clkout" property while the other does not Nov 12 14:20:15 yeah the original overlay was that way Nov 12 14:20:50 well, we have one mcp that works and one that doesn't so any difference is immediately suspect in my eyes Nov 12 14:21:13 yeah I'll try Nov 12 14:22:16 I think I had tried before but no luck, but something fishy is going on because the newer overlay they gave me has one pin switched. Previously they were using pin25, then they switch it to pin 23 Nov 12 14:22:45 which are those? Nov 12 14:22:55 irq's Nov 12 14:23:11 hmm Nov 12 14:23:34 gpio 3_19 and 3_21 got change to 3_19 and 0_17 Nov 12 14:23:50 you could try visually inspecting the pcb Nov 12 14:24:27 I checked the board and INT is connected to pin 25 and 27, like their old overlay Nov 12 14:24:50 I have an old board from them, so maybe they changed board and don't display it on web page Nov 12 14:24:52 (or assuming the irq lines have external pull-up, mux the pins to gpio input with internal pulldown and check if they measure high) Nov 12 14:25:20 yeah I have scope on both now, one is low the other is high at 4V Nov 12 14:25:23 the internal pulls are very very weak so normally one doesn't rely on those Nov 12 14:25:28 4V ??? Nov 12 14:25:33 what? Nov 12 14:25:49 maybe 3.8 Nov 12 14:25:50 I hope that's a measurement error Nov 12 14:26:11 since putting more than 3.3V on a BBB I/O is the easiest way to damage the processor Nov 12 14:26:52 yeah meter says 3.1xxx Nov 12 14:27:08 I need to check my scope 8( Nov 12 14:31:15 yeah now scope reads 3.24 Nov 12 14:33:10 ok... note that once you send a packet on the irqless device I'd expect its irq line to be continuously asserted low since it isn't getting serviced Nov 12 14:35:43 still doesn't explain why the line isn't requested by the device though... unless it was but then gave up with an error (but I assume you checked the kernel log for errors right?) Nov 12 14:36:19 dmesg? Nov 12 14:36:45 yes Nov 12 14:36:48 the mcp251x doesn't give many errors, I guess I need to go back and modify it some more Nov 12 14:36:54 true Nov 12 14:36:55 driver* Nov 12 14:38:19 what is the difference between interrupt-parent/interrupts lines, vs mcp251x, irq-gpios Nov 12 14:38:56 where do you see the latter? Nov 12 14:39:30 in the older overlay: mcp251x,irq-gpios = <&gpio4 19 0>; Nov 12 14:39:36 interrupt-parent/interrupts is the standard way of declaring interrupts Nov 12 14:40:32 ok that would be a custom way to declare gpio irqs implemented by some older mcp251x driver, perhaps the generic mechanism didn't work (properly) yet Nov 12 14:43:48 if the chip select isn't working, would that cause the driver to fail loading Nov 12 14:44:31 probably, or if it somehow doesn't then certainly you wouldn't be able to send a packet Nov 12 14:44:41 I'm a bit surprised it works at all like this though Nov 12 14:46:26 why, what seems off? Nov 12 14:46:58 15:12 < zmatt> you're using cs-gpios yet not muxing the chip select pins to gpio Nov 12 14:47:49 what am I missing? Nov 12 14:48:09 isn't reg the chip select? Nov 12 14:49:02 when using cs-gpios, those pins should be muxed to gpio (obviously) Nov 12 14:49:08 they're not Nov 12 14:49:20 and yes for spi devices reg is the chip select number Nov 12 14:52:03 aren't they setup with 0x19c and 0x164 ? Nov 12 14:52:44 what mux mode do you see being used for them? Nov 12 14:53:46 13 and 12 Nov 12 14:54:16 output pullup, same as previous overlay Nov 12 14:54:21 3 and 2 you mean, yes. (0x10 is the pull-up, not the mux mode) Nov 12 14:54:30 is that the mux mode for gpio? :) Nov 12 14:55:07 yeah, should be mode 7 eh? Nov 12 14:55:16 yes Nov 12 14:55:42 how the heck did it even work before?! Nov 12 14:55:43 either that or cs-gpios shouldn't be used, but this combination doesn't make sense Nov 12 14:55:52 it worked without cs-gpios Nov 12 14:56:04 in fact cs-gpios didn't work yet in older kernels Nov 12 14:56:37 (otoh I suspect, but haven't verified yet, that very new kernels may have broken non-gpio support for chip selects other than cs0) Nov 12 14:56:39 I never thought really to check that Nov 12 14:57:24 well that looks different Nov 12 14:58:24 note that I don't see an obvious reason to use cs-gpios here, I was just noting that using it without muxing the pins to gpio makes no sense Nov 12 14:58:46 yeah I agree Nov 12 14:58:49 http://pastebin.com/Cjagus1s Nov 12 14:58:56 compare 3.8 to now Nov 12 15:00:12 that P9.27 entry is looking really weird Nov 12 15:02:14 btw I recommend muxing pin 104 to gpio with pull disabled, instead of the bogus pinmux that's probably caused by some old version of u-boot Nov 12 15:02:31 that's just a side-note though and not terribly important Nov 12 15:03:42 I'm really not sure what the hell is up with that mcp driver, sorry Nov 12 15:06:48 hrm, now all 3 can's are showing up but one doesn't work Nov 12 15:10:07 isn't pin 104 0x164 ? Nov 12 15:11:13 ~$ printf '%x\n' $(( 104 * 4 )) Nov 12 15:11:13 1a0 Nov 12 15:12:02 (of course you can also just write (4*104) in DT instead of a hex number, which is exactly what my own macros do) Nov 12 15:16:51 how do you tell from show-pins if it's disabled? (pin 104) Nov 12 15:17:06 I added 0x1a0 0x17, this should disable it yes? Nov 12 15:17:07 what do you mean with disabled? Nov 12 15:17:24 oh with pull disabled Nov 12 15:17:29 yeah Nov 12 15:17:44 I'm assuming the mode doesn't matter Nov 12 15:17:52 I don't know, why are you still manually figuring out hex values instead of using the constants? Nov 12 15:18:04 the mode does matter, gpio is the safe default Nov 12 15:18:05 disabled meaning, RXACTIVE = 0? Nov 12 15:18:30 receiver is disabled unless the receiver enabled bit is set Nov 12 15:18:44 and that's what you mean by disabled? Nov 12 15:18:53 I never said disabled, I said pull disabled Nov 12 15:19:13 ahh ok Nov 12 15:19:31 so 0x17 is disabled, mode 7 Nov 12 15:20:45 the reason for disabling the pull is to avoid conflicting with the pull configured on pin 89 (which both tie together on P9.42) Nov 12 15:21:03 configuring the same pull on 104 as on 89 is fine too Nov 12 15:22:18 (same for the other pairs, 106/109 on P9.41 and 16/34 on P9.15) Nov 12 15:32:37 so weird, I had only two cans show up, both worked. Now I have all 3 showing up, but only can0 and can2 work. Nov 12 18:15:02 hi there guys :-) Nov 12 18:15:19 hi there channel :-) Nov 12 18:16:03 any interesting project for BBB Rev A5C Nov 12 18:16:27 that's the one I have Nov 12 18:17:00 I want to do something interesting with it Nov 12 18:18:18 can anyone advice me something about it Nov 12 18:38:08 can anyone advice me, please? Nov 12 18:43:04 BBB A5C Nov 12 18:45:09 which distro is best for BBB A5C angstrom? the one it comes by default? Nov 12 19:59:06 Hi folks, I am using BBB (Kernel 3.8.13 bone79) I have purged the isc-dhcp-client and isc-dhcp-common and have assigned a static ip (via /etc/network/interfaces), what other network management packages should I check for since it doesnt remain static) Nov 12 20:04:26 The static IP changes after certain time Nov 12 20:06:36 What else might take over the static IP assigned via /etc/network/interfaces that I should disable ? Nov 12 20:17:42 hi there tejas Nov 12 20:17:54 available? Nov 12 20:17:59 hi Nov 12 20:18:11 thanks to answer Nov 12 20:18:46 tell me which distro for BBB rev A5C? Nov 12 20:20:03 debian (pre-installed, Kernel 3.8.13 bone79) Nov 12 20:20:09 BBB rev C Nov 12 20:21:03 tejas, better the one that it comes by default amstrong Nov 12 20:22:27 tejas, which one is recent rev. A5C or C Nov 12 20:23:00 Amstrong is old, I have written communication programs (uart), pwm etc needed as per debian directory structure Nov 12 20:23:30 I mean debian works fine for me Nov 12 20:24:13 tejas, which one would you install in eMMC rev. A5C? Nov 12 20:24:57 I use debian, I haven't used Amstrong much Nov 12 20:25:33 Hi folks, I am using BBB (Kernel 3.8.13 bone79) I have purged the isc-dhcp-client and isc-dhcp-common and have assigned a static ip (via /etc/network/interfaces), what other network management packages should I check for since it doesnt remain static) Nov 12 20:25:54 tejas, what's the difference between A5C and C? Nov 12 20:26:02 The static IP changes after certain time, What else might take over the static IP assigned via /etc/network/interfaces that I should disable ? Nov 12 20:26:50 dury : I guess its same Nov 12 20:27:12 dury : I am not sure but Nov 12 20:38:37 tejas, Rev. C 4GB eMMC, Rev. A5C 2GB eMMC Nov 12 20:39:13 tejas, thats what I've found http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_C_.28Production_Version.29 Nov 12 20:52:49 gessss I wanna flasher with lxde included for Rev.A5C. how can I do it? Nov 12 20:53:22 to install in eMMC, is that possible? Nov 12 20:55:07 tejas, can you advice please? Nov 12 21:11:40 gessss today is not the day to get support :-( Nov 13 01:32:58 Hello **** ENDING LOGGING AT Sun Nov 13 02:59:59 2016