**** BEGIN LOGGING AT Tue Sep 25 02:59:59 2018 Sep 25 06:40:06 zmatt: I think the problem with mem sleep is only pinmuxing Sep 25 06:41:09 zmatt: the power consumption of the board suggests that it woke up fine, just e.g. uart pinmux is weird and so I see nothing Sep 25 07:15:28 zmatt: the boot script is burned into uboot? Sep 25 07:15:54 Hi! I have a Beagle X15 revC board and looking for a way to power on the board on power supply connect. As it is now I have to press power on button in order to start the board. Sep 25 07:16:22 Anyone know if this is possible? Sep 25 07:34:32 hello! I'm using a BBB with a LCD Cape with Touchscreen, and a GUI app made with wxWidgets that do some animation. I noticed that when i press on the screen the animation "freezes", the BBB did not update the screen until i leave my finger. This does not happens if i use the mouse instead. Is this somewhat expected? Sep 25 07:37:11 zmatt: yeah, boot script is broken Sep 25 07:37:35 doesn't care about enable_cape_universal Sep 25 07:37:50 it just checks if uboot_base_dtb_univ is set then it goes down that path no matter what Sep 25 07:39:22 Enver: this has been previously discussed on the google group. let me see if i can find it real quick Sep 25 07:40:29 Enver: https://groups.google.com/d/msg/beagleboard-x15/fck_GaOiV_o/tQZoS9spFgAJ Sep 25 07:40:38 and 40mA in DS0 is a joke. Sep 25 07:41:14 Thanks tbr! Sep 25 07:43:44 np Sep 25 07:58:30 thinkfat_: ohh, I thought you meant it was broken as in *broken*, not merely unexpectedly high power consumption Sep 25 07:58:59 thinkfat_: ehm, where are you seeing that? the script looked fine to me when I checked it Sep 25 07:59:20 zmatt: I thought it was broken, because the prompt on the serial didn't come back and the heartbeat led would not blink any more Sep 25 07:59:39 zmatt: but it seems it's some stuff that the bone-univ dtb does Sep 25 07:59:58 zmatt: on my u-boot, I print uname_boot and follow the path down the rabbit hole Sep 25 08:00:19 which u-boot version? Sep 25 08:00:54 there is no mentioning of enable_uboot_cape_universal anywhere and the only way to stop it from loading the universal base dtb is by deleting the environment that refers to it Sep 25 08:01:04 let me check, it's part of the latest iot image Sep 25 08:01:38 U-Boot 2018.03-00002-gac9cce7c6a Sep 25 08:02:11 huh, why would they use such an old version? Sep 25 08:02:57 enable_uboot_cape_universal is definitely being checked in the sources I have here (v2018.09) Sep 25 08:04:14 weird that you're losing the console though, I thought that wasn't touched at all by universal Sep 25 08:05:35 actually the latest v2018.03 patch at rcn-ee.com also checks enable_uboot_cape_universal Sep 25 08:06:13 (file modification date 2018-08-14) Sep 25 08:07:12 only difference between working vs non working is loading bone-uboot.dtb instead of bone-uboot-univ.dtb Sep 25 08:07:21 apart from that it loads the same overlays Sep 25 08:07:29 that's a pretty significant difference though Sep 25 08:07:33 yes Sep 25 08:11:41 also, not sure it's really hitting ds0. Sep 25 08:12:09 shouldn't i see that MPU and PER switch off in /sys/kernel/debug/pm_debug/count ? Sep 25 08:12:16 I have no idea Sep 25 08:12:35 I suspect no, since the kernel isn't doing the switching Sep 25 08:12:42 the m3 firmware is Sep 25 08:13:52 then I suspect that also the message about successfully switching all power domains to target state is incorrect Sep 25 08:14:03 or,. maybe incorrect Sep 25 08:16:21 so why the fuck is there a -univ version of the base dtb anyway, in addition to the universal overlay itself Sep 25 08:17:38 this is so weird Sep 25 08:17:59 it was introduced not long ago I see Sep 25 08:18:26 Jul 31 Sep 25 08:29:29 somebody tried to solve some problem ;) Sep 25 09:53:25 I'm using a BBB with a LCD Cape with Touchscreen, and a GUI app made with wxWidgets that do some animation. I noticed that when i press on the screen the animation "freezes", the BBB did not update the screen until i leave my finger. This does not happens if i use the mouse instead. Is this somewhat expected? Sep 25 10:17:03 parduz: that's a wxwidgets question, not a bbb question Sep 25 10:18:43 it probably depends on how exactly you're doing things Sep 25 10:26:30 zmatt: not sure about this.... how the widgets could know if a mouse event comes from a usb mouse or a touch screen? Sep 25 10:27:33 the animation is not freezing when using a mouse, only when using touch? that is a bit odd Sep 25 10:27:48 that was why i asked Sep 25 10:28:06 at the same time, it has to be the doing of wxwidgets. the touchscreen just generates events, it has no direct influence on anything related to graphics Sep 25 10:28:17 and touch events are most definitely different from mouse events Sep 25 10:29:48 it is not just the animation: i implemented a "long click", which changes a page in my app after 1 second of "mouse down": you can't see the page change until you release the finger, while with the mouse it just happens "under the mouse".... Sep 25 10:31:43 i'd guess the routine that "detect" the touch (that one that compute the position and the "strenght" of the touch) is using too much CPU time ... or there's "too much interrupts" (if any)... Sep 25 10:32:06 that sounds implausible, but should be easy to verify Sep 25 10:33:06 with top Sep 25 10:33:12 for example Sep 25 10:33:27 I remember I had a similar problem with an OMAP5910 ;) Sep 25 10:33:42 but the touchscreen controller was on a bit-banged I2C bus Sep 25 10:33:52 and yes, it was consuming a _lot_ of CPU Sep 25 10:33:57 with udelay Sep 25 10:34:10 if it's literally blocking your process with continuous interrupts then everything will be frozen, i.e. an ssh shell will also be unresponsive Sep 25 10:36:57 well, the green bar on the bottomleft of the LXQT desktop goes to 100% if i press on the desktop Sep 25 10:37:47 there's nothing running other than the OS, right now Sep 25 10:38:19 hmm Sep 25 10:38:50 check with top which processes or kernel threads are taking the high cpu load Sep 25 10:39:05 this still doesn't explain why your application freezes though, one would expect it just slows down Sep 25 10:40:26 it is a 4- or 5-wire touchscreen btw? Sep 25 10:41:02 ok, if i press with the mouse and start to .... shake it very fast, the CPU rises. I'm not as fast the cursor shaking when i press the touch, but could be a clue. Sep 25 10:41:25 it is the 4D LcdCape. Sep 25 10:42:18 gonna get the datasheet to know how mu wires the touch have Sep 25 10:42:20 what's the overlay name? Sep 25 10:43:43 the youtube video suggests a 4wire interface Sep 25 10:43:46 4d seems to have a whole bunch of lcd capes Sep 25 10:43:49 uboot_detected_capes=BB-BONE-LCD4-01, Sep 25 10:43:54 ok Sep 25 10:44:27 https://youtu.be/XAeeDIkQ0Kw Sep 25 10:45:41 yep, that's my cape. Sep 25 10:53:36 uhhhh Sep 25 10:54:03 what? Sep 25 10:54:24 I'm just trying to figure out how the adc is being configured Sep 25 10:54:40 I don't understand why I'm not seeing them configure the sample time anywhere Sep 25 10:55:24 actually, maybe easier: just check /proc/interrupts Sep 25 10:56:08 touch the screen for some fixed amount of time, check /proc/interrupts before and after, calculate the number of interrupts per second while touching the screen Sep 25 10:56:40 ok Sep 25 10:57:30 hm, that is definitely a difference from a mouse... a mouse driver will only give events when you're actually moving the mouse, this touch driver is firing events unconditionally while touched Sep 25 10:57:55 btw which kernel are you using? Sep 25 10:58:37 i'd guess 'cause the driver needs to compute the "strengh" of the touch to determine if the "button" is down or not. Sep 25 10:59:01 pls recall me the command to know the kernel version? Sep 25 10:59:06 uname -r Sep 25 10:59:32 4.9.88-ti-r111 Sep 25 10:59:35 ok Sep 25 11:00:39 well the hardware has detection whether there's any touch at all Sep 25 11:01:45 and then it'll do periodic measurements of the coordinates and pressure, which trigger an interrupt which then cause events to fire Sep 25 11:01:46 uhm. Sep 25 11:02:13 gonna answer a call.... i'll be back in about an hour Sep 25 11:02:36 but the driver could have done some filtering to avoid firing events when nothing has really changed (similar to a mouse), but it has no event filtering at all Sep 25 11:57:49 here i am again. Sorry, zmatt, had to answer that call :| Sep 25 11:58:49 Is the driver the same that R.Nelson patched some months ago? Sep 25 12:29:49 ok, looked at processes with top: without touching the screen, there's "lxqt-panel" at top with %CPU 5.3, then xorg between 3.0 and 5.8. When i press the touch xorg jumps to 48.5 followed by pcmanfm-qt at 35. Sep 25 12:30:24 ok so the problem isn't the interrupts but the flood of events generated Sep 25 12:30:36 have you checked the interrupt rate yet? Sep 25 12:30:51 nope, i'll do it right now. Sep 25 12:40:07 done: https://pastebin.com/vk0ZanCw Sep 25 12:40:16 what should i look? Sep 25 12:40:51 there's around 5 seconds between the before and the after Sep 25 12:42:01 okay that's pretty excessive, around 1600 events per second Sep 25 12:42:12 so it's just sampling way too fast Sep 25 12:43:05 which brings me back to, where the fuck is the sample time being configured to begin with Sep 25 12:43:23 what's the name of the relevant interrupt? Sep 25 12:44:05 TI-am335x-tsc, TI-am335x-adc Sep 25 12:44:19 ok, thnx Sep 25 12:44:29 that's for adc and tsc combined though, maybe check if it's also increasing on its own (without touch) Sep 25 12:44:40 if so, that rate would need to be subtracted Sep 25 12:44:54 or hmm maybe the irqs end up combined, not sure Sep 25 12:45:35 okay so they're just configuring the minimum sample rate Sep 25 12:45:59 didn't change a bit from when i looked before Sep 25 12:46:33 it is still at 243980 Sep 25 12:53:42 hmm based on my calculation the event rate should be a lot lower Sep 25 12:55:14 though still too high Sep 25 12:56:46 better choice of config parameters would probably solve this, plus filtering of redundant events Sep 25 12:57:47 ok.... changing that parameters means recompiling the kernel? Sep 25 12:58:48 i don't know what code you're looking at.รน Sep 25 13:01:09 some of it can be tuned in the dt overlay, but they actually hardcoded a lot :-/ oddly the dt overlay is also setting parameters that don't seem to exist Sep 25 13:01:32 drivers/input/touchscreen/ti_am335x_tsc.c mostly Sep 25 13:55:53 Okay, finished writing a program to query those ethernet MAC memory addresses, and the results I get from it match what I see from ifconfig: the MAC believes it is sending packets and receiving none. What the heck? Sep 25 14:13:25 * n8vi checks his schematic for the fourteenth time looking for backwards wired RX lines ... or something Sep 25 14:14:35 n8vi: clock ... Sep 25 14:14:50 n8vi: who provides it? Sep 25 14:16:44 the PHY Sep 25 14:17:49 Regular MII, not RMII, so, as I understand it, the PHY provides clock for both TX and RX Sep 25 14:18:59 Transmit works fine, I see the frame leave the MAC on one board, and come out the PHY at the other end of the link, the far end MAC just doesn't see it Sep 25 14:26:44 so it's not reporting *any* rx statistics? Sep 25 14:27:58 just shows a bunch of zeros Sep 25 14:28:28 so it's not even receiving garbage, it literally thinks it's not receiving anything Sep 25 14:28:32 hmm Sep 25 14:29:38 logic analyser shows RXDV going high Sep 25 14:29:54 and you didn't forget to hook up rxdv or rxclk to the am335x? ;) Sep 25 14:29:59 did you double-check pinmux? Sep 25 14:30:04 no, and yes Sep 25 14:30:24 which pins are you using, same as on the bbb ? Sep 25 14:30:59 MII1_* Sep 25 14:31:23 on the OSD3358 Sep 25 14:31:38 what about rxerr ? Sep 25 14:31:41 so, let me check the pocketbeagle Sep 25 14:31:51 hmmm Sep 25 14:32:07 MII1_RX_ER Sep 25 14:32:24 I was just looking at RX_ER here, and ... let me see what my hardware guy did here :) Sep 25 14:35:05 n8vi: pocket has MII? Sep 25 14:36:37 oh, maybe not Sep 25 14:36:40 on header? Sep 25 14:36:51 since if your phy doesn't have that signal, it presumably needs to be tied off low, although configuring the pin to a mode other than mii and/or disabling its receiver probably works too Sep 25 14:36:53 we're actually going off the osd3358-red or whatever their reference platform is Sep 25 14:37:05 no, mii not accessible on the pocketbeagle Sep 25 14:37:37 I'll check the muxing on that Sep 25 14:37:39 what phy are you using? Sep 25 14:37:42 puh (guess something missed), on BGA yes, on header no Sep 25 14:38:13 zmatt: https://www.nxp.com/docs/en/data-sheet/TJA1100.pdf Sep 25 14:38:44 (with a kernel patch so linux doesn't freak out about missing capabilities) Sep 25 14:39:25 ah your phy does have rxer, never mind then Sep 25 14:40:42 what about CRS and COL ? Sep 25 14:40:56 since your phy doesn't have those signals Sep 25 14:41:09 I'll check Sep 25 14:41:10 I think? Sep 25 14:41:18 It definitely doesn't have COL Sep 25 14:43:11 So, the phy has a signal called RXDV/CRSDV Sep 25 14:43:21 which we're using the RXDV part of Sep 25 14:43:53 okay, CRSDV is RMII only Sep 25 14:44:12 MII has separate RXDV and CRS Sep 25 14:44:20 from the datasheet " Since Sep 25 14:44:20 100BASE-T1 allows for full-dup Sep 25 14:44:20 lex bidirectional communicati Sep 25 14:44:20 on, the standar Sep 25 14:44:20 d MII signals Sep 25 14:44:24 COL and CRS are not needed. Sep 25 14:44:27 gah, pdf Sep 25 14:44:48 yeah I know, but what did you do with those pins on the am335x side? Sep 25 14:44:53 Checking Sep 25 14:44:56 are they tied low? Sep 25 14:49:12 CRS ... seems to be pulled up, ... COL ... seems to be floating ... okay, I can easily modify both of those Sep 25 14:49:34 I think Sep 25 14:49:54 disabling receiver in pin config should work too Sep 25 14:50:12 it causes the cpu to perceive the pin as being low Sep 25 14:51:14 m Sep 25 14:51:15 okay, I'll try that Sep 25 14:51:21 that's much easier Sep 25 14:51:57 (amusingly that even works for the warm-reset pin, which bizarrely has a pin config register) Sep 25 16:07:00 n8vi: did it work? Sep 25 16:51:04 well, by removing those pins from the dtb, I got the ethernet interface to go away entirely and none of the pins to mus to ethernet Sep 25 16:51:39 let's see what dmesg says Sep 25 16:53:31 looks like nothing Sep 25 16:53:39 Okay, lets revert and see what happened ... Sep 25 17:02:31 hello, I flashed a BBGW with the debian 9.5 image Sep 25 17:02:47 I am trying to speed up the boot time Sep 25 17:03:08 one thing I want to change is de bootdelay to 0 Sep 25 17:03:40 but I am not manage to set this environment variable on the uEnv.txt Sep 25 17:03:48 anyone have any clues Sep 25 17:09:28 Well, apparently updating the device tree caused the units to somehow start booting an old kernel ... that's weird Sep 25 17:33:22 well, now I'm confused. I removed "0x108 0x28 0x10c 0x28 0x110 0x30" from "pinctrl-single,pins" under "cpsw_default", compiled and installed the dtb, and the pins still show being bound to the ethernet subsystem in "show-pins" Sep 25 19:59:52 okay, after discovering some other stupidity I was doing, I'm seeing my RX counters increment on one side, which is good, because I haven't fully fixed the other side yet Sep 25 20:09:05 fully operational Sep 25 20:09:07 whoo Sep 25 20:09:11 thanks for your help again Sep 25 21:38:26 I have a BBG with 4.14.62-ti-r71 kernel in it Sep 25 21:41:00 I have connected adt7516 sensor to it. My goal is remove the platform data from the adt7316 driver and replace those details using device tree bindings. Sep 25 21:42:37 Currently, I am able to probe the driver by instantiating from the userspace. But I am not able to do the same with the device tree bindings. Sep 25 21:46:00 I've added the following lines in am335x-bonegreen.dts adt7516@4b { compatible = "adi, adt7516"; reg = <0x4b>; interrupt-parent = <&gpio3>; interrupts = <26 8>; ldac-gpio = <&gpio0 20 GPIO_ACTIVE_LOW>; }; Sep 25 21:47:43 I compiled the file am335x-bonegreen.dts with the make command which in return generated a dtb file. I copied that dtb file into the /boot/dtbs/uname-r/ Sep 25 21:49:46 And then I rebooted BBG. Did modprobe adt7316. Checked with lsmod. But dmesg doesn't show probing of the driver. Sep 25 21:50:40 Any idea that where I am going wrong or any suggestions? Sep 25 23:24:32 GenTooMan: Hello! Sep 25 23:24:49 Do you know anything about the Sabertooth 2 x 12? Sep 25 23:26:07 Sabertooth: S1 | P9.24 :BBGW Sep 25 23:26:10 and... Sep 25 23:26:30 SaberTooth: S2 | P9.26 :BBGW Sep 25 23:26:40 I am using UART! Sep 25 23:28:03 ... Sep 25 23:28:18 If you are interested in looking, please view this idea: https://www.hackster.io/silver2row/sabertooth-2-x-12-bbgw-motor-bridge-cape-6f6115. Sep 25 23:32:33 The different software examples work at times but not 100% like expected. Sep 25 23:32:34 ... Sep 25 23:33:28 I think it has something to do w/ a poor serial connection from their library/module, i.e. https://github.com/MomsFriendlyRobotCompany/pysabertooth. Sep 25 23:33:30 ... Sep 25 23:33:59 "poor" = some odd errors Sep 25 23:43:53 set_ no I don't know a thing about sabertooth, is there serial API available IE can you directly twiddle the motor through hand typed stuff? Can you reset the thing (IE hit it with a hammer) with an IO? Sep 25 23:44:10 Yes. Sep 25 23:44:12 To all! Sep 25 23:44:19 No issue. Sep 25 23:44:43 I will not bother you w/ my fun in the Sun stuff. Sep 25 23:45:14 It has a microcontroller on it and a couple of switches to reset things. Sep 25 23:45:26 I got some motors to turn so far. Sep 25 23:45:32 ... Sep 25 23:45:52 The motors do not stop and then turn the other direction like I figured they would. Sep 25 23:46:44 I have /dev/ttyO1 working w/ it so far. Sep 25 23:47:20 Their library deals directly w/ a USB connection from a larger model of the 2 x 12. Sep 25 23:47:43 But...very similar. Just w/ larger caps and the extra USB connection. Sep 25 23:48:24 At first, I thought it was the BBGW and my connections to the P9 header. Sep 25 23:48:59 I know now...it is most likely a mix of communication errors from the am335x and their Atmel AVR. Sep 25 23:49:18 <<< my issue so far Sep 26 00:12:48 I got it. Scratch what i typed. Sep 26 00:17:33 I needed to use packetized serial from that Atmel thing to communicate w/ the am335x on the BBGW via UART! Sep 26 00:17:35 Boy! Sep 26 00:45:46 I have just installed the default standard image on my new beaglebone black. When I ssh to it, it prompts me for a login name and password. What should these be? Sep 26 00:46:22 The image name is Debian 9.5 2018-08-30 4GB SD IoT Sep 26 00:47:44 I know! Sep 26 00:47:48 debian temppwd Sep 26 00:48:29 I just ate like 15 dehydrated bananas and I can answer now! Sep 26 00:48:36 What else do you need? Sep 26 00:50:01 Thanks! it worked. I thought it'd have been documented somewhere, but couldn't find it. This really helps given I am to use the board as a computer! Sep 26 00:50:43 Oh. Sep 26 00:50:55 Yea. You should look here: bbb.io Sep 26 00:51:29 They have plenty on stuff but if you go to the section on latest-images and click on "more info," you can see the Wiki. Sep 26 00:51:50 The Wiki section has some extra info. Sep 26 00:52:22 bbnewbie: What are you trying to do w/ your board? Sep 26 00:53:16 Thanks you! That's the page I have been looking for. Sep 26 00:53:21 Oh. Sep 26 00:53:29 That is nice! Sep 26 00:53:57 I am going to use it as test server for running some python scripts Sep 26 00:54:03 Cool! Sep 26 00:54:10 I do that at times, too. Sep 26 00:54:51 Nice. Good to know I am not the first to do so :) Sep 26 00:54:56 Actually, all I do right now is run software languages on my BBB and the other varations to promote movement and/or servers. Sep 26 00:55:06 Definitely not! Sep 26 00:55:36 I am trying to find cust. to serve in reality. It is not easy. Sep 26 00:56:10 I have to get good and fast at working w/ the BBB first. So, this way I will not make mistakes when promoting myself and ideas. Sep 26 00:56:25 Any tips on running python on the BB? Is it straightforward? Sep 26 00:56:55 Ya! Adafruit_BBIO...this is a good library to work w/, plus they have helped people. Sep 26 00:57:13 They help w/ issues that arise from their library. Sep 26 00:57:48 I just created a new issue w/ a UART question. Sep 26 00:58:34 I think my version is out-of-date b/c of what I use it for outside of UART functionality. Sep 26 00:59:04 I use 1.0.3 instead of their updated version, i.e. 1.0.10. Sep 26 00:59:05 Thanks! Let me now go explore a little - I might come back with more questions later :D Sep 26 00:59:10 Otay! Sep 26 00:59:33 Thank you very for the help! Much appreciated. Sep 26 00:59:42 No issue at all. Sep 26 00:59:52 I only know so much, though. **** ENDING LOGGING AT Wed Sep 26 03:00:00 2018