**** BEGIN LOGGING AT Wed Dec 27 03:00:01 2017 Dec 27 12:28:08 I've downloaded 9.1, 9.2 and back to 8.7. Burned them with dd in Ubuntu, FreeBSD, & Windows with Etcher in Win-7. in all cases right after power-up, ds0 comes on. 2 or 3 seconds later DS1 & 2 come on and that's the last action I get. Nothing after that and the monitor on the HDMI says no signal. HELP!! Dec 27 12:31:04 THe BBB still works with an old jessie sdcard I've had for several years and works with the eMMC. . so It's not the Black. Dec 27 12:54:09 wa5qjh: lxqt or iot image? Dec 27 12:54:29 (although, in all cases hdmi should give a signal) Dec 27 12:55:21 actually, never mind that, since it sounds like it's not even booting at all Dec 27 12:55:49 try bypassing the bootloader on eMMC by powering the beaglebone on while holding down the S2 button Dec 27 12:58:09 a really old bootloader combined with a too-modern OS can be a problem Dec 27 12:58:29 (and by default, the bootloader on eMMC is preferred over the one on SD card) Dec 27 13:17:38 sorry had to go for a few minutes. still looking for idea why I cant get boot-up on my BBB by burning with dd on 3 different platforms and Etcher on win-7 Dec 27 13:24:30 weird that Etcher on windows says it verified what was written and I've confirmed the checksums Dec 27 13:25:43 hello all Dec 27 13:25:53 how do I flash an image to beagle bone blue Dec 27 13:32:15 is there anyone on? Dec 27 13:32:29 There is no answer in the FAQs Dec 27 13:32:36 and the method I followed was for BBBlack Dec 27 13:32:40 which is not working Dec 27 13:48:12 step 1. stick around after asking a question Dec 27 13:48:19 step 2... well, never mind I guess Dec 27 14:10:22 helpneeded best I can tell you is goto beagelbone.org and start from there. they've got an Etcher app for windows and linux and all the images you might want. Dec 27 14:10:51 wa5qjh: https://pastebin.com/raw/9EJEZ5M3 Dec 27 14:12:56 zmatt I've got absolutly nothing to put in pastebin. Etcher showed the process finished and validated on all three .xz files I tried on it. Dec 27 14:13:35 I linked to a piece of chat history where I gave you a suggestion but which you apparently missed Dec 27 14:14:02 likewise when i used DD in Ubuntu, Debian on my RPi, and FreeBSD on 9.1 and 9.2 Dec 27 14:15:06 yeah, I went off in search of answers on my own. pretty much forgot I was waiting for a response. Dec 27 14:15:27 old and absent minded, i guess!! :) Dec 27 14:15:28 in general it's a good idea to stick around in here after asking a question Dec 27 14:15:57 Alway should. I AGREE!! Dec 27 14:16:02 people are in different timezones and often just occasionally glance at chat... Dec 27 14:16:56 anyway, aside from several successfull burns ( al day today, and it's 10:16 PM here Dec 27 14:17:05 UTC+8 Dec 27 14:17:16 did you try my suggestion? Dec 27 14:17:40 sorry, you're right, I did miss it. Dec 27 14:18:57 wish these thiongs would store a little history HI HI!! Dec 27 14:19:22 there are irc logs online... or should be at least Dec 27 14:19:29 not sure if there any real-time ones Dec 27 14:20:08 I have my irc client open 24/7, so I do have chat history myself anyway :) Dec 27 14:20:30 not if you're in the middle of a reboot. and I screwed up and did that twice! once down from windoze and once from FreeBSD Dec 27 14:20:48 I run irssi in a screen session on my server Dec 27 14:21:21 I havent been on IRC in around a month ! Dec 27 14:21:34 till tonight Dec 27 14:21:56 welcome back! Dec 27 14:21:59 * zmatt hands out party hats Dec 27 14:22:03 thanks!! Dec 27 14:22:35 can you repaste that link, please ? Dec 27 14:22:53 https://pastebin.com/raw/9EJEZ5M3 Dec 27 14:23:04 or tell me what the bottom line was. Dec 27 14:23:13 the gist of it? Dec 27 14:23:28 13:55 < zmatt> try bypassing the bootloader on eMMC by powering the beaglebone on while holding down the S2 button Dec 27 14:24:38 ok, hang on I'll stick one of the 2 cards in and try that. Dec 27 14:26:48 oh, an older sdcard boots normally. Dec 27 14:27:52 if you want to be certain you did it right (the button can be a bit finicky), you can do it without any sd card inserted: then it should fail to boot at all from eMMC (since its bootloader is bypassed), then you can insert the sd card and hit the reset button Dec 27 14:29:21 normally what happens is that the bootloader (u-boot) is loaded from eMMC, and u-boot's boot script then loads linux but prefers to do so from SD card over eMMC Dec 27 14:30:06 so if your beaglebone (or more specifically the image flashed onto its eMMC) is pretty old, you can get a weird mix of an old bootloader and new OS image Dec 27 14:32:38 You're a magician!! THat Did the trick!! I KNEW it was something pretty simple that I just didnt know about. Dec 27 14:33:21 so, a less button-pressy fix is reflashing or erasing eMMC Dec 27 14:33:23 ok let me swap in a card from the Stretch images and see what hoppens!! Dec 27 14:34:50 If holding buttons is fiddly (especially for folks with limited mobility/dexterity), there are also jumper-wires-into-pins ways to accomplish all the same boot mode things as the buttons, I believe. Dec 27 14:35:36 correct Dec 27 14:35:54 I have a jumper wire with integrated resistor for such purposes Dec 27 14:36:09 Aye. The resistor is important to keep minor screwups from becoming smoke. :) Dec 27 14:36:29 those pins get configured into outputs once the kernel loads, so yeah Dec 27 14:36:55 (unless you explicitly disable hdmi via /boot/uEnv.txt) Dec 27 14:37:05 it's sad but it appears that may be necessary, while fiddlin there , I tried a quick reboot without holding S2. got the same DA0,1,2 on solid again. Dec 27 14:38:14 wa5qjh: you can erase eMMC with blkdiscard /dev/mmcblk1 Dec 27 14:38:24 if you just want to disable its bootloader, wipe sector 256 Dec 27 14:38:42 oh wait, it's really old so it might use a FAT boot partition instead Dec 27 14:38:43 looks like tthat card was last burned with the IoT image, apparently intended for headless operation Dec 27 14:39:03 iot image is usually the preferred image unless you explicitly want a desktop environment Dec 27 14:39:52 many beaglebone variants don't have hdmi, many people who do have hdmi don't use it, and many who do use it use it for a single-window-fullscreen application rather than a desktop environment Dec 27 14:40:38 for this I do want a desktop. largely cause I'm curious what the put in it. the raspbian Stretch image includes a lot of tools, kinda neat even if I dont expect to use them. Dec 27 14:41:10 yeah, takes all kinds, right ha ha!! Dec 27 14:41:33 also want to put gparted on it Dec 27 14:41:38 there's definitely a lot of crap in the lxqt image... if you flash it to eMMC you barely have any free space left :P Dec 27 14:41:49 I use that quite a bit. Dec 27 14:42:53 mostly cause I havent learned to use FreeBSD's gpart yet. it goes FAR beyond debian's gpart does. Dec 27 14:43:44 the bbb isn't exactly the most ideal piece of hardware for a desktop environment though... it's slooow Dec 27 14:43:53 its video output is quite limited Dec 27 14:44:01 (not even support for a hardware cursor) Dec 27 14:44:15 its primary applications are automotive and industrial control applications Dec 27 14:44:31 this is great!! past my bed time now so I'm gonna hold off burning these cards again till morning. The first one I tried aftwer we connected was a full 8.7 version but only burned to a 4GB card Dec 27 14:44:34 so it has a lot of I/O and peripherals Dec 27 14:45:05 for a desktop environment it's definitely better to get 8GB or more Dec 27 14:45:08 Heh, so's the RPi 2B for that matter. Dec 27 14:45:53 rpi is media-oriented, it doesn't really have much i/o useful for control applications at all Dec 27 14:46:17 but I need an alternate very low power 'near desktop' here. we get blackouts so frequently its sxcary!! but so far, not today. Dec 27 14:47:38 with some creativity a beaglebone can run on battery power... https://nurdspace.nl/images/0/0a/Bbb-zmattified.jpg Dec 27 14:48:00 that's why Im trying to get my BBB back up Dec 27 14:48:55 have you ever considered that a computer is a very elaborate and super capable Programable Pulse Generator? Dec 27 14:48:56 (if you do want to try to use the battery terminals and integrated charger, you must do a hardware patch to work around the 3v3 regulator issue) Dec 27 14:49:03 hahaha Dec 27 14:49:10 it's sand that we tricked into thinking! Dec 27 14:49:30 THAT TOO!! HA!! Good one! Dec 27 14:50:04 it's also a great programable measurement device. Dec 27 14:50:17 easiest way of working around the 3v3 regulator bug is by removing it: https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/_oNSCta5WusJ Dec 27 14:50:31 Are there any beaglebone variants with the battery workarounds already done? does the blue take care of that, for instance? Dec 27 14:50:44 obviously if you don't want to wield a soldering iron, just use an usb battery pack instead Dec 27 14:50:48 In other words potentially a VERY NICE desktop Automatic test equipment. Dec 27 14:51:35 the blue has integrated battery support, but no video output Dec 27 14:51:42 "it can't supply as much current as the original", classic! Dec 27 14:51:57 :) Dec 27 14:52:04 but on the other hand, it has a handy integrated current-measuring shunt :) Dec 27 14:52:08 well, I've found not all those battery papcks will act like a UPS, they wont power a device while they, themselves are being charged. But there's some that will Dec 27 14:52:45 wa5qjh: there are lists of USB battery packs with confirmed UPS/passthrough functionality Dec 27 14:53:07 Blue has NO vid output? I was thinking it did Dec 27 14:53:44 I don't think it does? Dec 27 14:54:16 Well, I dont have much choice here. very little selection at all and cant get shipping to my house. Dec 27 14:54:52 I'm in sorta backwoods Philippines on W. Samar specifically Dec 27 14:54:54 it definitely doesn't have video Dec 27 14:55:28 hah, your callsign doesn't indicate your qth! Dec 27 14:55:45 BUMMER!! well that saves me a lot of money!!to say nothing of anger and frustreation if I had bout one :) Dec 27 14:55:55 oh lol I didn't even realize it was a callsign Dec 27 14:56:24 I wonder if you could run a displaylink adapter... don't see why not... Dec 27 14:56:29 there are linux drivers for it :P Dec 27 14:56:30 no, the call signis Texas, got it in San Antonio. need to apply for my recip again too. Dec 27 14:56:59 you also a ham ? Dec 27 14:57:09 my dad was (pa0dtl) Dec 27 14:57:17 nj8z :) Dec 27 14:58:01 my dad got his long after I got mine :) and then I cant remembwer it. shame on me! Dec 27 14:59:18 I would be DV%/WA5QJH. very much a coincidence that I'm in Philippines region 5 for that. Dec 27 14:59:41 myself, have you ever played with packet ? Dec 27 15:00:08 or thought about using fldigi on the BBB ? Dec 27 15:00:10 not in the usual sense, but I cut my teeth on part-15 gear so sending packets wirelessly has always been my thing Dec 27 15:00:18 just not in usual ham ways :P Dec 27 15:01:19 there's software for linux I think is available for armhf as well. been wanting to try it out but for some reason..... Dec 27 15:02:22 my usual advice is start small, replicate someone else's work first... Dec 27 15:02:37 Iused to do packet quite a bit. Was Stationed in okinawa Japan as a civilian and packeted back and forth to a ham buddy back in San Antonio. got a round trip of only 20 minutes one day. Dec 27 15:02:58 heh! That's faster than fidonet, slower than ricochet.. Dec 27 15:03:00 if I could find that someone :) Dec 27 15:03:27 not bad for 8000 miles B4 internet tho\ Dec 27 15:04:41 Guys, I've really enjoyed the QSO tonight but I gotta hit the hay. hope I can catchyall on the flip side Dec 27 15:04:56 hope to see you back here, 73! Dec 27 15:06:14 ..73 to all yall too!! and THANKS for the tip on S2 Dec 27 15:06:57 good start but I'm gonna have to find some kind of work-around. sounds like you've got a few tho. Dec 27 15:07:08 G'nite yall! Dec 27 16:36:32 hello can i use beaglebone black for industrial applications Dec 27 16:37:52 so I learned you can't use the SYS_BOOT pins untill the SYS_RESET is active . I want to use them with a ULN2308 that drives relays. But it seems the inputs of the ULN280 Dec 27 16:38:51 ULN2803 have a to low impedance, and the BB doesn't boot when connected. Any advice what IC to put in between? Something like a tristate buffer Dec 27 16:40:32 deeLer: is the input impedance of that ULN specified? Dec 27 16:41:02 and direction of its pull Dec 27 16:42:02 i'I measured between two input pins: 23 kohm Dec 27 16:42:05 it may suffice to just reinforce the rather weak (100 KΩ) pull resistors on the beaglebone with external pull-ups or pull-downs Dec 27 16:42:49 you mean the pull-up/pull downs that are soldered on the back of the PCB ? Dec 27 16:43:04 beagle bone is fit for industrial applications ? Dec 27 16:43:12 they're on both sides actually (pull-ups are on one side, pull-downs on the other) Dec 27 16:43:20 ravi_: your question is too vague Dec 27 16:43:34 ? Dec 27 16:43:52 oh ok .... that's worth a try ! Dec 27 16:44:22 deeLer: e.g. we used an LVDS framer with internal 100K pull-downs, so we just put 10K pull-ups on the few boot pins that require pull-up Dec 27 16:45:13 I think for the prototypes we actually soldered them onto the existing pull-ups on the beaglebone Dec 27 16:45:20 nice ... so I need to check the schematics to find out what pin has pull-up, and what has pulldown ? Dec 27 16:45:31 you can also check my spreadsheet Dec 27 16:45:41 looking at it now ... Dec 27 16:46:52 sata Dec 27 16:46:55 on the P9/P8 tabs, the "H"/"L" next to the pin number indicates pull-up/down Dec 27 16:47:11 (either internal or on pcb) Dec 27 16:47:14 zmatt: would that be the J column that specifiec it ? Dec 27 16:47:19 ahaa, yes Dec 27 16:47:22 :) Dec 27 16:47:44 the J and M columns for P8 yes Dec 27 16:48:13 maybe a stupid question, but why where the resistors so high designed for these pullups/downs ? Dec 27 16:48:19 so, you'd need pull-ups on P8.31, .41, .43, and .44 Dec 27 16:48:24 yes Dec 27 16:48:27 makes sense Dec 27 16:48:38 to minimize interference with other uses of the pin Dec 27 16:48:44 ok Dec 27 16:49:13 but yeah, they could definitely have used stronger pulls Dec 27 16:49:32 on the 'boot' sheet , you mention SYSBOOT 0-15, while there are only 11 boot pins, are the other 5 internal (non-changable ?) Dec 27 16:49:38 100K is consistent with the internal pull resistors though Dec 27 16:49:56 there are 16 boot pins Dec 27 16:50:27 if my ULN2803 has 10k ohm per pin then maybe I should use slight lower resistor as pullup/down Dec 27 16:51:14 the ones I didn't mark in bright yellow are not relevant for the boot devices used by the beaglebone (eMMC and SD), but they may be relevant for other boot modes Dec 27 16:51:39 yes, I'd say use 2K or less Dec 27 16:51:42 oh ok, I'm booting of SD by the way Dec 27 16:51:55 thanks Dec 27 16:52:12 in that case pull-up on P8.43 is unnecessary Dec 27 16:52:29 right! Dec 27 16:52:33 (pulling down that pin is equivalent to pressing the S2 button) Dec 27 16:52:35 starts to make sense Dec 27 16:53:27 have you verified the ULN2803 has 10k pull-down and not 10k pull-up or pull-somewhere-in-between ? Dec 27 16:55:10 i'm checking the datasheet now Dec 27 16:56:23 can't find it Dec 27 16:56:54 I'll try with one pin, and put an extra resistor on it Dec 27 17:00:07 very handy sheet zmatt Dec 27 17:07:59 :) Dec 27 17:12:46 ok, I soldered the 8 inputs of the ULN2803 to P8-32/34/36/38/40/42/44/46 ... BB not booting, I'll start of with a extra pull up on P8-44 Dec 27 17:13:34 can't you just power the ULN2803 and measure the voltage on its inputs to know what it's doing? Dec 27 17:14:59 yes, it seems to pull-down Dec 27 17:15:13 0V on these pins Dec 27 17:16:52 holy cow! that works !!!!! Dec 27 17:16:54 :-))))) Dec 27 17:17:20 guess I'll only need pull-up resistors then Dec 27 17:18:06 anyone selling four 4,7 kOhm resistors ? ;) Dec 27 17:20:40 thanks zmatt! Dec 27 17:21:51 4.7 sounds a bit marginal, I'd use a lower value like 2.2 Dec 27 17:23:19 (assuming your estimate of 10K pull-down, and keeping in mind that on-die resistors tend to have as much as +/-50% variance) Dec 27 17:32:54 good point ... I'll take a 2.2 to be on the safe side Dec 27 17:52:10 Okay now I'm totally frustrated with the Blue Dec 27 17:52:21 Randomly it will throw the following error: Dec 27 17:52:34 unable to open /var/lib/sudo/ts/debian: Read-only file system Dec 27 17:52:44 what is the solution for this Dec 27 17:55:16 so frustrating Dec 27 17:58:35 any other way to connect to the D2-D5 LEDs than to carefully solder on their contacts ? Dec 27 17:59:55 no. why would you want to do that anyway? Dec 27 18:00:02 they're just four random gpios Dec 27 18:00:06 use four random gpios Dec 27 18:01:25 my bb will be in a closed box and I'd like to have the D2 LED on my front panel Dec 27 18:01:28 frustation: the solution is, waiting more than a few minutes to get some help with your filesystem corruption issues (my random guess) Dec 27 18:01:37 i like the heartbeat pattern :) Dec 27 18:02:16 deeLer: there is nothing special about those four pins, their functionality is entirely under software control and can be reproduced on any other gpio Dec 27 18:02:25 the only special led is the power led Dec 27 18:02:37 (although it can actually be controlled too) Dec 27 18:02:54 oh ok... what process controls that (using latest debian jessie IOT here) Dec 27 18:03:20 ew, still using jessie instead of stretch? Dec 27 18:03:27 anyway, it's handled by the kernel Dec 27 18:04:12 ahm wait: it's bone-debian-9.2-iot-armhf-2017-10-10-4gb.img Dec 27 18:04:13 the four pins are declared as leds in the device tree, as are their default triggers (although those can be overriden via sysfs, see /sys/class/leds/ ) Dec 27 18:04:17 stretch Dec 27 18:04:19 my bad Dec 27 18:04:47 yep Dec 27 18:05:26 but they also show things during boot, and I was just wondering if there is an elegant way of mounting them on a frontpanel Dec 27 18:06:14 please someone tell me how to use this BBBlue Dec 27 18:06:20 its frustrating me to no end Dec 27 18:06:36 it randomly startsd throwing the read only file system eroor Dec 27 18:06:38 error* Dec 27 18:06:40 deeLer: marking other pins as leds requires some minor customization of the device tree... probably easiest done via an overlay, although I'd need to check what the right way to do it is then (I'm used to using entirely custom device trees) Dec 27 18:06:40 and now Dec 27 18:06:56 iit automatically closes ssh connection Dec 27 18:07:04 I request anyone online to help me Dec 27 18:07:08 it automatically* Dec 27 18:07:10 frustration: sounds like filesystem corruption or some serious driver issue Dec 27 18:07:17 thanks zmatt, I'm not that advanced yet Dec 27 18:07:22 so what is the work around? Dec 27 18:07:57 zmatt: Can you please let me know how I can flash a new image to the Blue?? Dec 27 18:08:07 There is no documentation for it at alL! Dec 27 18:08:10 all!* Dec 27 18:08:30 you mean apart from being right below the download links at http://bbb.io/latest-images ? Dec 27 18:09:24 i did that Dec 27 18:09:26 and also instructions in the getting-started guide https://beagleboard.org/getting-started#update Dec 27 18:09:33 Ill tell you my procedure Dec 27 18:09:50 Im using a Mac so, first I formatted the SD card Dec 27 18:10:02 then I wrote the .img to the card using dd Dec 27 18:10:22 i inserted the card into the blue, and then I booted while pressing the SD button Dec 27 18:10:28 formatting the card is utterly pointless if you're going to overwrite it using dd anyway Dec 27 18:11:02 after this I went to the /boot/uEnv.txt file Dec 27 18:11:06 using sudo nano Dec 27 18:11:12 and uncommented the required line Dec 27 18:11:14 and saved it Dec 27 18:11:25 then i rebooted while pressing SD button again Dec 27 18:11:39 and waited for the cyclone pattern to finish Dec 27 18:11:51 then again i rebooted after removing the card Dec 27 18:12:15 that does sound like you should have successfully reflashed it Dec 27 18:12:24 it works fine for a while, but after running update and upgrade it moves into read only file system Dec 27 18:12:42 which image did you flash exactly? Dec 27 18:12:50 how much free space is available? df -h / Dec 27 18:12:59 Debian 9.2 2017-10-10 4GB SD IoT Dec 27 18:13:14 free space on sd card? Dec 27 18:13:21 no, on eMMC Dec 27 18:13:47 also, when this happens, if possible try to dump kernel log using the 'dmesg' command Dec 27 18:14:15 I've seen this happen once during a big upgrade due to a driver bug Dec 27 18:15:03 sorry i got logged out Dec 27 18:15:05 but it seems to happen very rarely and isn't consistently reproducible for me, so that made it problematic for a bug report Dec 27 18:15:22 I have to use screen as it is not ssh-ing into the board Dec 27 18:15:24 https://pastebin.com/raw/uF58bzJX Dec 27 18:15:32 the board is automatically closing the connection Dec 27 18:15:39 that's odd Dec 27 18:16:08 maybe it's a different issue... hard to say much without more information Dec 27 18:16:10 please give me 2 mins as I find out the space on eMMC Dec 27 18:16:27 Perhaps its an issue in the way I am flashing the card? Dec 27 18:17:06 not likely, but it may be worth trying etcher (https://etcher.io) to flash the image to sd card Dec 27 18:17:23 or try a different sd card Dec 27 18:18:06 I discovered that one sd card I had produced bit-errors in the data stored on it Dec 27 18:18:13 so.. yeah... Dec 27 18:19:18 Why is this not connecting?? Dec 27 18:19:20 oh phew Dec 27 18:19:28 dev/mmcblk1p1 3.5G 1.7G 1.6G 52% / Dec 27 18:19:37 thats the emac stat\ Dec 27 18:19:48 Filesystem Size Used Avail Use% Mounted on Dec 27 18:20:06 okay, so that's definitely not the problem Dec 27 18:20:06 should I paste the full result of df -h Dec 27 18:20:10 no need Dec 27 18:20:43 So I should try flashing with etcher.io Dec 27 18:20:48 with a new sd card? Dec 27 18:20:54 and thats about all I can do? Dec 27 18:21:10 in general, try reflashing. etcher.io is useful because it verifies the sd card after flashing it Dec 27 18:21:19 okay cool Dec 27 18:21:27 but the eMMC is alright yes? Dec 27 18:21:35 because I really don't understand any of this Dec 27 18:21:39 and one thing I do on our beaglebone is use /etc/sysctl.conf to limit the amount of data in write buffer Dec 27 18:21:55 what does that do? Dec 27 18:22:05 if your issue is due to the same bug I had, you just got very unlucky since it seems to be very rare Dec 27 18:22:26 sorry which bug are you referring to again? Dec 27 18:23:01 19:14 < zmatt> I've seen this happen once during a big upgrade due to a driver bug Dec 27 18:23:18 okay Dec 27 18:23:21 so thats it right? Dec 27 18:23:31 19:16 < zmatt> maybe it's a different issue... hard to say much without more information Dec 27 18:23:42 what info would you be needing? Dec 27 18:23:55 I am having the read only file system error again Dec 27 18:23:57 19:13 < zmatt> also, when this happens, if possible try to dump kernel log using the 'dmesg' command Dec 27 18:24:06 should I put the dmesg output here? Dec 27 18:24:15 use pastebin.com or similar paste site Dec 27 18:24:22 never paste multi-line stuff into chat Dec 27 18:24:43 if the beaglebone has internet connectivity, you can do: dmesg | pastebinit Dec 27 18:24:59 well umm Dec 27 18:25:06 it says "input/output error" Dec 27 18:25:12 ? Dec 27 18:25:20 what does? Dec 27 18:25:35 when i use dmesg Dec 27 18:25:38 it says: sudo: unable to execute /bin/dmesg: Input/output error Dec 27 18:27:41 what should I do now? Dec 27 18:29:41 panic? Dec 27 18:29:58 I am already Dec 27 18:30:09 I mean, if it isn't even able to *read* /bin/dmesg anymore, shit is fucked Dec 27 18:30:21 exactly Dec 27 18:30:32 refresh? Dec 27 18:30:35 if you think you can reproduce this problem, run dmesg before the problem hits Dec 27 18:30:42 to get it into disk cache Dec 27 18:30:47 reflash?* Dec 27 18:31:10 wait, had you already reflashed it yet or not? Dec 27 18:31:24 since typically if this happens once, shit is fucked Dec 27 18:31:46 I have refreshed it Dec 27 18:31:50 reflashed8 Dec 27 18:31:59 I refreshed it once Dec 27 18:32:07 reflashed* Dec 27 18:33:28 so the problem occurred, you reflashed, and now the problem occurred again? what triggered it the second time? Dec 27 18:34:01 the board started giving an input output error many times on the preloaded debian Dec 27 18:34:05 so I refreshed it Dec 27 18:34:13 hummmmm Dec 27 18:34:33 then after doing apt upgrade on the newly flashed os, it gave this filesystem error Dec 27 18:35:14 it is slowly starting to sound like there might be an actual hardware issue, but it's difficult to say due to limited information Dec 27 18:36:15 hardware issue with what? Dec 27 18:36:20 oh right Dec 27 18:36:22 you can't say haha Dec 27 18:36:24 if you can reproduce the problem easily enough, then it should be possible to capture a kernel log of the event Dec 27 18:36:36 let me try just give me a few minutes Dec 27 18:36:37 eMMC I'd guess? maybe Dec 27 18:36:51 ¯\_(ツ)_/¯ Dec 27 18:37:23 its like, it works perfectly fine, and then just throws this wee all the time Dec 27 18:37:58 btw im running this command, before when it throws the error: sudo /opt/scripts/tools/update_kernel.sh --ti-rt-channel --lts-4_4 Dec 27 18:39:53 is that indicative of anything? Dec 27 18:40:49 you're the first person to have come in this channel with this particular problem, so I don't have any prefab solutions to offer... my best suggestion still is making sure it can't somehow be due to how you flashed it (although that doesn't sound likely if the problem randomly appeared the first time) and otherwise contact manufacturer to see if an RMA is possible Dec 27 18:41:24 no Dec 27 18:42:22 if you can capture the kernel log after this event happens I may be able to take a better guess at what's going on Dec 27 18:46:13 Sorry got disconnected yet again Dec 27 18:46:16 ok so ssh is working Dec 27 18:46:32 waiting for the command to eecute Dec 27 18:46:35 execute Dec 27 18:46:45 I got two BBG's .... when I do a "config-pin -a P8_46 in+", one loads its cape-universala (command is successful and I can see the cape loaded via dmesg, it's in slot 4) .... the other BBG doesn't do that, and just says: WARNING: GPIO pin not exported .... it should automaticaly load the cape Dec 27 18:47:19 the /boot/uEnv.txt's are identical, so is the software Dec 27 18:47:25 any idea Dec 27 18:47:25 ? Dec 27 18:49:23 nope Dec 27 18:49:31 continually returning same error Dec 27 18:50:23 mesh enough ssh Dec 27 18:50:25 eesh* Dec 27 18:50:54 deeLer: if any cape is being loaded for that that's already very odd, that shouldn't happen if you're using the latest image Dec 27 18:51:20 deeLer: can be symptomatic of old bootloader though Dec 27 18:51:28 sa Dec 27 18:51:55 zmatt, anyway to check that in debian ? Dec 27 18:52:31 are you booting from eMMC or SD ? Dec 27 18:52:35 SD Dec 27 18:53:02 try powering on with the S2 button held down Dec 27 18:53:10 ok Dec 27 18:53:16 or if you don't care about the contents of eMMC, wipe it with sudo blkdiscard /dev/mmcblk1 and reboot Dec 27 18:53:44 zmatt: when i run any rc program it says "you probably need a newer kernel" just before executing Dec 27 18:53:52 is _that_ indicative of anything? Dec 27 18:54:08 I booted in eMMC now Dec 27 18:55:19 frustration__: I don't know anything about the robotics cape stuff, but my guess would be it is indicative of stuff being fucked Dec 27 18:55:22 deeLer: ? Dec 27 18:55:28 ah no, still in SD mode Dec 27 18:55:37 frustration__: or, maybe you successfully downgraded your kernel to 4.4 Dec 27 18:55:45 (I think 4.9 is the default nowadays) Dec 27 18:55:52 (not 100% sure) Dec 27 18:57:07 zmatt: there is no /dev/mmcblk1 only a mmmcblk0 Dec 27 18:57:08 Im running the update kernel script Dec 27 18:57:22 deeLer: wait what? Dec 27 18:57:40 deeLer: did you disable eMMC in /boot/uEnv.txt ? Dec 27 18:58:33 frustration__: but you're explicitly telling it to install a 4.4 kernel Dec 27 18:58:36 I'm confused now: at boot does it read the uEnv.txt from eMMC ? or from SD ? Dec 27 18:59:07 deeLer: it reads it from the system that it will boot, i.e. from SD when booting from SD Dec 27 18:59:33 yes zmatt, that's what I would like : because i want to use as much gpio as possible, including the emmc pins Dec 27 18:59:52 zmatt: sorry I didn't understand you again.. im runningsudo ./update_kernel.sh Dec 27 19:00:30 i somehow managed to do this on the first BBG, and on the second it looks good too . But this universala cape doesn't seem to load when "configure-pin -a" Dec 27 19:00:37 deeLer: well, that explains why /dev/mmcblk1 doesn't exist, hence if you want to erase eMMC you should temporarily enable it again Dec 27 19:01:16 deeLer: like I said, on current images no overlay should get loaded for that, at least not at runtime: current images use u-boot overlays Dec 27 19:01:34 I don't really care about the eMMC , will it make a difference if I erase it ? Dec 27 19:01:36 zmatt: this is my kernel 4.4.91-ti-rt-r141 Dec 27 19:02:29 deeLer: yes, since erasing it prevents some old bootloader sitting on eMMC being used to load the linux system on SD card Dec 27 19:05:11 I don't understand , this cape should load when I enter that command, already in debian on the SD. How can the bootloader still make a difference at this point ? Dec 27 19:05:53 I'm kind of out of energy to explain, just trust me and ask me again later Dec 27 19:06:11 :) sorry Dec 27 19:06:19 zmatt: ill need a few mins rebooting sys again Dec 27 19:06:35 frustration: you don't need to narrate everything you're doing Dec 27 19:26:57 well its not throwing any error right now Dec 27 19:26:59 and I don't know why Dec 27 19:44:43 zmatt: I did a blkdiscard Dec 27 19:45:00 now i'm booting of SD again Dec 27 19:45:17 but still can't use the config-pins command Dec 27 19:47:35 hello all, I'm trying to flash a new image to my Blue and I noticed the guidelines on the bb webpage: [..edit the /boot/uEnv.txt file on the Linux partition on the microSD card...] Dec 27 19:48:02 Now I'm using macOS and after flashing the sd card it becomes unreadable by my computer Dec 27 19:48:14 so how can I edit this file? Dec 27 19:49:16 if anyone could help me that would be great Dec 27 19:49:39 can I follow BBBlack instructions: https://old.ghielectronics.com/community/forum/topic?id=23763 Dec 27 19:53:28 is anyone online Dec 27 20:09:20 * vagrantc wonders if the irc web client has some auto-timeout to make the issue even worse Dec 27 20:10:58 zmatt: I found it, I forgot to do this on the new BBG: apt install bb-cape-overlays Dec 27 20:11:48 now i can use the config-pin , and it auto loads the universala cape (I still don't understand the whole dtb concept yet, but learning) Dec 27 20:32:30 deeLer: ?! how was that not already installed/ Dec 27 20:32:47 did you accidently remove it? Dec 27 20:33:06 vagrantc: that sounds like something that could be empirically tested Dec 27 20:38:04 I'm not kidding, I just flashed the image bone-debian-9.2-iot-armhf-2017-10-10-4gb.img , and dit the apt-get instal bb-cape-overlays and it installed Dec 27 20:38:17 was'tn there Dec 28 00:35:26 G'Morning All Dec 28 00:37:17 zmatt myself yall still up ? Dec 28 00:52:00 Evening All, I recently got a BB Blue. It was working great for a day then i switched it to a different computer and upon pressing the power the power LED goes on then off almost immediately Dec 28 00:52:21 i tried it back on the computer it was connected to and it does the same thing, also if i connect it to a 12v DC supply it does the same thing Dec 28 00:55:31 on the power out header I get a constant 5V the 3.3 never volts even when pressing the power button and having the LED flash Dec 28 01:05:43 Don't suppose you felt a static zap at any point while working with it? Cuz that sounds pretty fried, and 'tis the season for low indoor humidity.. Dec 28 01:06:02 (And of course ESD events much too small for a human to feel can still destroy silicon..) Dec 28 01:06:54 I was thinking about that, which is highly possibly. I'm not overly familiar with the BB so before I rule it dead i wanted to make sure there wasn't a simple reason Dec 28 01:07:03 like possibly no POWER led because of a corrupted OS Dec 28 01:07:07 like a RPi would do Dec 28 01:11:48 It's possible but unlikely that the emmc got hosed, but in that case I think the power LED would still stay on. Dec 28 01:12:26 Nonetheless, if you have a microSD card sitting around, write a new image to the card with Etcher and boot it by holding the "SD" button: https://github.com/beagleboard/beaglebone-blue/wiki/Flashing-firmware Dec 28 01:12:35 and I got a buddy that'divorced' hgis BBB cause the PMIC died suddenly. he sent it off to TI and the replaced it and sent it back free tho he had to pay shipping there. Dec 28 01:12:49 I will give that a test Dec 28 01:13:42 I sometimes forget that people ESD the shit out of their hardware since I got so strict about it myself, it's become habitual and I don't really think about the precautions anymore. Dec 28 01:13:47 MrOlsen: power led blink = hardware failure. a missing OS would leave the power led on Dec 28 01:13:50 is the PMIC known to be something to fail? There isn't much i can find on the BB Blue compared to the Black Dec 28 01:14:02 no, I've never heard of the PMIC failing Dec 28 01:14:21 he went back to his pi which he had been eschewing vehemently previously. Dec 28 01:14:23 though, the blue does have a lot more circuitry around power, I don't know much about that Dec 28 01:14:25 The blue is 90% a black anyway, most of the advice for the black applies to the blue. Dec 28 01:14:35 I think it still uses the same pmic though Dec 28 01:14:39 lemme check Dec 28 01:14:59 oh duh it does Dec 28 01:14:59 such fragile little things they are Dec 28 01:15:02 Yeah, I did a double-take when you said you hooked it to 12v, cuz that would smoke a black, then I looked it up and the blue has a 9-18v input :) that's awesome Dec 28 01:15:02 it uses the osd335x Dec 28 01:15:14 which has the pmic integrated Dec 28 01:15:30 is there a utility for configuring wifi in 9.1 or 9.2 that you know of ? Dec 28 01:15:50 wa5qjh: the iot images use connman as network manager by default Dec 28 01:15:57 you can replace it by a different one if you prefer of course Dec 28 01:16:20 right now, I'd prefer any :) Dec 28 01:16:56 MrOlsen: so yeah, if the power led turns on then it got to a pretty late stage of the power-up sequence, so that makes a problem with the other power circuitry unlikely Dec 28 01:17:10 and if it immediately turns off again, that's typically indicative of overcurrent Dec 28 01:17:28 then i guess something shorted Dec 28 01:17:58 exposing AM335x I/O to overvoltage can cause damage that results in an internal short-circuit Dec 28 01:18:00 I did have a GPS Connected to it, but i dont think that draws much current Dec 28 01:18:00 but overcurrent with nothing plugged into the board usually means something blew through the silicon in part of the soc itself Dec 28 01:18:01 connman not found Dec 28 01:18:09 try connmanctl Dec 28 01:18:17 MrOlsen: details please Dec 28 01:18:46 MrOlsen: making mistakes in interconnecting a beaglebone to external hardware is a common way to damage I/O Dec 28 01:18:50 There is/was a GPS module connected to the GPS uart Dec 28 01:18:57 that exposes 5V Dec 28 01:19:23 unplug that! Dec 28 01:19:25 what port is that? Dec 28 01:19:27 it is Dec 28 01:19:31 GPS Dec 28 01:19:40 UaRT5 Dec 28 01:19:46 no Dec 28 01:20:21 i dont know what UART it is labled as UART GPS its 5V,GND,TX,RX,GND Dec 28 01:20:25 oh wow, there is indeed 5v on that connector... Dec 28 01:20:26 uart2 Dec 28 01:20:45 https://github.com/beagleboard/beaglebone-blue/wiki/Pinouts says ttyS2 Dec 28 01:20:46 I do hope the gps module uses 3.3v for its uart signals even though it's powered by 5v itself Dec 28 01:20:50 Could the GPS voltage drain short anything on the board if the USB is not sufficient? Dec 28 01:21:09 yes the GPS RX/TX is 3.3V TTL Dec 28 01:21:30 connmanctl was found but it errored looking for net.connman.vpn Dec 28 01:21:33 the next question is... where does that 5V supply come from and when does it power up Dec 28 01:21:40 * zmatt digs further Dec 28 01:21:47 if the GPS was functioning properly, no it shouldn't hurt anything, but a short on the GPS side could throw 5v onto the UART pins which would be bad Dec 28 01:22:05 since this smells like a recipe for power domain violation during power-up/down Dec 28 01:22:13 myself: that doesn't sound very likely Dec 28 01:22:34 a more plausible issue would be the GPS module driving its TxD before the 3.3v supply of the beaglebone has powered up Dec 28 01:22:36 Oooo. Interesting. Dec 28 01:23:35 in general, using an independent 3.3v supply (which such a module obviously has) is a recipe for creating hazardous situations if you're not very careful Dec 28 01:24:00 I'm familiar with the pin i/o structures on simpler chips, and there's typically a protection diode that would conduct in this situation, and back-power the chip from the I/O, but I've never dealt with chips that have multiple power supply voltages and sequencing requirements. Dec 28 01:24:27 myself: yes, such diodes are there, but they're meant to divert short ESD spikes Dec 28 01:24:53 Right. Not power the chip like Scanlime abuses them to... :P Dec 28 01:25:14 plus, the am335x i/o are not 3.3v-tolerant when it has no 3.3v supply Dec 28 01:25:46 That's one of those little-asterisk details that should probably be in flashing red text all over the front page of the datasheet. Dec 28 01:25:55 I don't think pdf has a tag, more's the pity Dec 28 01:25:55 it does magical things to make its i/o 3.3v in the first place, given that the transistors used in this semiconductor process have an absolute maximum rating of 2V Dec 28 01:26:26 the only other thing i could think but would be very random and not likely but always possible Dec 28 01:26:26 so there's stuff with cascaded transistors and an intermediate bias supply Dec 28 01:26:28 Whoah. Now that I'm gonna have to learn more about, I have a notion.. Dec 28 01:26:52 haha, yup! like the virtual ground used in certain opamp circuits I've seen, wild! Dec 28 01:26:53 is possibly the very small bare ends of the wires in another connector shorted Dec 28 01:27:08 MrOlsen: I'm looking at the blue schematic and I'm quite concerned Dec 28 01:27:19 since it looks like that 5v supply remains up even if the beaglebone is powered down Dec 28 01:27:25 if I'm reading this right Dec 28 01:27:40 and there's no buffer on the gps uart pins? Dec 28 01:27:54 nope, straight to the osd335x Dec 28 01:28:30 so, that whole setup is a very nice recipe for fried hardware Dec 28 01:29:43 it is Dec 28 01:29:45 I always get 5v Dec 28 01:29:51 regardless of on or off Dec 28 01:29:53 hence the gps module stays powered Dec 28 01:30:15 and keeps driving 3.3v into the uart2_rxd pin even while the am335x is unpowered Dec 28 01:30:54 which will fry the i/o Dec 28 01:30:56 but 3.3v is the tollerable level Dec 28 01:31:00 will it? Dec 28 01:31:07 not when the processor is unpowered Dec 28 01:31:17 well that's not good Dec 28 01:31:24 the max voltage on i/o is the i/o supply voltage + 0.5 v Dec 28 01:31:47 so when there's no i/o supply, that means max 0.5 v Dec 28 01:31:57 (iirc it was 0.5v, don't hold me to it) Dec 28 01:32:00 I wonder if the Blue people know that. Dec 28 01:33:00 I certainly hope they know about that restriction on i/o... they probably just overlooked the consequences of putting that particular 5v supply on that connector Dec 28 01:33:01 well if the 5v perifs are powered before the system is powered.. I need to make a work around for the future Dec 28 01:33:24 MrOlsen: a level shifter powered by the 3.3v supply of the beaglebone should work Dec 28 01:33:54 yeah i was thinking that or a transistor off the 5V triggered by the 3.3V out so the GPS is not powered until the system is up Dec 28 01:34:00 or something that isolates the i/o when reset is asserted Dec 28 01:34:09 no, that is not safe Dec 28 01:34:13 oh Dec 28 01:34:26 the GPS will run off of 3.3V Dec 28 01:34:33 i could just not power it from the 5V Dec 28 01:34:56 oh if it accepts 3.3v then just use the beaglebone's 3.3v supply Dec 28 01:35:01 problem solved Dec 28 01:35:03 yeah Dec 28 01:35:17 its amazing how fragile this is and now all these components are useless Dec 28 01:35:25 can't even repurpose them Dec 28 01:35:35 I know of one case of someone managing to bring an am335x back to life Dec 28 01:35:42 in a hilarious way Dec 28 01:36:04 basically they had these RMA'd boards and were trying to diagnose what happened to them Dec 28 01:36:47 so he managed to disconnect the PMIC and used a bunch of lab supplies to manually power up the board to see what happened Dec 28 01:37:21 when the 3.3v up was provided, briefly the board would draw 2-3A and after that it would work totally "fine" again Dec 28 01:38:08 TI support's guess was that overvoltage damaged the esd protection diodes of i/o and caused an internal short-circuit Dec 28 01:38:45 and connecting a supply capable of high current (with no overcurrent protection like the pmic does) resulted in the internal short being vaporized Dec 28 01:39:15 bye bye esd protection diodes, but hey the board "worked" again ;) Dec 28 01:39:23 interesting Dec 28 01:39:37 unscrew the fuse, put a penny under it, screw it back in... Dec 28 01:39:44 there's something poetic about a chip being killed by overvoltage and then resurrected using overcurrent Dec 28 01:40:08 Did he observe the massive current draw and scream IT'S ALIIIVE afterward? Dec 28 01:40:14 hehehehe Dec 28 01:40:55 probably it was "whoa SHIT we should have configured current limiting.... oh it's fine now? ... ??? ..." Dec 28 01:41:37 probably the second-funniest thread I've seen on the E2E forum Dec 28 01:41:52 Back before time-domain reflectometry, ohmic measurement was the best way to estimate the distance-to-fault in telco outside plant wiring. But it only works if the fault is a nice short short. So they had this thing called a "breakdown test set", which was basically a stack of 45V batteries in series, with a selector to pick how many you were using. Dec 28 01:42:19 45, 90, 135, 180 volts... with an ammeter to see how much current was being shunted by the fault. Dec 28 01:42:44 225... eventually you'd see the current shoot up, meaning the marginal fault had finally welded itself into a true short Dec 28 01:42:52 lol Dec 28 01:43:08 quickly turn it off before you fry something, then get out the ohmmeter and do some math to figure out how many kilofeet you are from the new short Dec 28 01:43:23 Good times, good times. Dec 28 01:43:27 kilofeet.... .... ... Dec 28 01:43:35 It was the 1920s, okay? Dec 28 01:43:45 ok well I guess I will pick up a new one in the morning Dec 28 01:44:51 when you could just walk down to the corner store and buy 45-volt B-batteries for your radio's vacuum tubes, too. :P Dec 28 01:46:37 MrOlsen: my condolences for your beaglebone. may it rest in peace Dec 28 01:46:46 yep Dec 28 01:46:50 $80 out the window! Dec 28 01:47:03 cutting in my ESC budget Dec 28 01:47:12 we also have a small stack of dead beaglebones at work Dec 28 01:47:36 I should ask charlie how many dead'uns we have.. Dec 28 01:47:40 overvoltage incidents can happen really easily sometimes Dec 28 01:48:08 yeah, it's amazing some things are just more sensative... haven't really ever shorted any type of Arduino Dec 28 01:48:16 not shorted a PI Dec 28 01:48:20 shorted a few STM32 Dec 28 01:48:30 they are easy to break with overvoltage Dec 28 01:48:56 and now I learned BB is the same... But STM32 are cheap Dec 28 01:49:07 it mostly depends on transistor size Dec 28 01:49:09 I am using this for an ArduCopter project Dec 28 01:49:24 I'm surprised the rpi isn't fragile, if it truly isn't Dec 28 01:49:44 it may be, just I only use 3.3V components Dec 28 01:49:53 so I may have never been in a situation to do it Dec 28 01:50:19 using the same 3.3v power rail for everything avoids most problems Dec 28 01:50:30 the same power rail in general Dec 28 01:51:04 it's when you try to interconnect multiple power domains that headaches begin and the hardware cemetary fills up Dec 28 01:51:26 yeah Dec 28 01:51:29 this was USB Dec 28 01:51:38 i dont remember if i had the lipo on it Dec 28 01:52:50 I tried to power it with the LIPO after it was dead... but it's dead.... I will throw it in my reflo and knock all the SMD off maybe I can repurpose the WIFI, acclerometer and BMP to an arduino Dec 28 01:53:25 it actually looks to me like that 5v supply shouldn't even be present if the board is only powered via usb.... but the power circuitry of the blue is pretty complex so maybe I'm just overlooking something Dec 28 01:53:53 maybe i had it on the lipo i cant remember if the lipo was on it before or after it died Dec 28 01:56:18 My first big memorable hardware facepalm of expensive stuff involved a 486 motherboard running bare on the bench (back when 486's were expensive, god I'm old) and there was an exposed nail or screw or something sticking out of the benchtop... Dec 28 01:56:54 my guess would be: the board didn't like that Dec 28 01:57:09 Ever since then, I've cut up scrap cardboard and ziptied it to the bottoms of anything I'm gonna run like that. Takes 2 minutes, is cheap insurance. Dec 28 01:57:31 For stuff I want to look nice, I trace the board footprint (or just grab it from the design files, if available) and laser-cut something: https://www.i3detroit.org/wiki/File:Arduino-base-plate-puzzle.jpg Dec 28 01:57:46 i've given away a few hundred of those ^^ Dec 28 01:58:12 I've sometimes given boards little "feet" using polycaprolactone (a hand-moldable polymer) Dec 28 01:58:18 shapelock! Dec 28 01:58:40 e.g. https://nurdspace.nl/images/0/0a/Bbb-zmattified.jpg Dec 28 01:59:00 Oh! I saw the battery last time you posted that, looked right past the footsies. Dec 28 01:59:51 note also the little resistor that's telling the pmic the battery temperature is safe for charging ;) Dec 28 02:01:21 neat. I'm so glad the blue is finally a battery-ready board. Wish it was single-cell... Dec 28 02:01:23 alright gents, I am heading off to bed. Thanks for the help I'll check in tomorrow with a new BBBlue Dec 28 02:02:07 Good luck and sucks about being the guinea-pig for that one! Dec 28 02:02:35 what's the next steps of raising this issue with the Blue folks and ascertaining whether it's valid and a notice should be put on the pages, etc? Dec 28 02:03:26 I would do the same test again and see if the same results. But I dont want to keep throwing away $80 Dec 28 02:03:33 i will submit this to them for investigation Dec 28 02:04:05 that gps connector is just a fucking landmine Dec 28 02:04:09 it's set up for failure Dec 28 02:04:25 short a pin? Kapow! Dec 28 02:04:32 Use it as designed? Blam! Dec 28 02:04:47 [pin 1 towards enemy] Dec 28 02:05:37 and it will seem to work initially of course... and then you power down, and next time you try to power up you're left wondering what the hell happened **** ENDING LOGGING AT Thu Dec 28 03:00:02 2017