**** BEGIN LOGGING AT Sat Nov 11 03:00:02 2017 Nov 11 13:49:13 Hi guys. I have detectected a something strange. Since I configured the SoftAp Settings in /etc/default/bb-wl18xx. I can only connect ssh into the board if wifi is conected(I am logged into SoftAp). But if I connect the wifi than I can suddenly ssh in via 192.168.6.2 also. Nov 11 13:50:00 in /etc/default/bb-wl18xx I only changed PW + SSID Nov 11 15:26:01 hi everybody ! question about pwm Nov 11 15:26:21 I have configured ping P9_14 as pwm with config-pin Nov 11 15:26:52 but, where can i set duty and period ? Nov 11 15:35:26 /etc/dogtag --> BeagleBoard.org Debian Image 2017-10-10 Nov 11 15:54:22 nmingotti: check /sys/class/pwm ? Nov 11 15:58:12 hi zmatt !! Nov 11 15:58:24 I landed there readin this page: https://goo.gl/9UhGEv Nov 11 15:58:39 but, in that directory i don't have the "export" file Nov 11 15:58:52 which the blog page uses, so now i am stuck Nov 11 15:59:03 that sounds odd Nov 11 15:59:12 what's in there? Nov 11 15:59:44 ls gives: pwmchip0 pwmchip1 pwmchip3 pwmchip5 pwmchip6 Nov 11 16:00:05 and these don't have the export attribute? Nov 11 16:00:35 I think yes, let me check Nov 11 16:00:47 beware of old articles btw, a lot has changed in recent times Nov 11 16:02:12 yes, yes, I saw, since cape universal a lot of things are different Nov 11 16:02:17 so while some of the stuff in that article is still vaguely right (e.g. his description of how he figured out which pwmchip represented what is a useful strategy) Nov 11 16:02:32 other details are definitely different Nov 11 16:03:06 yeah cape-universal is now the default Nov 11 16:04:21 so in that regard you're lucky that this article used it even though it wasn't enabled by default at the time (it looks like the article was written for the debian wheezy / kernel 3.8 era) Nov 11 16:04:41 ah it actually says so at the top Nov 11 16:06:41 is there some place to look for docs in general ? I am not used to read linux kernel readme but I can start to do it;) ... reading drivers, nope, i am not ready for that Nov 11 16:06:41 so, it looks like back then pwm device numbering was global across all pwmchips, similar to the situation with gpio Nov 11 16:06:49 that has changed, it's now per-pwmchip Nov 11 16:08:18 so, assuming pwmchip0 is ehrpwm0, /sys/class/pwm/pwmchip0/pwm1 would be ehrpwm0b Nov 11 16:08:32 let me check Nov 11 16:08:46 and if it's not there yet, you'd need to write 1 to /sys/class/pwm/pwmchip0/export Nov 11 16:10:02 finding docs that are actually accurate and up-to-date can be a bit challenging sometimes Nov 11 16:10:47 echo 1 > /sys/class/pwm/pwmchip0/export ===> Nov 11 16:10:50 echo: write error: No such device Nov 11 16:10:50 Nov 11 16:11:09 maybe pwmchip0 isn't ehrpwm0 ? check what it symlinks to Nov 11 16:11:11 maybe P9_14 is not on pwnchip0 Nov 11 16:11:59 P9.14 is ehrpwm1a Nov 11 16:12:49 for an overview of what signals are available on which pins, the "P9" and "P8" tabs of this spreadsheet I made may be of use -> https://goo.gl/Jkcg0w Nov 11 16:13:04 let me see Nov 11 16:14:06 I confirm ehrpwm1a for P9_14 from the table i took from Molly website Nov 11 16:17:46 to connect the names like "ehrpwm1a" to sysfs names like "pwmchip0" i need to use the memory addresses, correct ? Nov 11 16:19:12 I need to go out for an half hour, c u later if u will be still here, bye ! Nov 11 16:20:09 I'll probably be around, or maybe shopping Nov 11 16:25:01 another way of identifying devices is by checking what the /sys/class/pwm/pwmchip*/device/of_node symlinks point to and comparing those with the path specified in /proc/device-tree/__symbols__/ehrpwm1 Nov 11 17:01:41 i'm back Nov 11 17:26:13 I have a Beaglebone Black and I want make the LEDs light up by directly writing to the GPIO registers using C and memory mapped IO. I have someone else's working solution (cf https://pastebin.com/cMTXf2KH). I worked on understanding it and expanded it and ended up with this code (https://pastebin.com/6r98JEWf) that seems a lot nicer to me. Nov 11 17:26:34 Main difference is that i am not writing to GPIO_DATAOUT directly anymore because I wanted to avoid overwriting other registers Nov 11 17:27:54 However, obviously, I did something wrong when writing my version. One of the mistakes was that I calculated the memory maps for SETDATAOUT and CLEARDATAOUT incorrectly. So it might very well be possible that i wrote to other GPIO registers by accident Nov 11 17:27:56 yeah don't write to dataout Nov 11 17:28:16 do be very careful when meddling with gpio directly Nov 11 17:28:29 well, i did my best :D Nov 11 17:28:49 some mistakes (e.g. accidently changing inputs to outputs) may risk hardware damage Nov 11 17:29:44 so, what are my options? as of right now, the LEDs blink in a seemingly random pattern and running the first, working, version of the code changes nothing Nov 11 17:30:06 did i mess it up for good or is there some way to diagnose the problem? Nov 11 17:30:15 uhh, change their trigger via /sys/class/leds/ ? Nov 11 17:30:58 I mean, I'm assuming you just wanted to practice using direct gpio via memory-mapped registers and figured the leds were a convenient target Nov 11 17:31:19 if really all you want to do is toggle the leds, use /sys/class/leds/ Nov 11 17:31:50 the first one is the case Nov 11 17:32:04 okay Nov 11 17:33:21 well, step one would be writing "none" to each of /sys/class/leds/*/trigger Nov 11 17:33:53 otherwise you're fighting with the kernel over those leds ;) Nov 11 17:35:14 yeah my code already does that Nov 11 17:36:08 basically i am moderately sure i have it figured out and the code is correct, however I can't test it because right now, not even the code that worked in the first place (first paste) has any effect anymore Nov 11 17:36:29 can still ssh, compile and run.. Nov 11 17:48:16 uhhhhhh Nov 11 17:48:41 your first paste looks like a really really bad idea Nov 11 17:50:28 oh, you didn't stick around Nov 11 18:18:01 Hi, can someone point med in the direction of how to build linux from the source (beagleboard 4.4-rt source), and make an image of it? Nov 11 18:19:15 4.4-bone-rt or 4.4-ti-rt ? Nov 11 18:20:03 easiest way build rcn's kernel is using his build scripts, e.g. https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-rt-4.4.y for the 4.4-ti-rt series Nov 11 18:20:40 https://github.com/RobertCNelson/bb-kernel/tree/am33x-rt-v4.4 is the equivalent for 4.4-bone-rt Nov 11 18:22:12 I was thinking of using this one: https://github.com/beagleboard/linux/tree/4.4-rt Nov 11 18:22:33 yeah that's 4.4-ti-rt Nov 11 18:23:29 ahh ok. I've tried the TI kernel before, but then the PRU didnt work as expected (using prussdrv). Nov 11 18:23:31 so use the first of the two links I gave for that Nov 11 18:24:17 note that this isn't the "TI kernel" in the purest sense, rather they're rcn's builds based on TI's kernel Nov 11 18:24:29 uio-pruss is definitely enabled by default in those Nov 11 18:25:09 alright, I can try it again I guess. Nov 11 18:25:17 or rather, the -ti kernels support both uio-pruss and remoteproc-pru, it depends on the DT which one is selected Nov 11 18:25:40 in the latest images you can select which one you want via config options in /boot/uEnv.txt Nov 11 18:27:16 so what is the main difference between the ti and non-ti kernels? Im making multi threaded applications on the beaglebone using SPI's, I2C's GPIOS and the PRU. Nov 11 18:27:56 the -bone series are somewhat closer to mainline than the -ti series Nov 11 18:28:05 either would work fine for what you're describing Nov 11 18:28:13 I'm using 4.9-bone series myself Nov 11 18:29:49 note btw that since the cortex-a8 is single-core, using Nov 11 18:29:50 ok, I need to reduce the jitter so im trying out the RT kernel. Do you by any chance know if there is a difference between the ti-rt or just regular rt? Nov 11 18:30:19 note btw that since the cortex-a8 is single-core, using multithreading will generally just add overhead and better avoided when possible Nov 11 18:30:53 I'm pretty sure -ti-rt is just -ti + -rt Nov 11 18:32:34 (in some cases separate threads are of course needed, e.g. when using an RT kernel you do need a separate thread (with real-time priority) for time-critical stuff) Nov 11 18:33:48 yeah, thats what im using the pthreads for :) Nov 11 18:34:03 another difference between the -bone and -ti kernel series is that rcn's -ti kernels are configured to also support the beagleboard-x15 Nov 11 18:35:10 which probably makes them slightly bigger and possibly less efficient than kernels tailored specifically for the beaglebone Nov 11 18:44:20 thanks :) i will go for the regular RT then! Nov 11 18:44:35 you mean -bone-rt ? Nov 11 18:45:35 "regular" is a strange word to use Nov 11 18:46:48 it could mean mainline linux (not what you want), or the default kernel (currently actually 4.4-ti) Nov 11 20:12:00 For reference to anybody who may be interested and to close a previous talk with zmatt who is always helpful Nov 11 20:12:44 i was able to find how to control pwm via sysfs Nov 11 20:13:54 The way to find which pwmchipXX to enable and what to write in "export" Nov 11 20:14:16 can be find almost painlessly coping what has been done in bonescript Nov 11 20:15:08 the two files to look at are "bone.js" which contains many info about each pins Nov 11 20:16:12 and file "hw_mainline.js" at function "setPinMode" to see in which files to touch and what to write into them. Nov 11 20:17:36 good evening folks, bye ! **** ENDING LOGGING AT Sun Nov 12 03:00:02 2017