**** BEGIN LOGGING AT Mon Aug 01 02:59:58 2016 Aug 01 03:24:54 hello, I'm a new beaglebone black owner and not very good with linux. I wanted to setup the beaglebone black running debian to connect to my wifi router. The usb wifi dongle I use is recognised and I fiddled a while with wpa_supplicant and connmanctl without success. ifup wlan0 says: "Ignoring unknown interface wlan0=wlan0" eventhough the interface is there. Then I noticed that the beaglebone created a wifi access point Aug 01 03:26:33 Why is this the default behaviour? This is really confusing for beginner and I think that 80% of the people connecting a usb wifi dongle would want it to connect to their existing wifirouter, not creating an AP :( Aug 01 03:27:53 can someone please show me where to turn off the start of this AP so I can use the usb dongle to connect to my wifi router? thanks in advance! Aug 01 05:51:43 hello Aug 01 08:01:10 I am trying to boot my BBB powering it via USB and my pc detects a connection via USB Ethernet Aug 01 08:01:10 but none of the light by the USB port on the BBB light up and i cant ssh into it Aug 01 08:01:10 what could be the problem? Aug 01 08:10:33 tomlukeywood: if the 4 leds don't come on or blink at all you shouldn't see a usb network connection either Aug 01 08:10:42 weird... Aug 01 08:11:01 It was booting before Aug 01 08:11:54 then i tryed to boot another system on it using a micro sd card Aug 01 08:11:55 and after that (even after removeing the micro sd card) it has not worked Aug 01 08:13:31 maybe the sd card overwrote something? Aug 01 08:15:12 if it did how would i get a OS back on it? Aug 01 08:15:29 there should be instructions on beagleboard.org Aug 01 08:15:45 basically take an official image, edit one line in the uenv.txt Aug 01 08:16:19 and boot from SD card? Aug 01 08:18:57 yes Aug 01 09:18:37 Where would i find uenv.txt? Aug 01 09:47:39 if the image has a FAT32 partition, then on that Aug 01 09:47:56 if not, probably in /boot of the ext4 partition Aug 01 10:19:54 What should i change uEnv.txt too? Aug 01 10:38:07 tomlukeywood: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Aug 01 11:29:38 hello people Aug 01 11:49:16 Hi, I am here asking a question on behalf of a friend. A motor is being driven through beaglebone. There is an interrupt pin to the beaglebone. When the motor is turned on, ideally one interrupt should be recieved. However about 4 of them are being generated. A 16 Mhz DSO couldnt pick up the signals. Is there a way to slow down the Interrupt hardware so as to detect so many interrupts ? Aug 01 11:49:47 so as not* to detect Aug 01 11:50:27 tried putting a capacitor on the interrupt line, but didnt help Aug 01 11:50:44 next thing to try is to make an active LPF Aug 01 11:51:02 but prior to that I wanted to know if the Interrupt ciruit can be slowed down Aug 01 12:17:14 Hi, I'm trying to enable SPI0 and get to the point where /dev is populated with /dev/spidev1{0,1}; I succesfully did it with the preinstalled debian via "echo BB-SPIDEV0 >/sys/devices/bone_capemgr.9/slots". so far so good... Aug 01 12:17:31 I've created a buildroot image on a microSD based on Linux 4.1.13; /lib/firmware does not contain any dtbo file but, from what I understand, it should be possible to enable SPI0 by properly modyfying the main dts Aug 01 12:18:00 I've noticed that arch/arm/boot/dts contains "am335x-boneblack-spi0.dts": so I've tried to use that in place of am335x-boneblack.dtb but still no luck Aug 01 12:58:46 jayaura: yes, it's either discrete debounce or debounce in software. On the software side you would then discard interrupts that are within timeframe x of a previous interrupt. I'm not sure if the hardware or kernel driver has any debounce capability itself. Aug 01 12:59:33 david-e: you're on the right way, you'll need to modify the .dts file and then recompile it to a dtb Aug 01 13:01:29 tbr: that's what I think I've done. after the reboot I still can't see /dev/spidev1{0,1} though Aug 01 13:08:29 hmm, make sure the dtb you put in place is the one that is used when you booted. there is a way to extract it from the kernel proc or sysfs and then inflate/decompile it. Aug 01 13:16:50 I have booted the disk image and edited the uEnv.txt file but its the same as before Aug 01 13:18:29 oh wait i gtg sorry bye Aug 01 13:18:36 AFK Aug 01 13:24:45 tbr, thank you for the resposne Aug 01 13:37:06 Hello all, sorry if it is a dumb question, but I'm kinda lost. I wanna make an embedded device running on BBB. I made an image with Yocto Krogoth (core-image-base), and it is running fine. Now I need to enable UART1, and I'm not figuring how to do it, I found lots of information about device tree but it sounded very difficult to me. Is there a not-so-complicated way to do it? Aug 01 13:55:18 xultz: no, since about kernel 3.10 this has been the 'correct' way to enable ARM peripherals - the BBB kernels have helper apps, but they only really wrap the process Aug 01 14:06:13 thank you for your answer, veremit. Do you know any document which could help me enabling the UART1? Aug 01 14:08:15 alas, not really .. I've never used angstrom/yocto on my arm boards Aug 01 14:08:42 seems like people are more active now, so I will repost my question. Hope you don't mind: Aug 01 14:08:45 I've flashed my BeagleBone Black with the latest Jessie image from: https://debian.beagleboard.org/images/ bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz Aug 01 14:08:55 nky> the problem I have now is, that whenever I plug an usb wifi dongle in, the system automatically starts a wifi access point with the SSID "BeagleBone-6400" thus preventing me from using the usb dongle to connect to my existing wifi router (for internet access) Aug 01 14:09:05 nky> this happens by default, I haven't configure anything yet. I tried to disable the hostapd with systemctldisable hostapd.service (I found hostapd.service in the systemctl list) and rebootet, but the access point is beeing created again.So, where can I disable the creation of this AP? Any why is this by default? In my opinion 80% of the people plugin in an usb wifi dongle would want to connect to a wifi router and no Aug 01 14:09:12 thank you in advance for your help :) Aug 01 14:17:16 NoPinky: that sounds like a fallback condition, certainly shouldn't be a default. I can't really offer any advice because Im not familiar with systemd Aug 01 14:20:49 NoPinky: sounds like something that hopefully is just a systemd service. check out the list of services and disable the offending one Aug 01 14:21:55 tbr: that's what I tried to achive with "systemctl disable hostapd.service", now it's not on the list anymore, but still, there is that AP :( Aug 01 14:22:10 NoPinky: and you rebooted after that? Aug 01 14:22:24 yes I did Aug 01 14:22:48 trying it right now once again to be sure with shutdown -r Aug 01 14:22:55 xultz: you'll need to figure out where the DTS is that is used for your image and then add a patch to your build files to add the UARTs you want Aug 01 14:24:16 xultz: as to the code, there should be dtsi include files that you can use as a template. These files are on a default debian image under /opt IIRC. Not sure which git repository they live in though. Aug 01 14:29:44 the AP of hell is still there :D Aug 01 14:30:23 and I have no idea from what source (script) ist spawned Aug 01 14:32:29 you should be able to klist running services.. Aug 01 14:32:36 s/klist/list Aug 01 14:36:48 I used sudo systemctl list-units -t service Aug 01 14:37:25 and there is no hostapd.service anymore or anything else that looks like it has something to do with hostapd Aug 01 14:39:16 some connman and a wpa_supplicant service is active though Aug 01 14:40:08 check those too .. Aug 01 14:40:38 you may find though you -think0 you've disabled hostapd, something else is using its config :)( Aug 01 14:41:25 I would expect systemd to be 'helpful' like that .. Aug 01 14:41:56 what do you mean with "check those too" ? like try to dissable them? Aug 01 14:42:27 you could disable them .. see what happens .. Aug 01 14:42:46 you'll still see the interface, but it shouldnt be configured .. Aug 01 14:42:59 hopefully you'll narrow down the problem .. Aug 01 14:43:02 I mean at some point I would want to use connman or wpa_supplicant to connect to a wifi network, this problem would arise again if I activate that service, right? Aug 01 14:43:13 likely Aug 01 14:43:13 ah, ok, narrow it down... okay Aug 01 14:43:41 yeah it seems drastic .. but its a data point .. :) Aug 01 14:44:15 I'm so confused that this behaviour comes "out-of-the-box" though Aug 01 14:44:51 does seem very odd. Never heard of it before though. Aug 01 14:45:57 NoPinky: you say the jessie debian image? Aug 01 14:46:06 yes I did Aug 01 14:46:17 hrm Aug 01 14:46:20 the newest and fanciest of them all :P Aug 01 14:46:50 I think I will try to apt-get remove hostapd first, let see what happens Aug 01 14:51:11 NoPinky: nailed it .. https://github.com/rcn-ee/repos/tree/master/rcnee-access-point/suite/jessie/debian Aug 01 14:51:17 it's configured by connman Aug 01 14:52:43 that RCN is gettin too clever for his own good Aug 01 14:52:54 yes, it's not hostapd, after removing the hostapd package it is still there Aug 01 14:54:03 hmm, ok and where (in which config file) is it specified, that AP from hell? Aug 01 14:54:15 looked into some, but didn't find it explicitly Aug 01 14:54:40 its a special package .. rcnee-access-point Aug 01 14:55:06 hmmm, why would a person do this? T_T Aug 01 14:55:15 https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-jessie-lxqt-4gb-v4.4.conf#L186 Aug 01 14:55:26 -shrug- it _is_ madness tbh Aug 01 14:55:36 unless you happen to be a connman pro -sigh Aug 01 14:56:01 yeah, putting this out there for all the noobs like me is jus pure evil Aug 01 14:57:31 thank you veremit, you are very helpful, now I know where the root of that evil is, atleast Aug 01 15:03:17 NoPinky: normally we could fire questions directly at RN himself .. but he's made himself scarce here lately :( Aug 01 15:03:20 it is a sad loss Aug 01 15:05:02 veremit: yeah I thought about writing him to and ask how to deal with this. But I think I will look into how to use connman, maybe there is a easy way how to list running "services" and find out how to stop the automatic creation of the AP Aug 01 15:05:47 probably Aug 01 15:05:54 I have emailed himin the past .. he is very helpful :) Aug 01 15:08:19 well, there was a commit 22hours ago by him. So it seems like he is fine... like not sick or worse. So I think he might be available for contact. But still I want to find a solution myself first Aug 01 15:09:05 yup I'm keen to 'grok' connman also fairly soon . want to use it for some embedded PCs Aug 01 15:09:19 and ARM too probably .. not sure about that project -just- yet. Aug 01 15:09:29 wpa_supplicant old-skool is still ok by me :D Aug 01 15:10:47 I still have some pogoplugs lying around, compared to the raspberry pi (even the zero) they are pretty weak in computation power and support, but still I want to find a longterm usage for them, any ideas? Aug 01 15:11:39 yeah, on the rpi and pogoplug, I also used wpa_supplicant on arch linux or rasbian, worked fine Aug 01 15:12:09 I think I wouldn't mind connman, but this default AP ... smh Aug 01 15:13:59 lol right. Does seem Odd. Aug 01 15:20:27 veremit: the "funny" thing is: the AP isn't even showing as a service! only the ethernet connection is showing while the AP is still visible ony my fones and laptop Aug 01 15:20:41 so I can't even dissable it in the cli Aug 01 15:21:13 yeah you may need to remove that evil package Aug 01 15:21:26 and/or figure how connman instantiates connections. Aug 01 15:21:34 I'm trying to modify the setting file now Aug 01 15:26:00 I commented the lines 9 to 12 out from https://github.com/rcn-ee/repos/blob/master/rcnee-access-point/suite/jessie/debian/settings . rebooted, but AP is still there Aug 01 15:26:16 that's just evil! >:( Aug 01 15:26:39 apt-get remove rcne Aug 01 15:26:50 this is now on the menu LD Aug 01 15:26:52 :D Aug 01 15:35:50 I'm looking to find the hardware specs and datasheet for the Arrow BeagleBone Black Industrial clone. Aug 01 15:36:31 The page about it on Beagleboard's site (http://beagleboard.org/arrowbbbi) has links which go to beagleboard.org/TBD. Aug 01 15:36:35 I didn't think it was an arrow product .. and hav eyou tried contacting them?! Aug 01 15:36:59 Can anyone give a status update on when and where that info will be available? Aug 01 15:37:52 afaik the industrial variant was hardware identical apart from higher spec parts Aug 01 15:38:21 element 14 has an industrial variant of the BBB Aug 01 15:38:35 there is documentation (or atleast a product page) for this Aug 01 15:39:02 https://www.element14.com/community/docs/DOC-78671?ICID=BBB-feature-link Aug 01 15:39:08 maybe they are the same Aug 01 15:39:56 ele14 certainly do manufacture Aug 01 15:40:26 Yeah, I'm using the Arrow board because the Element14 version was out of stock. Aug 01 15:40:58 The Element14 industrial board was conformal coated, and I'm trying to figure out whether the Arrow industrial board is as well. Aug 01 15:41:18 best contact your local agent Aug 01 15:41:49 what does conformal coated mean? Aug 01 15:42:15 a special clear paint coat to protect the hardware? Aug 01 15:45:56 veremint: the monster has been slain. after apt-get remove rcne-access-point. it is gone Aug 01 15:52:52 NoPinky: dayum. Yeah an email to find out wtf was he thinking is probably justified ;D Aug 01 21:00:24 does the beagleboard-x15 support wake-on-lan? Aug 02 00:16:03 * mehmet__ is Aug 02 00:28:10 vagrantc: probably depends a bit on the sleep state, but lemme check what the phy they're using supports Aug 02 00:30:34 ok, so for WoL it would need to 1. keep the phy powered and 2. wake on the interrupt line of the phy Aug 02 00:31:32 which are gpio7_26 and _27 Aug 02 00:33:43 all of its sleep states maintain power supplies on anyway, so yeah I see no obstacle Aug 02 00:40:33 but not from a cold boot? Aug 02 00:40:58 this is all part of my master plan to be able to remotely powe the thing on without having to do hardware hacking :) Aug 02 00:41:56 i guess i should just rewire the power button using some hack i've heard of to always power on Aug 02 00:42:16 why that coudn't have been a jumper setting... hrmpf. Aug 02 00:43:44 vagrantc: you need to power-up fully from cold and go straight to powersave :P lol Aug 02 00:44:01 I don't think anything besides full boards will auto-power-up from standby from cold Aug 02 00:44:12 even that -may- be optimistic Aug 02 00:44:41 yeah, just used to x86 boards that do wake-on-lan from a "cold" state, but it's surely keeping the ethernet powered up at a basic level Aug 02 00:46:04 they have a 5V 2A standby supply normally .. lol .. Aug 02 00:46:21 and yeah, all the modern boards I see have the ethernet phy perma-powered Aug 02 00:46:36 you can tell as the LEDs light when you plug a cable into an active switch/etc Aug 02 00:46:43 * vagrantc nods Aug 02 00:47:01 but that 5v 2a suuply is equivalent to your complete ARM board XD Aug 02 00:47:05 ATX spec ftw Aug 02 00:47:24 just was hoping somehow because my remote power switch can issue wake-on-lan ... since power-cycling isn't good enouhg to reset the board without manual power-on button press Aug 02 00:47:55 you need a supervisor circuit .. Aug 02 00:47:55 probably back to hardware hacking Aug 02 00:47:59 yup Aug 02 00:48:32 sometimes you can't beat a good old-fashioned relay XD lol Aug 02 00:48:55 would that actually work, though? Aug 02 00:49:12 I know people resetting Pi's with a relay .. :) Aug 02 00:49:31 sure, but they boot on power reset Aug 02 00:49:35 bbx15 doesn't Aug 02 00:49:46 ah that's a bbx15 shortcoming then .. the bbb does ... Aug 02 00:49:49 i've got that much Aug 02 00:49:54 * vagrantc nods Aug 02 00:50:04 zmatt: you got an x15 yet? Aug 02 00:51:49 every once in a while i do u-boot testing on it, and wonder if it's broken again ... until i remember i have to go to the basement and hit the power button Aug 02 00:52:10 (although sometimes even then it doesn't work... but that's another story) Aug 02 00:53:36 get it out the friggin basement man .. lolz Aug 02 00:53:59 but yeh.. maybe hardwire something across the power button and drive from an esp8266 or something :) Aug 02 00:56:52 veremit: no Aug 02 00:57:05 whoa lot of text suddenly, lemme catch up Aug 02 00:57:06 zmatt: :( Aug 02 00:57:55 veremit: it's not even available yet is it? Aug 02 00:58:21 zmatt: probably not .. unless you got an early preview edition Aug 02 00:58:33 vagrantc: I thought there was a jumper to force the pmic to automatically power up (including after software-requested shutdown) Aug 02 00:58:46 PWRHOLD or so Aug 02 01:00:07 bingo, J5 Aug 02 01:00:16 PMIC_POWERHOLD Aug 02 01:01:03 fancy that .. Aug 02 01:02:40 the only catch is that you need to be careful that you don't keep the board powered up in a state where no u-boot gets loaded, or at least such a state is not occupied for too long Aug 02 01:03:08 if J5 isn't bridged then the pmic will automatically power off again after a few seconds if that happens Aug 02 01:03:26 iirc Aug 02 01:04:09 does it detect a current peak then? Aug 02 01:05:25 or surge... and back off if it doesn't 'see' it Aug 02 01:05:32 no, there's some mechanism for software to let the pmic know that it would appreciate continued power supply plz Aug 02 01:05:41 heh right Aug 02 01:05:47 "powergood" :P Aug 02 01:06:24 that's an output Aug 02 01:06:31 right Aug 02 01:06:41 PWRON Aug 02 01:06:43 probably Aug 02 01:06:58 or not Aug 02 01:07:06 might just be a register Aug 02 01:09:31 bingo Aug 02 01:10:59 software needs to set the DEV_CTRL.DEV_ON bit Aug 02 01:11:02 in the PMIC Aug 02 01:12:10 "Upon receipt of an ON request, the TPS659037 device initiates the power-up sequence and asserts the RESET_OUT pin high when it is in the ACTIVE state (reset released). While in the ACTIVE state, the device remains active for 8 s and then automatically shuts down." Aug 02 01:12:25 zmatt: sounds sensible Aug 02 01:13:04 the host processor then either needs to arrange POWERHOLD to be asserted high, or set the DEV_ON bit via I2C Aug 02 01:14:00 powerhold is also a non-maskable ON-request Aug 02 01:16:01 of course the problem with powering on without u-boot is that the am572x inherited erratum i863 from the omap5 Aug 02 01:18:44 I see the x15 includes the option for external pull-ups on eMMC though (R250-R259), though they're marked DNI Aug 02 01:21:18 placing them would be a hardware workaround for i863, but I don't know whether it adversely impacts max eMMC speed or so (there's presumably a reason they're not placed by default) Aug 02 01:22:23 ohey silicon 2.x made some changes Aug 02 01:22:34 vagrantc: you got 2.x silicon? Aug 02 01:29:31 neat, first 10 production samples of the BBE Aug 02 01:33:18 zmatt: got it around november, i think ... i think there's been a major revision since Aug 02 01:35:55 you can check the part number (AM5728AABC vs AM5728BABC) Aug 02 01:36:08 or some register... Aug 02 01:36:18 actually 'omapconf cpuinfo' ? Aug 02 01:37:22 omapconf available in Debian? Aug 02 01:37:49 I think installed by default in rcn's images? Aug 02 01:38:02 * vagrantc doesn't run rcn's images Aug 02 01:38:25 running mainline linux on an unreleased board doesn't sound wise Aug 02 01:38:27 zmatt, vagrantc: had a classic today .. RN's installing a default AP in his connman configs now ... >< Aug 02 01:38:43 hasn't been too bad so far Aug 02 01:38:55 and if nobody runs mainline, who will fix mainline? Aug 02 01:39:00 or at least report bugs Aug 02 01:39:01 you gotta start somewhere .. Aug 02 01:39:15 vagrantc: well they do work with upstream Aug 02 01:39:18 rn's been submitting patches for x15 for &ages& Aug 02 01:39:24 exactly Aug 02 01:39:35 (and TI before the x15 even existed) Aug 02 01:39:58 yes, and having run a bbx15 as part of a build farm using mainline linux for quite some months now, i'd say it's working pretty well. Aug 02 01:40:18 0x4AE0C204 Aug 02 01:40:20 though i get the impression we could work it harder Aug 02 01:40:30 I think that register should contain the IDCODE Aug 02 01:41:08 might be easier to dump that instead of grabbing omapconf for it Aug 02 01:41:33 omapconf is afaik not in standard debian repo, but it is in rcn's debian repo or you can grab it from https://github.com/omapconf/omapconf Aug 02 01:41:58 u-boot reports Model: TI AM5728 BeagleBoard-X15 Aug 02 01:41:59 Board: BeagleBoard X15 REV A.20 Aug 02 01:42:12 that's completely uninformative Aug 02 01:46:09 actually that's not true Aug 02 01:46:41 A.20 ? Aug 02 01:46:56 my statement of it being completely uninformative Aug 02 01:47:20 your statement was quite broad-sweeping Aug 02 01:47:29 it just informs me that u-boot reports board versions in some way that can't be matched to the revision numbers on the actual schematics Aug 02 01:48:50 it still doesn't tell me your SoC revision, but anyhow it doesn't really matter as long you don't let POWERHOLD keep your board up in an ubootless state for more than 200 hours Aug 02 01:49:15 given that i often do u-boot testing ... hm. Aug 02 01:49:54 if it's really 200 hours ... hm. Aug 02 01:51:25 well it doesn't matter whether u-boot really works or not, I think it fixes the pinmux fairly early on Aug 02 01:56:57 also, warm boot doesn't reset pinmux, so the worry only exists after power on Aug 02 01:58:15 well, last resort option is a full power cycle, so ... Aug 02 02:00:13 how would you do that anyway? Aug 02 02:00:42 a remote controlled power switch Aug 02 02:01:06 so, if you power it up and see no sign of u-boot, power it off again Aug 02 02:01:35 sure, but if it power cycles while i'm not paying attention Aug 02 02:01:44 it's got an autoping power cycle Aug 02 02:01:48 if it booted once, why wouldn't it boot twice? Aug 02 02:02:09 or put some known-good u-boot on a secondary boot medium Aug 02 02:02:39 last i checked, it didn't work with sata or eMMC boot with mainline u-boot ... soo... Aug 02 02:03:02 note again: it suffces if u-boot loads, it doesn't matter whether u-boot really works Aug 02 02:03:15 or rather, it suffices if SPL loads Aug 02 02:03:19 omapconf is arguably less informative than u-boot, fwiw Aug 02 02:03:27 what does it say? Aug 02 02:03:37 (I don't remember if it's cpuinfo or --cpuinfo btw) Aug 02 02:03:51 ah it's --cpuinfo Aug 02 02:04:32 wait, am572x doesn't support ethernet boot? how lame! Aug 02 02:04:35 https://paste.debian.net/786481/ Aug 02 02:04:50 es1.1, ok Aug 02 02:05:13 so the erratum still applies Aug 02 02:06:47 if necessary just put the instructions to fix the pinmux at _start Aug 02 02:06:52 or something Aug 02 02:07:19 or make a watchdog that cuts power to your board if it doesn't check in periodically Aug 02 02:07:50 there's really a ton of options to fix or work around the problem, just pick one Aug 02 02:09:57 connect an xds100v2 and have a little script detect a reset or power-cycle and check/fix the pinmux Aug 02 02:10:23 (I just realized "warm" reset does actually reset pinmux since iirc they wired the board to have warm reset trigger cold reset) Aug 02 02:20:57 zmatt: i've struggled unsuccessfully with watchdog, but only gave it a few minutes of configuration Aug 02 02:21:57 the main failure-case i've experienced is the disk stops responding ... and supposedly the watchdog package has a filesystem test, but it didn't seem to do anything Aug 02 02:22:11 though thankfully, it's been more stable lately Aug 02 02:23:22 you're confusing two things: I'm referring to a watchdog program running on whatever is controlling the power switch Aug 02 02:24:12 and I was still referring to the powered-but-not-booting issue, where a watchdog daemon on the board itself obviously plays no role whatsoever Aug 02 02:34:08 (and yes, the watchdog daemon can be configured to performs all sorts of checks to verify the system is "okay") Aug 02 02:34:23 (unrelated note) **** ENDING LOGGING AT Tue Aug 02 02:59:57 2016