**** BEGIN LOGGING AT Mon Feb 25 02:59:57 2019 Feb 25 03:00:41 Do you know if I will be able to install Python 3.6 on the IoT version? Feb 25 03:01:11 I will find a micro HDMI cable so I can see what's going on. Feb 25 03:01:32 dpe: huh, what's weird Feb 25 03:01:48 dpe: it might be a problem with the sd card? Feb 25 03:01:52 the iot image is known-good Feb 25 03:02:08 oh wait, you can boot from it, but it won't flash? Feb 25 03:02:28 wait no, that can't possibly make sense Feb 25 03:02:50 and python isn't particularly big, the lxqt image is just really bloated Feb 25 03:03:12 plus it's possible that you're pulling in additional dependencies (e.g. updates of packages) Feb 25 03:04:19 actually, what did you do to be able to install python3.6 ? did you add buster as additional repository? Feb 25 03:08:10 because if so, you could also try the latest buster-iot testing image: https://rcn-ee.com/rootfs/bb.org/testing/2019-02-24/buster-iot/ Feb 25 03:09:16 (bone-*.img.xz is for booting standalone from sd, BBB-blank-*.img.xz is a flasher image) Feb 25 03:12:25 I discovered that the uEnv.txt file flash command was still commented out. I was confused about the sd card as a device and actually mounted it before editing the file. I thought I had to do that. Maybe I wasn't actually editing the real file? In any case I'm flashing right now. My whole purpose is to load the Python CAN library and it would not load in Python 2 Feb 25 03:14:05 did you cut power immediately after editing the file? Feb 25 03:14:26 okay but you said python3.6 .. debian stretch ships with debian 3.5 Feb 25 03:14:34 *python 3.5 Feb 25 03:15:05 Yes. Very soon after. Is there an Un-mount that I should have done? Feb 25 03:15:07 also, you're saying python3 isn't installed by default? that's odd Feb 25 03:15:54 either power off using the 'poweroff' command, or cleanly unmount and then wait a bit, or at the very least use 'sync' before cutting power Feb 25 03:16:54 cutting power to eMMC or (especially) SD cards while data is being written to them can also cause unpredictable corruption (including to unrelated data on the same device) Feb 25 03:18:04 Python 2 is installed but I wanted the CAN library. But then I had to first install pip, the finally the CAN, but it did not finish because it could not find a particular item (as I recall something like windows curses). So I found that Python 3 comes with the CAN already installed. Feb 25 03:18:30 I know python2 is also installed, but I would have assumed python3 is also installed Feb 25 03:18:43 python2 should be avoided nowadays Feb 25 03:18:52 As I was installing Python 3 I ran out of space. Feb 25 03:18:55 (by "nowadays" I mean "for many years now already") Feb 25 03:19:09 you were doing "sudo apt install python3" ? Feb 25 03:19:24 Is there a beter OS release that has 3 already included? Feb 25 03:20:27 uhh, I just checked, the debian stretch images (at least the iot image, but I presume the lxqt one too) already has python3 installed, including pip3 Feb 25 03:21:38 So how come "python --version" shows version 2? Feb 25 03:22:36 because "python" is a symlink to "python2" for backwards compatibility reasons Feb 25 03:22:43 if you want python3, use python3 Feb 25 03:23:05 now I'm also curious what you were doing to try to install python3 Feb 25 03:23:12 since it was already installed Feb 25 03:23:35 yikes! duh ... python3 Feb 25 03:23:46 likewise if you want to use pip, use "pip3" Feb 25 03:24:06 I found a site with a lot of instructions for installing python3 on Debian. Feb 25 03:24:16 a lot of instructions? o.O Feb 25 03:24:46 the instructions for installing python3 on debian is "sudo apt install python3" (after doing "sudo apt update" once if you haven't done so within the last day or so) Feb 25 03:25:13 # sudo apt-get install -y make build-essential libssl-dev zlib1g-dev Feb 25 03:25:21 # sudo apt-get install -y libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm Feb 25 03:25:26 wtf Feb 25 03:25:29 # sudo apt-get install -y libncurses5-dev libncursesw5-dev xz-utils tk-dev Feb 25 03:25:34 also please don't paste multiline stuff into chat Feb 25 03:25:41 sorry Feb 25 03:25:45 just give a link, or use a paste service site like pastebin.com Feb 25 03:25:58 but that sounds like you were trying to build it from source code Feb 25 03:26:01 why would you want to do that Feb 25 03:26:10 :D Feb 25 03:26:29 Thought I was doing the right thing. Next time I will ask for some help first. Feb 25 03:26:52 on the bright side, reflashing to the iot image is probably a good idea anyway Feb 25 03:27:25 you probably don't want a desktop environment on the bbb, so using the lxqt image just means you waste a lot of space and probably slow down boot Feb 25 03:28:01 Thanks for the help. I really appreciate it. I'm going to see if I can get somewhere with the Python3 Feb 25 03:29:18 yeah, the fact that "python" still points to the (obsolete, unmaintained) python2 is pretty unfortunate and annoying, even though I understand the backwards compatibility argument Feb 25 03:29:30 it does seem that debian is finally working on transitioning Feb 25 06:55:42 Hi I have a question on beaglebone blue Feb 25 08:23:38 Hi. I was planning to apply for GSoC 19 and was going through some of the ideas mentioned on the website. I was wondering if I can also choose projects which are not so system/kernel oriented. I was planning to create a motion capture suit using multiple IMUs. Feb 25 08:54:30 anant3110: Hi ! The fundamental requirement is: the deliverables should be significantly helpful to the community and should "mostly" involve software. Try discussing the idea on mailing list and/or on #beagle-gsoc. Feb 25 09:50:25 So, most of my contribution will be on the software side, and I would be writing libraries for different components available in the market. Should I write it as a proposal to the mailing list to get some validation before hand? Feb 25 10:14:59 anant3110: Sure. Go ahead. Feb 25 10:19:16 zeekhuge[m]: Thanks! **** BEGIN LOGGING AT Mon Feb 25 10:59:24 2019 Feb 25 13:54:51 Hi All, someone has experience with brcmfmac driver, please? Feb 25 13:55:30 I'm trying to setup cyw4343 with custom board based on Octavo Feb 25 13:56:59 I believe that the device tree is correct, when I load brcmfmac.ko I get these messages: Feb 25 13:57:25 https://pastebin.com/raw/7bv7PspK Feb 25 13:57:28 any idea? Feb 25 14:35:28 kros, been getting that same issue on both am335x and am57xx based devices.. i've had better luck with the brcmhd driver. (which also barely works..) supposly someone at cypress is looking at our sdio interface.. Feb 25 14:53:52 rcn-ee, many thanks for your reply. I'll try both brcmhd driver and contact cypress. I'm determined to set this up, this is the smallest wifi chip we could find, anything else wouldn't fit in the required PCB size... Feb 25 14:54:39 From the log file, can I conclude that the soldering is correct? It seems that driver is able to detect chip version, so I assume this is all good. Feb 25 15:00:51 it's the sdio interface, ti's interface needs everything setup in a specific mode/etc, whereas brcmfmac can support many types.. Feb 25 16:41:57 https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/?fbclid=IwAR1-hvy9PqGqnCXg_xngqOseWJ7Gue-oDZJw8oc3Yaab87AaTSaNrJQ5CDI Feb 25 16:42:06 software fix to phy issue eh Feb 25 16:48:10 pretty creative Feb 25 16:48:17 found a reserved bit that indicated ethernet status Feb 25 16:49:04 and using the RTC alarm to restart Feb 25 17:37:03 yeah, very bad idea Feb 25 17:40:23 SYS_5V will remain active, and VDD_3V3B too (as a result of the VDD_3V3B regulator enable issue), which means various components on the bbb itself as well as any cape connected will remain powered Feb 25 17:40:38 but the I/O supply of the am335x itself will go down Feb 25 17:42:00 so if any of the connected components tries to drive a pin of the am335x high, you've got a great situation for frying that I/O Feb 25 17:46:04 when I was doing power-related tests with the bbb I once accidently ended up in that same configuration (board powered off but with SYS_5V and VDD_3V3B still active) while having a serial cable connected to the debug console port, which caused the uart buffer (powered from VDD_3V3B) to drive about 45 mA into the UART0_RXD pin Feb 25 17:47:05 this also caused VDD_3V3A to be lifted more than 2V above the 1.8V supply, a situation the am335x datasheet repeatedly and emphatically warns should be avoided under all circumstances Feb 25 17:49:43 so, yeah, don't do that Feb 25 17:59:44 did it fry? Feb 25 18:00:58 fortunately it seemed to have survived okay, but the scope traces looked pretty scary Feb 25 18:03:50 especially since there seemed to be a sudden surge of some sort once vdd_3v3a got more than 2v above the 1.8v supplies... I wonder if a latch-up or something like that happened, but the potential for damage was limited because there wasn't much power available (just whatever was injected via the protection diode of the UART0_RXD pin) Feb 25 18:04:31 https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/V1Ft-xxh0agJ (fourth image) Feb 25 19:08:27 well i wonder if the technique in that block can't be extended in such a way as to be useful Feb 25 19:09:08 i realize that the components on the bbb itself can be tricky but the cape you should be able to keep gated off during the process, design permitting Feb 25 19:18:45 if you have a cape connected to the beaglebone, you could probably also fix the issue by adding a tiny reset ic that keeps the reset line asserted for some time after power up (longer than it currently does on the bbb), and maybe add a bit more pull-up to the reset line Feb 25 19:50:52 That wouldn't address the on-board peripherals tho Feb 25 19:52:36 or maybe it would? Feb 25 19:52:49 if those are attached to the reset line, i'm not sure Feb 25 20:14:53 the ethernet phy is attached to it, that's the whole cause of the problem Feb 25 20:15:20 if the ethernet phy's reset had been connected to a gpio, the problem wouldn't exist Feb 25 20:21:56 my phone is bricked Feb 25 20:22:05 in a very hardware way, the SoC popped off the motherboard Feb 25 20:22:29 it's a bad hardware design, the uneven heat distribution makes it bend or something Feb 25 20:22:50 anyway I assume that's the problem, since people report it a lot for this model Feb 25 20:25:42 some sources suggest using a heat gun on it Feb 25 23:10:43 Hello, I am trying to validate ethernet throughput performance of the BBB and the Beaglebone Enhanced boards, and I have noticed that the performance is significantly worse when I apply power over USB (~50-90 Mbps max UDP) than when I apply power over an AC adapter with 5V output (~150 Mbps max UDP). The problem is that if the USB cable is plugged in after the 5V input (at boot or sometimes after boot), then I see low performance. Feb 25 23:12:22 baglebone: huh, that sounds odd Feb 25 23:13:10 this is using the latest debian image? Feb 25 23:14:23 This is using Debian 9.5 Feb 25 23:17:42 I see references online that the TPS65217 power management chip should automatically prioritize the 5V input over the USB 5V, but I'm not totally sure how to test this yet Feb 25 23:19:26 it should yes, but even if it doesn't then that still has absolutely zero reason to affect performance in any way at all Feb 25 23:25:10 I see this reference from Hacking and Penetration Testing with Low Power Devices By Philip Polstra: "It should be noted that when powered by the USB client port, the CPU speed is limited to 500 MHz" Feb 25 23:25:32 Referring to the BBB CPU speed when powered over USB Feb 25 23:25:41 uhh, nope Feb 25 23:26:38 maybe there are beaglebone OS images, past or present, that have some setup to arrange that (for whatever reason), but I've never seen that happen Feb 25 23:26:55 check with cpufreq-info Feb 25 23:27:04 So it's not expected to see any performance change from USB power vs. external 5V input? Feb 25 23:27:54 no, it would require some misguided piece of software actively changing the power management configuration in reaction to pmic events Feb 25 23:28:16 the BBB wouldn't require more than 500mA ? Feb 25 23:28:22 like the rpi does Feb 25 23:28:27 the latest anyway Feb 25 23:29:52 generally it doesn't, but also the pmic config is changed (during early boot) to allow more than 500 mA, since in practice people may be using usb chargers to power the bbb and many usb ports nowadays also tolerate drawing more current Feb 25 23:30:12 hold on, I have an usb current measurement thingy Feb 25 23:35:19 during boot I've seen it peak to just over 0.4 A when it was really busy, and now it's settled to around 0.2 A Feb 25 23:35:53 cpufreq-info reports the "performance" governor is used, i.e. cpu frequency is fixed at 1 GHz Feb 25 23:36:37 I see, yeah I tried cpufreq-info for USB power vs. 5V 2A input and they both show 1 GHz Feb 25 23:37:11 I heated the processor of my phone with a blowtorch Feb 25 23:37:18 you can tell this is the last attempt before the bin Feb 25 23:38:34 nah, too much thermal stress. You need to heat the whole phone evenly with the blowtorch. Feb 25 23:38:54 Does anyone have ethernet throughput performance numbers for the BBB powered over USB? Feb 25 23:39:03 I was about to try that Feb 25 23:39:17 Thanks! Feb 25 23:45:55 the processor under the shield I heated fell off, artag Feb 25 23:45:58 allegedly Feb 25 23:47:33 baglebone: I'm not seeing any difference, using wget to download a file (to /dev/null) from a server on my LAN saturates the link (11.2MB/s) regardless of how I power the beaglebone Feb 25 23:48:15 pretty close to the theoretical limit Feb 25 23:48:34 indeed Feb 25 23:49:34 baglebone: for usb-powering, are you using an usb charger or a computer? Feb 25 23:50:04 in the latter case, is there any chance you're accidently testing via the usb networking interface instead of ethernet? Feb 25 23:53:40 I am using a computer but I am testing using the assigned ethernet IP address with Iperf Feb 25 23:56:54 I'm just trying to think outside the box :) since there's really no plausible way for the difference in power source to have a performance impact (except if software were to change e.g. cpufreq settings for some reason, but you already checked that) Feb 25 23:57:15 there's one. RFI. Feb 25 23:57:29 if the power supply is noisy (or something nearby is) in RFI, the USB cable could be receiving spurious radio signals Feb 25 23:57:41 that could possibly result in packet retransmission Feb 25 23:57:45 it's a bit of an edge case but it is possible Feb 25 23:57:52 can you try a different-length USB cable? shorter is better. Feb 25 23:57:53 does iperf not report dropped packets? Feb 25 23:58:07 I'm not sure. ping obviously does, and mtr. Feb 25 23:58:41 also if packets are being corrupted, that would show up in the ethernet link statistics (ip -s link show eth0) Feb 25 23:59:20 indeed. Feb 26 00:01:08 my theory could be ruled out pretty easily. Feb 26 00:01:12 or ruled in as a definite possibility. Feb 26 00:02:26 I bought a new phone, but I have to live without any phone for 1 week now Feb 26 00:03:48 life is harsh Feb 26 00:04:42 I've always kept a spare phone, ever since I started using GSM, but luckily I've never needed one except for using prepaid sims abroad Feb 26 00:08:28 the issue I had is known to the manufacturer, there has been a class action in the US about it Feb 26 00:08:31 but I'm french Feb 26 00:08:39 so no free new smartphone for me Feb 26 00:09:09 dommage Feb 26 00:09:41 that's annoying Feb 26 00:43:54 god the iot image boots soo slow /o\ Feb 26 00:44:24 I'm used to our own beaglebone images that are mostly up in 5-10 seconds Feb 26 00:48:23 lol Feb 26 00:55:35 ahh, initramfs still has the udev rules from the old bb-customizations package version I think, i.e. before rcn applied my fixes Feb 26 01:08:58 https://pastebin.com/raw/LTdAuEKx some boot times, for comparison Feb 26 02:11:05 my blowtorch reparation seems to have worked Feb 26 02:11:06 it's been on for around 2 hours now Feb 26 02:11:06 without freezing Feb 26 02:11:06 but I disabled the perf cluster from the big.LITTLE thingie to be sure Feb 26 02:11:12 while trying for the new phone Feb 26 02:11:15 while waiting* **** ENDING LOGGING AT Tue Feb 26 02:59:57 2019