**** BEGIN LOGGING AT Mon Apr 26 03:00:18 2021 Apr 26 04:49:29 mattb000ne: your description sounded more like the board was booting fine but ethernet wasn't working? have you tried resetting/power-cycling the board? Apr 26 04:50:05 since it's a known issue that the ethernet phy is sometimes confused on the bbb Apr 26 05:15:39 i tried Apr 26 05:15:43 no dice Apr 26 05:15:52 I am going to get my serial cord and see where it gets stuck Apr 26 05:16:00 and try a different ethernet cable Apr 26 05:16:36 if there's led activity and after a while you have power led on + usr0 led blinking in a heartbeat pattern that sounds to me like it booted successfully Apr 26 05:16:54 yeah it looks totally normal Apr 26 05:17:13 just never gets recognized by the computer with the ethernet connection Apr 26 05:17:19 or as a device Apr 26 05:18:04 not sure what you mean by that Apr 26 05:18:28 normally i get a blip just connecting the BBB to my laptop with just the usb Apr 26 05:19:17 ah so it's not detected as usb device? Apr 26 05:19:23 no Apr 26 05:19:28 but you're additionally having problems connecting to it via ethernet? Apr 26 05:19:32 yes Apr 26 05:19:40 just solid lights Apr 26 05:19:45 on the port Apr 26 05:19:55 no blinking like normal Apr 26 05:20:19 this is a new bbb right, you reflashed it with the latest image? Apr 26 05:20:24 yes Apr 26 05:21:08 when you plug ethernet in after it has "booted", you're not seeing any network activity (green ethernet led blinking) ? Apr 26 05:21:23 only thing i can think of is it may of gotten damaged when I was testing the pins Apr 26 05:21:28 on the logic shifter Apr 26 05:21:33 the green light will flash once Apr 26 05:21:36 thats it Apr 26 05:21:42 orang light is on and just stays on Apr 26 05:21:46 your hypothesis doesn't sound likely Apr 26 05:22:05 well it chirped but never powered off Apr 26 05:22:13 ? Apr 26 05:22:25 usually when I fry a board it will do that disconnect chirp Apr 26 05:22:31 that is when I know I am in trouble Apr 26 05:22:45 it did a chirp but not sure why Apr 26 05:23:19 since then this behavior so I am pretty sure i did it but not sure how since I had my multi meter and was just trying to see what was going on with the logic shifter Apr 26 05:23:31 since it works fine on the osciloscope Apr 26 05:24:38 thing is, damaging an I/O can really only have three outcomes: 1. no observable problem 2. problems with the affected I/O 3. complete failure of the board Apr 26 05:25:10 there isn't any sort of mechanism via which it could result in a system that seems to boot but has network connectivity problems Apr 26 05:26:24 hmm Apr 26 05:26:37 anyway, monitoring the serial console sounds like a good idea Apr 26 05:26:42 let me paste bin the serial output give me a bit to get my cord Apr 26 05:27:31 and maybe just in case measure the voltage of the 3.3V supply Apr 26 05:38:33 Hello all. I've been out for a while. Wanted to ask about the upgrade instructions at https://beagleboard.org/upgrade which say to do 'sudo apt install -y ti-tidl mjpg-streamer-opencv-python'... It used up a lot of space on my device and I don't know why I need it. Apr 26 05:39:56 well that page seems to be BeagleBone AI specific Apr 26 05:40:27 and it also seems old, judging by the fact it seems to be about debian stretch Apr 26 05:41:43 so my guess would be that it was intended as something to link to to get the beaglebone AI from whatever software state it was shipped it to one where the TIDL demo is working Apr 26 05:42:09 Thanks. I kinda figured it wasn't needed but regardless, I figured I would ask Apr 26 05:42:24 usually the recommended way to upgrade the system is to just reflash the latest image Apr 26 05:42:49 (latest release images: https://beagleboard.org/latest-images latest testing images: https://elinux.org/Beagleboard:Latest-images-testing ) Apr 26 05:44:51 Yep I'm using the latest IoT image from that page - the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" specifically on a BB Black, although I probably could have used the console version just the same Apr 26 05:45:10 whelp need to hunt down my serial cable not where I thought I left it Apr 26 05:45:11 doh Apr 26 05:46:02 handojin: yeah the IoT image is the "official" image, which includes a ton of stuff like the nginx webserver, cloud9 web-based ide, bonescript, node-red Apr 26 05:46:21 handojin: while the console image is a fairly minimal debian system intended for people who are comfortable just installing whatever packages they want Apr 26 05:46:36 Yep and last time I did this (last year'ish) I noticed a lot of the node stuff was broken Apr 26 05:47:06 Other matt, not sure if this is helpful but I had a BB Blue with bad eMMC. it behaved badly but only after some uptime. Eventually worked it out and replaced the board Apr 26 05:47:31 I don't exclude the possibility of the node stuff being broken, I use none of it myself so I wouldn't notice Apr 26 05:47:52 that sounds odd, never heard of such a thing before Apr 26 05:48:01 Sure, and after a while you just write your own, but the nodered stuff is nice for beginners Apr 26 05:48:31 the only kind of failures I've ever seen with eMMC were due to wear-out Apr 26 05:49:15 This was brand new board. Luckiliy I had others around to compare, but what ultimately gave it away was many house of uptime on SD card vs eMMC crashing Apr 26 05:49:15 (generally resulting in the eMMC becoming inaccessible, either immediately after boot or upon the first attempted write) Apr 26 05:49:33 so you had like, bit errors from the eMMC ? Apr 26 05:49:52 Yep totally. I would have expected a definitive and immediate failure of the eMMC, but go figure Apr 26 05:50:06 yep, lemme check my notes Apr 26 05:50:47 "I ran badblocks and dd to verify while booted to SD card, and it does not show anything wrong with the eMMC, but I can't see what else it could be." Apr 26 05:50:54 one thing to beware of with NAND flash (especially MLC/TLC), whether "raw" or in "managed" form such as eMMC or SD, is that data can become "unstable" if power loss happens during write Apr 26 05:51:39 meaning it might sometimes read wrong, but not consistently Apr 26 05:52:05 Good to know. I know, so much easier to figure out of it happens consistently Apr 26 05:52:23 that should however be fixed if it is subsequently overwritten Apr 26 05:52:41 anyway given the price (and I got a free replacement) it didn't make sense to spend any more time on it. the new board worked perfectly :) Apr 26 05:52:46 so like, wiping and reflashing the eMMC should solve any such problems Apr 26 05:53:58 this in constrast to wear-out, which can cause parts of the storage to be permanently unstable. I have an SD card where some pages are basically random number generators: each time you read them you get different data Apr 26 05:54:39 wow interesting Apr 26 05:55:50 I haven't observed anything like that with eMMC yet, so far they've always just gone "dead", but only upon access or upon write, as if the firmware in the eMMC crashes or just fails some check that doesn't have better error handling than going into a deadloop Apr 26 05:56:13 perhaps if the eMMC weren't the cheapest available on the market you'd get more useful errors Apr 26 05:56:41 ha! truth. Apr 26 05:57:16 Thanks for your help. Very nice of you. Apr 26 05:57:18 I know fancier eMMC also gives health indication that estimates how far along the wear-out is Apr 26 05:59:44 our strategy for dealing with wear out has been to reconfigure the eMMC into pSLC mode (which cuts disk space in half but improves performance, lifetime, and tolerance to power failures) with "reliable writes" enabled (to improve tolerance to power failures, presumably at cost of performance though when combined with pSLC its performance benefits seems to outweigh the performance loss of reliable ... Apr 26 05:59:50 ...writes) Apr 26 06:00:10 and on the software side eliminate anything that writes to eMMC unnecessarily Apr 26 06:01:24 I think so far we've only seen eMMC dying to wear-out on some devices that were affected by a bug in our software that caused iirc about 16 GB/h of continuous writes :P Apr 26 10:18:26 BeagleV on my desk Apr 26 10:18:43 is your desk enjoying it? Apr 26 10:19:07 I didn't think to ask Apr 26 10:20:05 it has an enormous heatsink and fan Apr 26 10:23:46 interesting, is it that high-performance or just very inefficient? ;) Apr 26 10:24:18 I'm guessing power management isn't working (yet?) Apr 26 16:22:51 hello, I am trying to figure out how to read and set the values of the GPIO pins of the beaglebone black at runtime. I posted in here last week, and zmatt helped me out, suggesting that I rename the GPIO pins as follows: Apr 26 16:22:52 https://pastebin.com/qZZmQQQg Apr 26 16:23:17 and then read them as follows: Apr 26 16:23:17 https://pastebin.com/n54hkvw8 Apr 26 16:23:40 initially I thought it was working for me, but the second command in the first link returns an error on my beaglebone: Apr 26 16:24:12 -bash: ATTR{label}!=sysfs,: command not found Apr 26 16:24:21 I tried googling around, but I'm not really sure what this means Apr 26 16:25:12 the subsequent code isn't working for me either, but I assume it's because this first command didn't go through Apr 26 16:25:18 any ideas? Apr 26 17:21:13 Hi , Apr 26 17:22:02 I would like to find out if some one have experience to share how to configure spi driver support for yocto build? Apr 26 17:23:19 also for sancloud build does anyone was able to setup linux version ? Apr 26 17:36:39 john_doe: https://pastebin.com/qZZmQQQg are not shell commands, it's an udev rule Apr 26 17:37:56 john_doe: save it as /etc/udev/rules.d/gpio-symlinks.rules then do "sudo update-initramfs -u" and reboot Apr 26 17:38:24 then you'll have symlinks for gpios in /dev/gpio/ Apr 26 17:45:12 john_doe: and here's three versions of a trivial python lib for accessing gpios: https://pastebin.com/1UCnbVNT Apr 26 17:51:51 Hi, Good-Afternoon, I flashed BBBw with pre-build image, and updated and installed more deb packages. The new system is on EMMC flash. Is there a way to create an image of the customized system into new pre-build image, so I can easily to duplicate is for production? Apr 26 17:56:38 tiger: /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh sounds like it's what you're looking for (but I've never used it myself) Apr 26 18:01:26 zmatt that seems to be working, thanks! Apr 26 18:01:44 I'm able to set and get the values based on the english names I gave them in the configuration file, which is nice Apr 26 18:02:05 yep that's the whole point of the udev rule Apr 26 18:05:48 awesome Apr 26 18:05:50 good idea Apr 26 18:15:21 tiger also I was able to back up a boot image on an SD card, then duplicate that image to another SD for production, as you say Apr 26 18:15:35 although I didn't use the EMMC, so it's not exactly the same Apr 26 18:15:45 I followed these instructions: Apr 26 18:15:47 https://beebom.com/how-clone-raspberry-pi-sd-card-windows-linux-macos/ Apr 26 18:26:25 Thanks guys. The problem I have is there is no SD card on our production boards. Apr 26 18:26:46 how are you flashing then? Apr 26 18:27:23 via usb? Apr 26 18:27:25 I uses micro usb using BelenaEcther to flash Apr 26 18:28:03 ah it supports that natively nowadays? I don't suppose they already include a way to make an image instead? Apr 26 18:28:36 since the underlying tool makes the eMMC accessible as block device, which means you can also make an image from it Apr 26 18:29:33 Detailed steps for making image from block device? Apr 26 18:32:17 dd if=DEVICE of=filename.img bs=4M Apr 26 18:33:02 Thanks, let me try Apr 26 19:55:16 Hi everybody, I am looking for a Wifi to USB module as Access Point for my PocketBeagle. Is there a list of supported devices? I tried some of the Realtek rtl8192cu (driver) devices but unfortunately they didn't work. Apr 26 19:55:16 Do you have a recommendation for me, which module works out of the box? Apr 26 19:56:58 this list might be of use: https://elinux.org/RPi_USB_Wi-Fi_Adapters Apr 26 19:57:54 usb wifi sticks on linux are generally speaking a headache Apr 26 20:03:31 zmatt thank you very much for the fast response! Apr 26 20:03:31 It is indeed a headache. The reason I need one is for my drone which I plan to control via Wifi. Apr 26 20:03:32 As I see in your link, I think that the Ad-Hoc mode would fit better. Do you agree? Apr 26 20:03:54 ad-hoc is deprecated/dead Apr 26 20:04:46 rarely supported Apr 26 20:06:00 Good to know. Thanks! Apr 26 22:31:09 Hi, have some issues getting a SPI UART (MAX14830) up and running on a BBB with U-Boot 2019.04-00002-gc9b3922522 / Debian Buster IoT Image 2020-04-06 (4.19.188-bone64). I probably shouldn't flood this channel with all details, so is this question best asked on beagleboard@googlegroups or on DigiKey TechForum? Apr 26 22:33:23 (As a teaser: I think I'm almost there, but /dev/ttyMAX doesn't show up :) Apr 26 22:43:01 go ahead an ask the questions, but wait around a good long while for a response Apr 26 22:43:39 as mentioned in the topic for the channel Apr 26 22:46:18 RobertStaven: why did you replace the -ti series kernel with a -bone series kernel? Apr 26 22:49:22 and share (using a paste service like pastebin.com) the overlay you're using to get this thing working Apr 26 22:55:10 zmatt: is there a quick way to stream the serial connection to a file Apr 26 22:55:15 got my cord Apr 26 22:55:26 zmatt: Hmm.. The Debian Buster IoT Images uses -ti series? If so it is an unintentional 'error' by me, getting up to data with the new U-boot overlay has been a bit challenging, I probably choose the wrong kernel while installing/updating bb.org-overlays Apr 26 22:55:27 it seems it is stuck in a boot loop Apr 26 22:57:01 RobertStaven: how would updating that affect the kernel? why did you feel a need to update that anyway? Apr 26 22:57:39 mattb0000ne: uhh, does whatever program you're using to monitor the serial port not have a logging feature? otherwise just copy/paste to pastebin Apr 26 22:58:33 RobertStaven: and yeah the -ti kernel series has been default for a long long time now Apr 26 22:59:57 it looks like getting that uart working should be fairly straightforward Apr 26 23:00:42 what are you using as clock source? Apr 26 23:01:13 I'll collect the essential info and put it on pastebin.. brb Apr 26 23:01:55 https://pastebin.com/zfhairBT Apr 26 23:02:14 seems my files are corrupted Apr 26 23:02:41 mattb0000ne: looks like filesystem corruption indeed Apr 26 23:02:55 am I hosed far as recovering Apr 26 23:03:05 that is sooo weired Apr 26 23:03:35 that sucks Apr 26 23:03:42 i guess it is better than a dead board Apr 26 23:03:53 you can try e2fsck -y /dev/mmcblk1p1 and hope for the best Apr 26 23:03:53 so I am techincally still on board 5 which is a plus Apr 26 23:04:52 then reboot Apr 26 23:05:26 what did it produce as output? Apr 26 23:05:39 said file system was modififed Apr 26 23:05:46 that's it? Apr 26 23:05:59 it worked Apr 26 23:06:06 laptop sees the bone Apr 26 23:06:06 presumably it output more than that Apr 26 23:07:09 with filesystem corruption severe enough to result in a boot failure like this, you may want to just make a backup of your files and reflash the eMMC Apr 26 23:07:41 depending a bit maybe on what the output was from manually running e2fsck Apr 26 23:12:16 zmatt: https://pastebin.com/mSB8ziZR Apr 26 23:12:16 The MAX14830 have a separate xosc on 16MHz, and connections seem to be OK as boot doesn't report seeing wrong ID on chip. Apr 26 23:12:28 yeah i am trying Apr 26 23:15:57 status="disabled"; doesn't work on spi bus devices (annoyingly), either disable cape-universal or give your spi node the same name as the existing one declared by cape-universal Apr 26 23:16:02 also your clock declaration makes no sense Apr 26 23:17:35 also the -00A0 suffix for custom (non-cape) overlays is a historical thing, there's really no longer any reason to do that Apr 26 23:18:35 Without the channel@0{ status = "disabled"; }; I got an error on cs0 already beeing used and no activity on the SPI bus to the MAX14830 Apr 26 23:18:53 huh, it does work? it didn't last time I tried it Apr 26 23:19:02 interesting Apr 26 23:19:36 that's nice actually Apr 26 23:20:52 Hehe, it is 5-6 years since last I worked with overlays. OK at least I think that was the thing that fixed it, but I've been fiddling around a bit so.... Apr 26 23:21:08 I'm cleaning it up a bit Apr 26 23:22:43 I guess getting rid of spidev would also work, but I haven't figured out how :) Apr 26 23:27:33 tried to manually set up /dev/ttyMAX0 with mknod, but no success (not sure about minor number to use) Apr 26 23:27:50 yeah no Apr 26 23:28:13 the problem is the DT declaration, almost certainly the clock node... I'm nearly done cleaning up your overlay Apr 26 23:28:56 Could running on -bone kernel be an issue? Apr 26 23:28:58 are you using an external clock source or a crystal? Apr 26 23:29:13 External clock source Apr 26 23:29:16 no idea, they're just rarely tested and not recommended Apr 26 23:36:41 RobertStaven: https://pastebin.com/L7PNSdd6 something like this maybe? I've renamed it to spi1-max14830.dts since EVER NOTICED HOW ALL-UPPERCASE MAKES TEXT MORE READABLE? no me neither Apr 26 23:36:59 ;) Apr 26 23:37:31 and dtc nowadays doesn't require manually writing out the fragment@ and __overlay__ crap, you can just sane dts syntax Apr 26 23:39:01 great, I'll take a look and test it. Apr 26 23:46:13 I'm guessing you limited the spi clock speed to 16 MHz to keep a bit more timing margin compared to the actual max clock freq supported? (which is 26 MHz based on the datasheet, though if you specify that as max you'll actually get 24 MHz since the spi controller only supports integer divisions of 48 MHz) Apr 26 23:49:31 I compile the overlay with /opt/source/bb.org-overlays$ make Apr 26 23:49:32 get some warnings Apr 26 23:49:54 yeah, really annoying that dtc is producing those spurious warnings Apr 26 23:50:01 that's plain a bug in dtc Apr 26 23:50:30 though as long as dtc isn't fixed it would be nice if the makefile passed flags to suppress those warnings Apr 26 23:51:20 https://pastebin.com/MGJqVkqj Apr 26 23:53:26 4.19-bone doesn't support remoteproc-pru btw (the AM335X-PRU-RPROC-4-19-TI-00A0 overlay) Apr 26 23:53:40 huh Apr 26 23:53:41 hmm Apr 26 23:53:47 hold on Apr 26 23:54:13 I usually use my own overlay-utils rather than bb.org-overlays so I may have messed up Apr 26 23:54:15 ok, should I change or disable it? Apr 26 23:54:48 use ./install.sh I think Apr 26 23:54:53 set_: hush Apr 26 23:54:57 Fine. Apr 26 23:55:07 RobertStaven: if you don't care about pru either way it doesn't matter, the kernel will just ignore it Apr 26 23:55:18 ok I see the issue Apr 26 23:56:24 apparently the AM33XX_IOPAD macro and the BONE_Px_xx macros are mutually exclusive Apr 26 23:57:13 so https://pastebin.com/3vZAdygZ Apr 26 23:57:48 Not using the PRU so should be fine. But I believe the AM335X-PRU-RPROC-4-19-TI-00A0.dtbo overaly is 'default' in the Debian Buster IoT Image 2020-04-06 Apr 26 23:57:59 yes, and 4.19-ti is the default kernel Apr 26 23:58:33 which is what that overlay targets (hence the 4-19-TI in the overlay name) Apr 26 23:59:15 I personally use uio-pruss instead of remoteproc-pru (which is not particularly sensible to kernel version/series) Apr 27 00:06:43 https://pastebin.com/QfBtyhGj Apr 27 00:06:44 Loaded fine, but /dev/ttyMAX* still not showing up Apr 27 00:07:39 oh that's really weird Apr 27 00:08:26 does it show in /sys/class/tty ? Apr 27 00:08:39 is the '0' in Used by (for max310x) in lsmod correct? Apr 27 00:09:15 it might be yeah Apr 27 00:09:33 pretty sure it is until the tty device is opened Apr 27 00:10:07 yes, in /sys/class/tty do they show up! Apr 27 00:10:45 anything interesting in journalctl -b -o short-monotonic | grep ttyMAX Apr 27 00:11:06 and now they show up in /dev/ttyMAX* ... Hmm was I to fast after boot= Apr 27 00:11:16 I''ll test with minicom... Apr 27 00:11:53 I guess you must have been Apr 27 00:14:42 Great. I can connect with minicom, and get SPI traffic. Apr 27 00:19:48 This was a huge step forward. Thanks a lot for your help! It's getting late here, so I have to leave this for tonight. Apr 27 00:36:17 woot Apr 27 00:36:41 zmatt you should get a fee from TI Apr 27 00:41:29 whats the difference between SYS and VDD Apr 27 00:41:32 on the bbb Apr 27 00:42:20 SYS_5V is the 5V output, i.e. it provides 5V power to external hardware that may need it. it switches off when you shut down the beaglebone Apr 27 00:42:40 it is not suggested to power things from VDD Apr 27 00:42:42 or you just cant Apr 27 00:42:47 VDD_5V connects directly to the 5V barrel jack and is primary meant is input *to* the beaglebone, as a way for the cape to power the beaglebone Apr 27 00:43:31 though since it does directly connect to the 5V barrel jack, it is possible to draw power from it, but only if the beaglebone is powered via the 5V barrel jack Apr 27 00:43:51 but that's not recommended Apr 27 00:57:04 is there a 3.3V VDD Apr 27 00:57:11 or 3.3V SYS Apr 27 00:57:15 on the pin map Apr 27 00:57:18 that question makes no sense Apr 27 00:57:19 it just says 3.3V Apr 27 00:57:46 looking at the pin map from google Apr 27 00:57:48 the 3.3V Apr 27 00:57:52 is colored yellow Apr 27 00:57:57 where? Apr 27 00:58:00 and is not labeled one way or another Apr 27 00:58:21 actually they call it VDD Apr 27 00:58:22 https://vadl.github.io/beagleboneblack/2016/07/29/setting-up-bbb-gpio Apr 27 00:58:28 https://goo.gl/Jkcg0w#gid=1775283126 Apr 27 00:59:20 supply names are just that, names Apr 27 00:59:36 largely arbitrary choices based on what someone once thought was a good name **** ENDING LOGGING AT Tue Apr 27 02:59:56 2021