**** BEGIN LOGGING AT Fri Mar 02 03:00:02 2018 Mar 02 03:17:36 Is there some kind of generic guide to use for distros that don't have a proper sdcard image? Mar 02 03:29:39 What pins does the BBB use to interface w/ Capes...P9_19 and P9_20, right? Mar 02 03:34:17 Sorry...I found out. Would I have to configure P9_17 and P9_18 w/ config-pin P9.17 i2c to use it w/ a cape? Mar 02 03:35:16 no Mar 02 03:35:55 I tested it. When you are right, you are right. Mar 02 03:36:17 P9.19-P9.20 are configured to i2c (by default) and used for cape autodetection Mar 02 03:36:30 Oh. Mar 02 03:37:07 (that i2c bus can also be used for other purposes of course) Mar 02 03:37:35 I just tested w/ config-pin on pin P9_19 and I have many types of ways to use it. Mar 02 03:37:58 how do I know if that pin is being used w/ an i2c bus? Mar 02 03:38:36 i.e. instead of gpio or spi_cs for instance. Mar 02 03:39:38 ... Mar 02 03:40:17 it's i2c by default Mar 02 03:41:49 Yep. I just used config-pin -q P9.19 to test it. Mar 02 03:41:51 i2c! Mar 02 03:44:15 So, there are four i2c buses being used by Capes/EEPROMS? Mar 02 03:44:32 ??? Mar 02 03:44:41 where did you get that nonsensical idea? Mar 02 03:45:02 I am going to get the link. Mar 02 03:45:23 the bbb doesn't even *have* four i2c buses Mar 02 03:45:41 https://beagleboard.org/Support/bone101 shows two i2c ports that are being used and four that are for Capes. Mar 02 03:45:43 Right? Mar 02 03:45:45 all cape autodetection uses i2c bus 2, on pins P9.19-P9.20 Mar 02 03:45:58 Oh. Mar 02 03:46:36 Look under the i2c section on the diagram for pinouts. Mar 02 03:46:48 what about it? Mar 02 03:47:21 I guess I did not understand. I thought the i2c1 buses were all being used by the EEPROMS on Capes. Mar 02 03:47:43 https://beagleboard.org/static/images/cape-headers-i2c.png makes it look like the functions can be pinmux'd to appear on different physical pins perhaps? Mar 02 03:48:11 ... Mar 02 03:48:31 I was more in tune w/ those sentences under the .png image. Mar 02 03:48:38 they can be, although pins P9.19+P9.20 are the ones used for i2c bus 2 by default. mapping i2c bus 2 to P9.21-22 instead would conflict with that Mar 02 03:48:50 Okay. Mar 02 03:48:57 I am just making extra sure. Mar 02 03:49:30 So, I do not need to configure anything outside of what is configured for my Cape to work. That is good news. Mar 02 03:49:37 the two sentences below it are correct apart from the awkward choice of words using saying "the first I2C bus" and "the second I2C bus" while they actually mean "i2c bus 2" and "i2c bus 1" respectively Mar 02 03:49:43 i.e. well w/ the i2c buses. Mar 02 03:50:01 See... Mar 02 03:50:19 I saw i2c1 and i2c2 and thought, "Oh...these are those buses." Mar 02 03:50:30 they are, but swapped Mar 02 03:50:37 Is the image wrong? Mar 02 03:50:45 Or are the words incorrect? Mar 02 03:50:46 configuring i2c1 is rarely useful since i2c2 is already enabled by default Mar 02 03:50:51 Okay. Mar 02 03:50:53 Got it. Mar 02 03:51:02 the image is correct, the text isn't Mar 02 03:51:07 Got it. Mar 02 03:51:24 i was losing my Gebraltor Straight. Mar 02 03:51:53 and no...I did not look up that word for that location. Mar 02 03:52:05 Back to the BBB! Mar 02 03:52:38 btw, if you don't mind I'm going to ignore your strange nonsensical comments in https://github.com/Seeed-Studio/MotorBridgeCapeforBBG_BBB/issues/6 (that's you right?) Mar 02 03:55:37 Okay. Mar 02 03:55:40 Thank you. Mar 02 03:55:52 You have my full attention but I still receive errors. Mar 02 03:56:07 Yea. Me, me, me! Mar 02 03:56:29 silver2row = worm_duel Mar 02 03:57:33 zmatt: Please do not ignore me on those posts. I changed things to suit the needs of Adafruit_BBIO in the MotorBridge.py library. Mar 02 03:57:40 the errors in your first comment were caused by random other changes you made to the source code. then it seems you noticed that and subsequently got an i2c error, which you bizarrely blamed on the use of variables or something, but presumably is either caused by having screwed up some system config (such as the pinmux of P9.19-20) or is perhaps caused by hardware issues (e.g. poor connection, or damage to Mar 02 03:57:41 I received errors. Mar 02 03:57:46 the motor controller) Mar 02 03:58:02 Oh. Mar 02 03:58:07 Damn! Mar 02 03:58:13 fine, I won't ignore it. I'll just comment there what I said above Mar 02 03:58:23 I only know so much lingo so far. Mar 02 03:58:31 I got errors listening to that person. Mar 02 03:58:45 I do not know what to blame and what to go w/ for now. Mar 02 03:59:42 I tested import Adafruit_BBIO.GPIO as GPIO and import Adafruit_GPIO as GPIO = no mas veces Mar 02 04:00:59 zmatt: Mar 02 04:01:01 ... Mar 02 04:01:28 I fixed my previous statements and tried to understand further w/ new software, new ideas, and testing. Mar 02 04:02:05 <<<< smoking Mar 02 04:02:19 that person is me, and I never said anything about changing the "import Adafruit_BBIO.GPIO as GPIO" line Mar 02 04:06:53 the python code was (most likely) working correctly when it was in the state where you got the "Remote I/O error", since that means it attempted to communicate with the motor controller via i2c (but it failed to respond) Mar 02 04:07:37 Oh. Mar 02 04:07:40 Now...I know. Mar 02 04:07:58 unless perhaps you made more changes to the code and in doing so messed up the reset logic Mar 02 04:08:28 try to make sure you use the original version of the motor bridge python library with only the two changes I mentioned Mar 02 04:08:58 I tried it. I got funny errors. Mar 02 04:09:05 I will do it again and post on it. Mar 02 04:09:28 zmatt: Do you want me to try to pastebin the errors? Mar 02 04:09:43 go ahead Mar 02 04:09:46 Yea boy! Mar 02 04:09:48 Please hold. Mar 02 04:12:42 ideally also power the system off and on first, just to exclude the possibility your errors are caused by e.g. messing with settings via config-pin Mar 02 04:14:05 Okay. Mar 02 04:14:08 Please hold. Mar 02 04:14:52 I might have some services that start. I will have to check. This may be my issue. Mar 02 04:15:26 brb Mar 02 04:15:46 Otay. Mar 02 04:23:31 They changed the services idea once upon a time and I was not in tune w/ the change. Mar 02 04:26:10 Forget it. I checked. Mar 02 04:44:38 still getting remote i/o error? can you double-check the configuration of pins P9.19, P9.20, and P9.23 using my show-pins utility? Mar 02 04:44:46 Sure. Mar 02 04:44:53 one moment. Mar 02 04:44:54 (pastebin the show-pins output for those pins) Mar 02 04:44:57 Okay. Mar 02 04:49:28 https://pastebin.com/HUkeLaNk Mar 02 04:55:53 P9.23, not P8.23 Mar 02 04:56:30 Oh. Please hold. Mar 02 04:56:32 Damn. Mar 02 04:58:32 https://pastebin.com/RxenAnG8 Mar 02 05:03:41 default Direction: out Value: 1 <<<< P9.23 from config-pin -q P9.23 Mar 02 05:04:03 ok that's all looking fine Mar 02 05:04:10 Ut oh... Mar 02 05:04:12 Okay. Mar 02 05:04:40 then I have no idea what's up with your cape's motor controllor not responding via i2c Mar 02 05:04:48 Okay. No issue. Mar 02 05:04:54 I will keep trying. Mar 02 05:05:16 Hey sir...I can use that cape on other boards willy-nilly. Mar 02 05:05:46 what's different about this board? Mar 02 05:05:49 for instance...BBB and BBGW but I have specific images and kernels. Mar 02 05:05:51 BBG Mar 02 05:06:11 This BBG board has a newer image w/ a 4.9.x kernel. Mar 02 05:06:43 wait, BBG or BBGW ? Mar 02 05:06:49 are you testing on a BBGW right now? Mar 02 05:06:54 BBG is the board I am using right now. Mar 02 05:06:56 No. Mar 02 05:06:58 BBG. Mar 02 05:07:25 ok BBG should be no problem Mar 02 05:07:38 It used to be no issue but then I updated. Things changed. Mar 02 05:07:41 I updated the image. Mar 02 05:07:45 and the kernel. Mar 02 05:08:23 no issue...I will plug at it some more and tell my findings to whomever. Mar 02 05:09:44 if you have a working configuration to test it in, run show-pins and save its output (all of it to be sure) Mar 02 05:10:14 Okay. Mar 02 05:10:17 Good idea. Mar 02 05:10:34 That is what I will do now. Mar 02 09:22:25 hi Mar 02 15:32:05 Anyone have any pointers to how I could essentially rebuild the linux-headers-4.1.18-bone20 deb package (or find said package in some archive)? Mar 02 16:51:58 yeah there are scripts Mar 02 16:52:05 oh wait, that specific old kernel? Mar 02 16:53:23 its headers rather Mar 02 17:08:12 cebart: assuming you have specific reasons to require the 4.1-bone kernel series, I'd suggest just moving to its latest bugfix release, 4.1.38-bone24, which is still available via apt Mar 02 18:18:30 zmatt: I have a number of fielded devices and I need to change a kernel module on them without a linux version upgradde. Mar 02 18:34:28 cebart: Did you see this? http://rcn-ee.net/deb/stretch-armhf/v4.1.18-bone20/ Since it's a diff file, it's not immediately clear to me what you apply it to (linux kernel source version 4.0 ?), but I think in theory this could get you part of the way there Mar 02 18:38:48 cebart: you can find a snapshot of that exact kernel tree here: https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.18-bone20/ Mar 02 18:58:32 Yeah, I'm not sure what that patches either, but am taking a look. Mar 02 18:58:38 I do have https://github.com/RobertCNelson/bb-kernel/tree/4.1.18-bone20 Mar 02 19:24:02 bb-kernel is the repository with build scripts Mar 02 19:24:11 the link I gave is the resultant tree Mar 02 19:25:37 iirc the build scripts might not behave well to build older git tags Mar 03 02:04:35 Hi I came here from the google summer of code webpage after reading the description of this opensource project, and was wondering if anyone has mentored a student for this project before or could provide information about the experience. **** ENDING LOGGING AT Sat Mar 03 03:00:00 2018