**** BEGIN LOGGING AT Mon Jun 04 03:00:00 2018 Jun 04 03:53:40 e Jun 04 04:31:26 i don't understand this answer: https://github.com/RobertCNelson/u-boot/issues/7#issuecomment-394205062 Jun 04 04:31:58 i wasn't asking about i2c2 or dcan0 or p9_19 or p9_20 or any of those things. it's almost like he was answering a different question than the one i was asking? totally confused. Jun 04 07:42:31 hi can you help me i connected sierra wireless modem to BBB. i turn on ppp connection. how can i connect remote controling use SIM ip address Jun 04 07:55:32 kenrestivo: ohhhhhhhhhhh he means that when cape-universal is disabled, the /ocp/cape-universal node nevertheless exists just for the mux of P9.19/P9.20 Jun 04 07:56:04 but it doesn't conflict with anything, since it's just for those two pins Jun 04 07:56:14 (which were previously fixed-function) Jun 04 07:56:56 so if you still have problems loading an overlay in that case, it's not related due to a cape-universal conflict Jun 04 07:57:06 silly me, I totally forgot about this Jun 04 08:03:31 hi can you help me i connected sierra wireless modem to BBB. i turn on ppp connection. how can i connect remote controling use SIM ip address Jun 04 08:10:26 any generic linux solution should apply. You could for example hook it up through the already installed connman, using ofono. Jun 04 11:30:50 How can I enable the SPI overlays? Jun 04 11:31:28 umbaman_: usually you don't have to. by default the /dev/spidev* devices exist and all you have to do is configure the pinmux using the config-pin utility Jun 04 11:37:55 ok. yes they do exist. thank you Jun 04 11:47:31 how come I get zeros instead of 0xFF when I connect p9_18 to p9_21? Jun 04 11:49:03 Although I transmit 0xF Jun 04 11:49:06 OxFF Jun 04 11:49:26 did you configure the pins to spi mode using config-pin?/ Jun 04 11:50:09 e.g. config-pin p9_18 spi Jun 04 11:51:10 let me try again Jun 04 11:52:23 yes I did config-pin p9_18 spi Jun 04 11:52:26 and Jun 04 11:52:41 config-pin p9_21 spi Jun 04 11:53:12 and I am using /dev/spidev1.0 Jun 04 11:53:36 shouldn't it be spidev0.0 ? Jun 04 11:54:17 also configure the clock pin (p9_22) Jun 04 11:54:19 I only have spidev1.0 1.1 2.0 and 2.1 Jun 04 11:56:20 oh, weird Jun 04 11:56:32 which image are you using? Jun 04 11:57:02 IoT latest Jun 04 11:57:38 oh right, I keep forgetting rcn never applied my patch to fix the spidev numbering... so it still has the bogus numbering unless you use a 4.14 kernel (where the bug was fixed in mainline) Jun 04 11:57:45 okay, spidev1.0 it is then Jun 04 11:58:46 it should work then, but like I said be sure to also configure the clock pin (p9.22) Jun 04 11:58:55 anyway, I gotto go Jun 04 11:58:59 bbl Jun 04 11:59:02 ok. cheers Jun 04 12:00:23 excellent Jun 04 12:00:33 im looking for beagle the dog Jun 04 12:00:37 It was the clock pin after all Jun 04 12:00:56 also im looking for culey Jun 04 12:24:39 Hey, I bought a Beaglebone black and it worked perfectly! However I putted accidentally 5V on a input pin. Now it is not responding anymore. When I plug in the power supply there is a LED that only blinks ones. Is it possible that there is some safety that has to be reset before it starts up again? Or is the BBB already death? Thanks in advance. Jun 04 12:25:17 Jafar_Belgium: it's dead, you fried it Jun 04 12:27:10 the led blink you're seeing is due to the pmic (power management ic) attempting to power up, detecting overcurrent (caused by internal short-circuit in the damaged processor), and cutting power again Jun 04 12:27:54 oke thanks for the terrible news :( Jun 04 12:28:04 is it possible to fix it? Jun 04 12:28:09 nope Jun 04 12:28:35 damn... Jun 04 12:29:42 basically for a modern SoC like this, 5V is http://www.safetysign.com/images/source/large-images/E3368.png Jun 04 12:30:11 they already had to perform small miracles to make it able to tolerate 3.3V Jun 04 15:45:13 should the rtc be able to wake the device from autosleep? Jun 04 15:57:26 .... I guess? as long as there's something to "catch" that event and make ensure the system doesn't immediately reenter sleep Jun 04 16:17:34 I'm having some trouble getting hostapd to run at startup. I can run it manually if I `systemctl mask wpa_supplicant`. Is there a "right" way to ste this up w/ debian 9.3? Jun 04 16:32:03 It looks like init is running hostapd before wlan0 is available. Jun 04 16:53:02 sounds like some dependency is missing Jun 04 16:55:00 I don't know if it's of any use, but this is the wpa_supplicant.service file we use: https://pastebin.com/dT7nBLyE Jun 04 16:55:13 I'm assuming hostapd would be similar Jun 04 17:39:50 zmatt: systemd just needs a little help to know that the hostapd service depends on wlan0 Jun 04 17:40:03 zmatt: https://bbs.archlinux.org/viewtopic.php?id=209783 Jun 04 17:40:48 yes which is why such dependencies are present in the service file I pastebinned Jun 04 17:49:11 zmatt: yes, you had it right. Thanks for the help. Jun 05 01:18:58 I see that GitHub is being acquired by MS. What gives? Are the BBB.io things still being hosted on GitHub.com? Jun 05 01:19:44 ... Jun 05 01:20:10 Oh and are the new Capes still going to be made? Jun 05 01:21:29 Nosey and needy here! Jun 05 01:21:40 dang it. brb. Jun 05 01:26:32 $7.5 billion. Is that right? Jun 05 01:28:15 Anyway... Jun 05 01:31:10 This fellow I remember came in here and almost sponsered some other Gitxxx.com thing online. Is the BBB.io stuff going to be restructered to another versioning system? Jun 05 01:31:11 ... Jun 05 01:34:58 unless and until they made questionable changes to the platform I don't see any urgent reason to do so Jun 05 01:35:08 it's easy enough to migrate if and when it becomes necessary Jun 05 01:38:45 Oh. Jun 05 01:39:18 (note I'm speaking for myself here of course, I don't know what the opinion is of the bb.org people) Jun 05 01:39:30 Otay. I see they were keeping "management on github at github." Jun 05 01:39:33 Aw. Jun 05 01:40:08 I figured since some of the people here like Linux over Win, there would be a choice to make. Jun 05 01:40:37 heritage vs. newly-discovered-ground. Ha! Jun 05 01:41:19 what does linux vs windows have to do with this? Jun 05 01:42:12 Partnership, background, and choice of use all have to do w/ that "vs." idea. Jun 05 01:42:49 ... Jun 05 01:43:49 I like tradition and if MS takes over, which is inevitable, the process changes (just like w/ the processes on our desktops). Jun 05 01:44:36 Look, either way, I care. I liked the learning of Linux, the usage, and the way things are used as of now. Jun 05 01:44:37 ... Jun 05 01:44:51 I do not want 7.5 billion dollars to change that. Jun 05 01:50:14 ...what happens to set_ and his ways? Sir, basically, it is like this. I learned all that stuff for what? Now, will I have to learn more stuff that deals w/ something "completely different?" Choices! That is all. Jun 05 01:51:24 zmatt: Have you heard anything about those new capes? Jun 05 01:54:36 brb...I need to see this storm while I can. This sucka' is bad! Jun 05 01:55:29 why would *I* hear anything about those capes? Jun 05 01:55:46 I know absolutely nothing about them other than what I've read on the mouser page you linked Jun 05 01:58:50 I do not know. You seem very knowledgeable on things around here. I thought I would ask. Jun 05 01:59:21 Mouser says May 22nd. Nope. Jun 05 01:59:44 I don't have any reason to know stuff about random pieces of hardware Jun 05 01:59:49 Oh. Jun 05 01:59:52 Now I know. Jun 05 01:59:59 if mouser is still saying that, then contact them and ask them what's up with that Jun 05 02:00:05 Okay. Jun 05 02:00:09 Good idear. **** BEGIN LOGGING AT Tue Jun 05 02:04:39 2018 Jun 05 02:15:18 hi all, I'm trying to enable UART2 on the debian stretch iot image, and it doesn't seem to be working. I have disabled the video overlay and added the BB-UART2-00A0 overlay in /boot/uEnv.txt, but I still don't see `/dev/ttyO2` appear. any thoughts on how to debug this further? Jun 05 02:16:33 geoffs: on the default image you shouldn't need to mess with overlays at all (except for disabling video if it conflicts), the various /dev/ttyS* devices should exist by default and all you need to do is configure the pins using the config-pin utility Jun 05 02:17:09 backwards-compat symlinks from ttyO* to ttyS* might still exist too, dunno Jun 05 02:20:36 zmatt: thanks, is that because of cape_universal? Jun 05 02:27:12 okay, so if I'm reading the config-pin docs right, I should be running `config-pin -a P9_21 uart` and same for P9_22 to set up UART2. But when I run that I get an error: Jun 05 02:27:12 P9_21 pinmux file not found! Jun 05 02:27:12 bash: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state: No such file or directory Jun 05 02:27:12 Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_21_pinmux/state Jun 05 02:27:56 did you remove the overlay stuff you put in /boot/uEnv.txt ? because manually loading an overlay means "cape-universal" gets implicitly disabled and config-pin is no longer functional Jun 05 02:28:12 basically you either do things the old way or the new way, but you can't mix the two Jun 05 02:28:55 ah. yeah, I was just wondering about that. I did not. Jun 05 02:43:58 okay, i removed my UART2 cape in /boot/uEnv.txt, but I still get the same error about P9_21 pinmux file not found... Jun 05 02:44:11 are you booting from eMMC or SD ? Jun 05 02:45:21 SD Jun 05 02:45:48 assuming you don't care about the current contents of eMMC, either reflash it or at the very least wipe it using "sudo blkdiscard /dev/mmcblk1" Jun 05 02:46:00 an old bootloader on eMMC can cause exactly these kinds of problems Jun 05 02:46:15 oh interesting. that's good to know Jun 05 02:47:08 I probably did flash this bb's mmc at some point Jun 05 02:54:16 okay, I ran blkdiscard as above, and rebooted. Still getting the same pinmux not fonud error **** ENDING LOGGING AT Tue Jun 05 03:00:14 2018