**** BEGIN LOGGING AT Thu Apr 14 02:59:58 2016 Apr 14 03:49:31 Oh hey there are a lot more people here Apr 14 03:53:53 Poplar: more than what? Apr 14 03:57:06 beaglebone or beagleboard Apr 14 03:57:32 ah... yeah, those are the wrong channels... we've had this one for years. Apr 14 03:57:48 join #beaglebone Apr 14 07:58:30 hey, im using the libpruio to set Pin 9_12 high or low but i doesn't work Apr 14 08:00:40 pruio_gpio_setValue(Io, P1, 0x8F) i used this command Apr 14 08:01:22 pruio_gpio_setValue(Io, P1, 1) for high and pruio_gpio_setValue(Io, P1, 0) for low Apr 14 08:01:44 but nothing happened Apr 14 08:13:04 BBW, i use pasm, but my suggestion - check dts file Apr 14 08:25:03 i checked dts file Apr 14 08:26:04 i think there is no problem with dts file Apr 14 08:35:06 can u send me your dts file to check ? Apr 14 08:37:05 ?? Apr 14 08:41:58 check pins. /sys/kernel/debug/pinctrl/44e10800.pinmux/pins Apr 14 08:42:53 By the way, which kernel you use? Apr 14 08:44:44 debian 3.8 Apr 14 08:45:07 pwm ecap everything work Apr 14 08:48:15 only gpio :3 Apr 14 08:48:22 i tested my pins Apr 14 08:48:25 same thing Apr 14 08:53:27 What is the value in front of the address? (0x878) Apr 14 08:57:15 what value i used this fonction to set the gpio high pruio_gpio_setValue(Io, P1, 1) Apr 14 08:57:23 P1: P9_12 Apr 14 08:59:57 if you want use P9_12 how GPIO (GPIO1_28, pins 30), you need set 7 in you dts file . This is so ? Apr 14 09:05:29 i set it Apr 14 09:06:22 but nothing :\ Apr 14 09:13:30 so, than look deriction in /sys/class/gpio Apr 14 09:13:48 echo 60 > export Apr 14 09:14:13 cd gpio60 and cat direction Apr 14 09:14:43 Or change pin ) Apr 14 09:25:16 direction output Apr 14 09:25:58 i changed the pin same problem :\ Apr 14 09:26:25 have any other solution to controle gpio with libpruio Apr 14 09:48:22 Hello... Apr 14 09:48:28 What is connman? Apr 14 09:49:44 I am asking because it gets upgraded but sometimes it makes my connection faulty. Apr 14 09:52:01 Set: is connman for home automation system ? Apr 14 09:52:30 I do not think so. I think it is just one of the packages offered when I update and upgrade. Apr 14 09:53:58 I erased my old directories and files. Now, I have no files/directories on my BBB. Apr 14 09:54:10 The upgrade still wants to upgrade connman. Apr 14 09:54:14 Set: What is your distrib ? Apr 14 09:54:30 Newest: Debian. Apr 14 09:54:40 I think it was 3-27-2016. Apr 14 09:55:27 Set: What do you mean by "no files/directories on my BBB" ? Apr 14 09:55:55 Well...all of my added files and directories have been erased, i.e. my personal items. Apr 14 09:56:22 I started from scratch on this distro for my BBB. Apr 14 09:57:09 I mean that I have no .py files or added directories that I use now on the BBB. Apr 14 09:57:18 Fresh! Apr 14 09:58:57 I looked up connman on the Debian wiki but I came up short. Apr 14 10:00:23 Set: Ok, me too. I started dev on BBB. Maybe someone could help you more. Did you use WiFi for your bbb ? My opinion: you could re flash your bbb with a new image. It could solve the problem Apr 14 10:00:40 No wifi. Apr 14 10:00:49 Thank you anyway. I appreciate it. Apr 14 10:01:16 Do you know the website of derek molloy. Could help http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/#Using_Connman Apr 14 10:01:40 Yea. Oh. Apr 14 10:01:45 Heh? I will check it out. Apr 14 10:02:18 No problem Apr 14 10:03:08 I am looking at it now. It says it is for Angstrom. Apr 14 10:03:23 I wonder what it is doing in Debian... Apr 14 10:04:54 Set: if you want to disable connman: ~/ systemctl disable connman.service Apr 14 10:05:03 BBW, unfortunately, I do not know how to do it through C Apr 14 10:05:13 Okay. Oh. Apr 14 10:05:23 I will keep reading on it. Apr 14 10:05:41 Set: ok Apr 14 10:08:20 dirkk, you know some resources, which describe work with BBB with kernel 4.*?? Derek describe work with 3.9 and chapters with PRUSS the differ for jessie Apr 14 10:36:45 I hitting the road, toad. Thank you, dirkk. I appreciate the relay. Apr 14 11:24:10 ladies, gents, can anyone possibly give me some advice on how one might eliminate some nasty EMI coming from the BBB that is triggered by the on board eMMC? Apr 14 12:02:50 ladies, gents, can anyone possibly give me some advice on how one might eliminate some nasty EMI coming from the BBB that is triggered by the on board eMMC? <--- out of curiosity: what kind of interference and did you put something to mmc1 lines? Apr 14 12:04:15 Ionakka: he left already Apr 14 12:04:22 too much noise I guess Apr 14 12:05:42 oh yeah Apr 14 12:05:49 should look at those part messages bit closer :p Apr 14 18:08:32 Anyone know why when I boot up my BeagleBone Green, it has a quasi-cape loaded named univ-emmc rev00A0? Apr 14 18:08:58 It takes ahold of a bunch of GPIOs etc. Which I want to use myself. Apr 14 18:09:33 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-emmc Apr 14 18:09:51 Running Debian Jessie Apr 14 18:10:14 sounds like cape_universal Apr 14 18:10:20 you can disable it in your /boot/uEnv.txt Apr 14 18:11:04 Geof: it makes those GPIOs programmable from userspace. Apr 14 18:11:11 that Apr 14 18:11:19 see 'config-pin'. Apr 14 18:11:27 * zmatt doesn't like it though Apr 14 18:11:42 zmatt: could it be fixed? Apr 14 18:12:19 yes, by making dynamic DT changes easier and able to cover its use-cases Apr 14 18:12:57 Ok, I'll look in /boot/uEnv.txt... Stand by. Apr 14 18:14:43 or, something that would probably be much easier, make a nice generator for the main DT Apr 14 18:15:01 I don't mind waiting a few secs for a reboot to reconfigure my pins Apr 14 18:15:12 making the hw changes that require such reconfiguration typically take more time Apr 14 18:16:25 jkridner: zmatt: Rock on! I spent two hours trying to figure that out. You folks answer in one second. It was enabled in my /boot/uEnv.txt. Now it's gone. Apr 14 18:16:46 I need those pins for a cape of my own. Apr 14 18:17:10 jkridner: cape-universal conflicts with pretty much any overlay, but can't replace everything you can do in an overlay Apr 14 18:17:30 plus iirc it enables many peripherals regardless of whether they are used Apr 14 18:18:32 zmatt: it certainly does waste a little power by turning on excess peripherals. Apr 14 18:19:00 bb.org-overlays gives lots of examples to build upon----some better than others. Apr 14 18:19:01 and sow confusion by making bogus devices appear (in /dev, udev, etc) Apr 14 18:19:36 and some drivers like eqep require configuration in the DT node Apr 14 18:19:44 In IOT world (that I live in now), I want more control over what's on and off. Apr 14 18:20:28 the syntax for DT in general and overlays in particular is awful and user-unfriendly though Apr 14 18:21:29 I've spent the whole day reading the DT stuff. It's a nightmare. Weird examples, little or no documentation. uart1's called uart2. Derek Molloy's video is a big help. Apr 14 18:22:07 Is there a DT language spec somewhere? I haven't found one. Apr 14 18:22:31 Geof: yeah the dt bindings for drivers are supposed to be documented, but that assumes you know what driver you need, and in practice I found many binding docs to be wrong or outdated Apr 14 18:22:41 sure, the bison grammar file in the dtc source code :P Apr 14 18:22:45 And is there a place that lists all the BB's stuff? Like how do I know that uart1 is uart2 without just blindly copying. Apr 14 18:22:55 uart1 is uart1 Apr 14 18:23:29 the only place it's called uart2 is in ti,hwmods and that's something you never need to write yourself normally since it's in the main am33xx.dtsi Apr 14 18:23:58 All the examples that I've found look like this: Apr 14 18:24:00 fragment@1 { Apr 14 18:24:00 target = <&uart2>; /* really uart1 */ Apr 14 18:24:00 __overlay__ { Apr 14 18:24:00 pinctrl-names = "default"; Apr 14 18:24:00 pinctrl-0 = <&sb_uart1_pins>; Apr 14 18:24:01 status = "okay"; Apr 14 18:24:03 }; Apr 14 18:24:05 }; Apr 14 18:24:33 maybe that was the case on some ancient kernels, but definitely not on current ones Apr 14 18:25:20 I'm just pulling stuff off the web. That's the problem with not having any source for documentation. GIGO Apr 14 18:25:43 it's useful to inspect am33xx.dtsi for reference Apr 14 18:26:04 So if I'm using Debian Jessie, I should call uart1 uart1? Ok, I'll do that. Apr 14 18:26:52 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.1.20-ti-r58/arch/arm/boot/dts/am33xx.dtsi Apr 14 18:27:29 And is gpio1 gpio1 too? Apr 14 18:27:30 CELLDTR { Apr 14 18:27:30 that defines the nodes you're referencing with "target" Apr 14 18:27:30 gpio-name = "CELLDTR"; Apr 14 18:27:30 gpio = <&gpio3 5 0x00>; /* &gpio3 is GPIO2*/ Apr 14 18:27:30 output; Apr 14 18:27:30 init-low; Apr 14 18:27:32 }; Apr 14 18:27:35 yes Apr 14 18:27:54 Thank goodness you guys are online. :-) Apr 14 18:28:01 brb, need to do some shopping before they close Apr 14 18:33:37 Geof: note btw that it depends on the kernel, not the debian release as such... you can install a 3.8 kernel (which has the 1-based numbering apparently) on jessie, or a newer kernel on wheezy Apr 14 18:33:49 really brb now Apr 14 18:34:26 :-) Apr 14 18:35:16 I grab what Nelson puts on the Debian page: Jessie Snapshot IOT Apr 14 19:08:03 back Apr 14 19:08:56 Geof: as for the syntax of DTs, it's not really hard since DTs are actually quite simple and stupid datastructures Apr 14 19:10:22 I agree, but it's not clear to me where you find a language reference that tells you want the possibilities are. Apr 14 19:11:16 For example, in the snippet from 14:27:29 above, I am guessing that that sets the initial values of a GPIO. But when I look, they don't seem to be set. Apr 14 19:12:37 the init-low doesn't work? Apr 14 19:12:43 it should Apr 14 19:13:15 Well, I tried loading the dto (echo HXHXHH > $SLOTS) and it worked. Apr 14 19:13:48 Then I tried looking at the GPIO (cat /dev/class/gpio/gpio44/direction) and it was still an input. Apr 14 19:14:08 And I read the value /sys/class/gpio/gpio44/value too and it was zero. Apr 14 19:14:27 hmm, you exported it *before* loading the dtbo? that might be giving trouble Apr 14 19:14:48 I'll try again. I might have loaded dtbo then exported. Apr 14 19:15:19 Stand by... Apr 14 19:15:43 iirc you don't need to export gpios if you use gpio_helper but I might remember incorrectly Apr 14 19:16:19 I'm actually quite sure of that Apr 14 19:17:12 http://gerbil.xs4all.nl/show-pins-v3.pl <-- this may be useful Apr 14 19:17:58 it gives a detailed overview of pin configuration/state Apr 14 19:18:32 including what in the kernel/DT claimed the pin Apr 14 19:19:14 also the directions and values of all gpios (whether exported via sysfs or requested by another driver) Apr 14 19:21:14 Ok. I just tried exporting, then loading the DTO, then checking and no change. Apr 14 19:21:51 no, they should *not* be exported Apr 14 19:22:30 can you show (link / pastebin) the whole overlay? Apr 14 19:25:43 I still don't understand why overlays use such horrid syntax... they could just have used the same syntax you'd use in a dtsi Apr 14 19:26:07 I once started on patching dtc to fix that, but since I never use overlays myself I kinda lost interest Apr 14 19:29:32 Geof: also, syntax for DTs: https://git.kernel.org/cgit/utils/dtc/dtc.git/plain/Documentation/dts-format.txt?id=HEAD Apr 14 19:30:11 http://pastebin.com/dEazVnHx Here's my whole file... Apr 14 19:31:44 howdy folks -- is there a concise guide to building a bootable beaglebone image with custom software on it? Apr 14 19:32:28 note that there's no reason to give child nodes of &am33xx_pinmux such long names... I don't know where that habit came from, but they're already child nodes of the pinmux node, so e.g. I'd use "uart4_pins: uart4 {" Apr 14 19:32:31 IPmonger: probably not the most concise: http://builds.beagleboard.org - http://beagleboard.org/source Apr 14 19:32:57 (there's no reason for a prefix since it's not possible for two overlays to be using uart4 at the same time) Apr 14 19:33:08 IPmonger: probably buildroot is the easiest, but the Debian images are very flexible with lots of packages. Apr 14 19:33:41 thanks jkridner Apr 14 19:36:16 Geof: one of the child nodes of your gpio helper contains a "GPIO" property instead of "gpio", that's not good Apr 14 19:36:27 Geof: other than it looks fine to me Apr 14 19:37:22 loading it *should* automatically export those gpios... they also look different from normal exports since they don't have a direction attribute (since this is selected in the DT node) Apr 14 19:37:37 Ok, I fixed the GPIO and shortened the uart names. I'll try it again... Apr 14 19:38:32 What does this mean? compatible = "gpio-of-helper"; Apr 14 19:38:40 it indicates the driver for that node Apr 14 19:39:02 And is that already there somewhere? I didn't write it anywhere else. Apr 14 19:39:27 the kernel drivers have lists of "comaptible" strings that it'll get matched to Apr 14 19:40:14 compatible can list multiple strings (usually from most specific to most general), the first one for which the kernel can find the matching driver gets used Apr 14 19:43:33 for existing nodes (such as the uarts) the compatible property is already defined, hence you usually don't specify it in an overlay, but sb_gpio_help is a new device node technically hence you need it Apr 14 19:44:33 status = "okay"; however is not necessary there, it's only needed to override the status = "disabled"; property that most predefined devices have to keep them disabled until activated by the main dts or an overlay Apr 14 19:46:30 Ok, it worked!!!!! Apr 14 19:47:19 I rebooted to clear the world up. Loaded the overlay now with GPIO spelled right. And the /sys/class/gpio/gpio44/value worked perfectly. Apr 14 19:48:10 if you check with my show-pins-v3.pl utility you'll see that the pins will now be listed with your helper node in parentheses (instead of "sysfs" as shown for manually exported gpios) Apr 14 19:48:53 I'll remove the statu="okay" from sb_gpio_help. Thanks for all your help! This is great. Apr 14 19:50:25 And I'll give the showPins a try too. Apr 14 19:50:55 tip: make the terminal sufficiently wide ;) Apr 14 19:51:02 it has a fair number of columns Apr 14 19:51:29 and you can pipe it through sort to get it sorted by expansion pin number (by default it is sorted by processor pin number) Apr 14 19:51:46 (by which I mean index into the pinmux array) Apr 14 19:57:01 very cool tool I just ran it. You're my hero. Thanks for all your help today. I think I'm done for today. :-) Apr 14 19:57:44 heh, yo9 Apr 14 19:57:46 you're welcome Apr 14 20:00:14 Geof: if you ever have a need/interest to see the state of pins other than those on the expansion header, you can pass the -v option once or twice to my script Apr 14 20:00:51 (passing it twice includes _all_ pins, including those which are really not useful to see) Apr 14 20:01:12 excellent. Apr 14 20:02:16 Now that I've given my pin a name (e.g. BLEDTR), is that in the file system? somewhere? Apr 14 20:03:21 ah, that part still sucks... Apr 14 20:03:40 there's a directory for your helper in /sys/devices/platform/ Apr 14 20:03:47 it contains a status attribute Apr 14 20:04:16 which includes the names and gpio numbers Apr 14 20:05:40 that driver really ought to have made a directory with named symlinks to the gpios... but unfortunately it doesn't Apr 14 20:11:20 Ok, thanks very much. Apr 14 20:11:36 but since the paths to the gpios are the same on every boot, you can of course manually make such symlinks in a directory somewhere for convenience Apr 14 20:20:11 Yes. That's perfect. Apr 15 01:57:13 finally figured out where to type Apr 15 01:57:40 I have lost the BeagleBone name and logo on my BBB Apr 15 01:57:47 anybody know how to get it back? Apr 15 01:58:15 Jake___: odd... you want to put it on the silkscreen? Apr 15 01:58:33 I don't think there is an easy way. Apr 15 01:58:37 just on the device when I plug it in Apr 15 01:59:19 I'm new, so only easy will work for me Apr 15 01:59:38 thanks anyway Apr 15 01:59:51 anybody else online know the answer? Apr 15 02:00:13 bye Apr 15 02:56:06 join #connman **** ENDING LOGGING AT Fri Apr 15 02:59:58 2016