**** BEGIN LOGGING AT Wed Jun 14 03:00:03 2017 Jun 14 03:55:49 hi this is sriram from INDIA i made one PCB for Beagleboard-x15 for GPIO expansion i attached the picture of PCB below please find it below. I completed all work on that PCB.Then in that I can't able to access the gpio pins. For Example GPIO4_17 means(4x32+17=145). My doubt is can i access the pins in the board or they are hard-wired already.Please give any suggestion for alteration to access the GPIO Jun 14 03:56:31 sorry i cant able to attach the pic Jun 14 03:59:15 sriram: upload to http://imgur.com/ and share the link, please Jun 14 04:02:08 ya please wait its uploading Jun 14 04:07:54 its uploaded Jun 14 04:08:12 please find it there Jun 14 04:12:33 there are a lot of images on imgur. Can we get the link? Jun 14 04:38:30 yes i will send the link Jun 14 04:54:01 http://imgur.com/a/uBXf8 Jun 14 04:54:09 this is link for the pic Jun 14 05:04:11 I don't really understand your question Jun 14 05:04:18 what have you tried to access the gpios? Jun 14 05:04:42 btw that formula (4x32+17) is not necessarily correct Jun 14 05:04:58 it works on the beaglebone but that's mostly by lucky accident Jun 14 05:05:05 I don't know if it works on the x15 Jun 14 05:05:52 hmm, I've wanted to make an example on the proper way to identify GPIOs... maybe this is a good moment Jun 14 06:31:28 I guess sriram didn't care Jun 14 06:32:46 * zmatt made the example anyway... https://github.com/mvduin/bbb-pin-utils/blob/master/list-gpiochips Jun 14 11:15:50 Hello, any Device Tree masters around? Having problems with SPI1 on BBGW... Jun 14 11:19:51 More precisely, I'm trying to enable SPI1 via dtb (capemanager disabled). Debian Stretch, kernel 4.4-ti-rt and 4.9-ti-rt. System seems to boot but doesn't connect to WiFi. Jun 14 12:17:38 i have a question about the BBB. I've gott the microSD card imaged and hold down the USER/REBOOT button, but I cannot ever the the four LEDs to be lit solidly. Jun 14 12:35:10 hello? Jun 14 14:18:04 is the capemanager not included on the iot image? Jun 14 14:18:23 (or rather, not enabled?) Jun 14 16:31:49 sgflt: it should be Jun 14 16:32:12 the iot image only differs from the lxqt image in the absence of gui Jun 14 16:37:39 zmatt: hmm, dmesg spits out some info regarding the capemgr, but i don't have any /sys/devices/bo* Jun 14 16:37:49 did the path change? Jun 14 16:38:19 yes, ages ago, and that's nothing specific to the iot image Jun 14 16:38:31 it's in /sys/devices/platform/ Jun 14 16:38:34 ah i see. Jun 14 16:38:53 /sys/devices/platform/bone_capemgr Jun 14 16:40:10 zmatt: thank you! Jun 14 16:42:46 i'm currently using am335x-boneblack-overlay.dtb (disables hdmi audio/video, emmc) and am quite happy that my gpios are now working (P8.[13,15..27]). however, i can't use BB-UART5: `BB-UART5 conflict P8.37 (#4:univ-all)` Jun 14 16:42:51 (that is from dmesg) Jun 14 16:43:32 i do have a cape 'univ-all' in said slot, is that caused by the am335x-boneblack-overlay.dtb ? Jun 14 16:44:34 what is the recommended way to get as many gpios working as possible while still using the uarts -- does that require compiling a new .dtb? Jun 14 16:45:14 "cape-universal" lets you configure the usage of pins per pin at runtime using the config-pin utility Jun 14 16:46:24 the previous approach of using overlays to enable uarts is also still supported Jun 14 16:46:36 using a custom device tree is another alternative Jun 14 16:46:52 so you can pick whatever you prefer :) Jun 14 16:47:08 I prefer custom DTs myself Jun 14 16:51:17 *scratches head*. so just use config-pin to configure P8.37 and P8.38 as UART5 TX/RX? does that come with performance penalties? Jun 14 16:51:21 how does that black magic work? Jun 14 16:51:54 i shy away from custom DTs because they're a.) a bit of work to compile and b.) error prone if you don't know what you're doing =) Jun 14 16:52:29 they're less error-prone than overlays Jun 14 16:52:53 and take roughly 0 seconds to compile Jun 14 16:53:44 cape-universal works by basically just enabling *everything* and creating a sysfs interface to change the pinmux config on the fly from userspace Jun 14 16:54:29 it's kinda gross since peripherals are active even when not actually being used (they're unaware that their signals go nowhere due to pinmux settings) Jun 14 16:55:33 it also conflicts with basically any overlay, which can be an issue since some drivers require configuration via DT Jun 14 16:55:54 but it usually works and is kinda convenient when playing around I guess... Jun 14 16:55:57 (I don't use it) Jun 14 16:56:17 if you put it that way... Jun 14 16:57:00 assuming i wanted a custom DT, can i just use am335x-boneblack-overlay.dts, copy in all the contents from the BB-UART? overlays, compile and call it a day? i guess i need to disable the cape-universal as well? Jun 14 16:57:02 the only good excuse for overlays is to get CAPEs working "plug and play" Jun 14 16:57:19 am335x-boneblack-overlay ? you Jun 14 16:57:25 am335x-boneblack-overlay ? you're not using eMMC or HDMI ? Jun 14 16:57:39 no. i just need 4 uarts and a few gpios =) Jun 14 16:57:58 booting from SD card, using the USB connection ssh into the bone Jun 14 16:58:05 ok Jun 14 16:58:17 i would leave emmc enabled, but i chose poor locations for my gpios =( Jun 14 16:58:49 you'd either make a copy of am335x-boneblack-overlay.dts or just #include it in your custom DT Jun 14 16:59:14 and overlays can just be included verbatim? Jun 14 16:59:22 no Jun 14 16:59:41 overlays are a horrible mess compared to normal dt syntax Jun 14 17:00:32 e.g. this is how you enable an uart -> https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi except the mainline device trees uses somewhat different syntax for the pinconfig (I'm using custom macros here to increase readability) Jun 14 17:02:26 e.g. here's the piece of DT that enables the console port => https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bone-common.dtsi#L185-L190 Jun 14 17:02:28 oh right, the dtsi files Jun 14 17:02:39 the pinmux block reference is a bit higher Jun 14 17:02:42 *referenced Jun 14 17:03:19 iirc there have been .dtsi for uarts in the bbb kernel tree; i'm guessing including those into the base tree is enough? i'll give it a short Jun 14 17:03:21 *short Jun 14 17:03:23 *shot Jun 14 17:04:25 all uarts are predefined in am33xx.dtsi, so they require no actual additional config besides enabling them (status = "okay";) and a pinctrl block Jun 14 17:05:55 you can copy the actual device tree properties from the overlay sources, it's just all the crap around them that's irrelevant Jun 14 17:06:48 wait, lemme explain more clearly by example Jun 14 17:08:02 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-00A0.dts Jun 14 17:08:18 that overlay just becomes these lines in your DT: https://pastebin.com/KsHQs4b5 Jun 14 17:09:33 i kinda see that. however that still is a nightmare to debug if you're not very sure to know what you're doing =) Jun 14 17:10:30 well at least you'll get errors if you use undefined references in the main device tree Jun 14 17:10:42 (while undefined references in an overlay just result in silent breakage) Jun 14 17:16:21 here's another look at that same fragment -> https://pastebin.com/vuZHhri1 Jun 14 17:16:44 but reformatted a bit and with some explanation of what's going on Jun 14 17:17:03 zmatt: thanks. where can i find docs on the pinmux> Jun 14 17:17:05 ? Jun 14 17:19:02 eh, combination of places I guess... I've tried to make that last pastebin hopefully clarify mostly how it works :) Jun 14 17:19:33 some_label can be anything, it's just to be able to reference the node Jun 14 17:19:46 i guess i'll take another look at it Jun 14 17:20:04 likewise the node needs a name but what name doesn't really matter (as long as it's not the same as some other pinmux node) Jun 14 17:20:37 the value of the "pinctrl-single,pins" property is an array of the form Jun 14 17:21:01 you can group those for readability, i.e. , , , ...; Jun 14 17:21:16 (confusingly no commas are used to separate elements inside < > ... that's a bit of weird syntax) Jun 14 17:21:34 the pin should be one of those BONE_P9_ or BONE_P8_ constants Jun 14 17:22:11 zmatt: that's not the only thing weird about the syntax =) Jun 14 17:25:19 zmatt: again, thank you. that has been very helpful =) Jun 14 17:25:35 hold on, I'll give you another snippet that summarizes the syntax Jun 14 17:30:16 https://pastebin.com/QWdG6fBn Jun 14 17:30:28 oh whoop Jun 14 17:30:29 s Jun 14 17:30:47 https://pastebin.com/GTNsJpPH sorry, fixed :) Jun 14 17:33:22 so basically a device tree source file is a list of "fragments", each of which patches some part of the device tree to add new nodes and add/change properties Jun 14 17:33:51 (you can actually even delete nodes or properties later on, although that's not frequently used) Jun 14 17:34:30 labels are used to easily reference nodes regardless of where they are in the device tree Jun 14 17:34:57 (you can alternatively reference a node by path using &{/foo/bar} but nobody does that) Jun 14 17:35:45 bbl, gotto do some shopping Jun 14 17:36:35 actually, nm that Jun 14 17:42:54 zmatt: i've gotten it to work now. now i can finally tackle all those bugs in the board i threw together carelessly... Jun 14 17:51:13 sounds like fun Jun 14 18:05:55 Hey guys, just got my hands on a beagleboard blue. Anyone know where to get the cables that plug into the GPIO connectors? I can't seem to find any info on them. Jun 14 18:07:36 JST Jun 14 18:09:25 Ah, thanks. That led me right to it. Cheers Jun 14 18:09:35 (JST-SH) Jun 14 18:12:35 Since I connected my FPGA to my BBG I get Bus Erros very often but sometimes it works without problems. And when I disconnect all wires again the Bus error persists. Before I connected anything except Ethernet and Power the problem never occured. Jun 14 18:13:24 I have to reboot several times until it works again. Jun 14 18:13:33 how to debug such an issue? Jun 14 18:15:25 well apparently you have a working setup ("Before I connected anything...") and a non-working setup... investigate what the differences are and how they may be affecting the fpga communications Jun 14 18:16:01 This is what dmesg says: https://pastebin.com/rwMeXNwZ Jun 14 18:16:25 that just says "bus error" Jun 14 18:17:28 Is this a problem of my source code or something different? Jun 14 18:18:34 it could really be anything, hardware or software Jun 14 18:19:02 you could try to see if it's possible to check GPMC registers for more info Jun 14 18:19:15 At the moment only Ethernet and USB for powering is connected to the device and I still get bus errors. Jun 14 18:19:51 Hm... GPMC says nothing to me. I will try to find some information about it through a google search. Jun 14 18:20:02 I'm assuming you're using GPMC to interface with the FPGA? Jun 14 18:21:59 I am using mode 6 and 5 because I am using pr1_pru1_pru_31_0..7 and pr1_pru1_pru_r30_9..10 Jun 14 18:22:03 ohh Jun 14 18:22:11 then bus errors just means you fucked up in software Jun 14 18:23:24 okay, that's good Jun 14 18:25:00 typical reasons would be reading from an address that doesn't belong to any peripheral or belongs to a peripheral that's not enabled Jun 14 18:25:14 So maybe my dts file is wrong Jun 14 18:25:33 I have no way to make a guess based on this little information Jun 14 18:26:37 That's true. I could give you my source code. Only 3 little files, dts, pasm and a c code. So when you like to investigate I can put it on a paste Jun 14 18:30:39 have you tried simply using a debugger like gdb to see where it gets the bus error? Jun 14 18:34:42 zmatt: This is the failing call: #0 0xb6fb4f54 in __pruss_detect_hw_version () from /usr/lib/libprussdrv.so Jun 14 18:35:23 It happens in this line of my source code: if (0 != prussdrv_open(PRU_EVTOUT_0)) { Jun 14 18:36:44 hum, pruss is not enabled? not reachable? odd Jun 14 18:37:00 The line prussdrv_init(); works without problems. Jun 14 18:37:35 yeah that call does basically nothing Jun 14 18:37:43 https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c#L245 Jun 14 18:38:41 hold on, lemme quickly make a tiny util that checks some stuff Jun 14 18:39:14 oh maybe I already have one Jun 14 18:42:18 https://liktaanjeneus.nl/pru-prcm-dump.tar.gz Jun 14 18:47:00 zmatt: What is this? A binary? Jun 14 18:47:22 a tar-gzipped executable yes Jun 14 18:47:39 that uses /dev/mem to dump some info about the state of pruss Jun 14 18:48:26 memory: on | clock source: core-m4 | clock domain: sleeping | module: idle | initiator port: standby Jun 14 18:49:22 try while your program is running (or even just manually open the uio device in bash using a redirection) Jun 14 18:58:26 zmatt: Hm, some of the first lines in my c code is opening the pruss driver. Jun 14 18:58:53 if you run your program in gdb, then when it crashes it won't immediately exit Jun 14 18:59:14 then run my util in another shell Jun 14 19:00:11 Yout tool gives exactly the same output Jun 14 19:00:15 hum Jun 14 19:00:50 ok let's try this differently, do this in bash: Jun 14 19:01:00 exec 5<>/dev/uio0 Jun 14 19:01:22 that will open the pruss device as file descriptor 5 in bash Jun 14 19:01:29 then run my util Jun 14 19:02:25 again same output Jun 14 19:02:38 ok then something is seriously messed up... the kernel isn't enabling pruss Jun 14 19:02:44 at least that explains the bus error Jun 14 19:02:54 now the question becomes, why isn't the kernel enabling pruss Jun 14 19:03:13 you mentioned you had a custom dts ? Jun 14 19:03:52 zmatt: yes. Wait a minute. I reboot the beaglebone and try your tool again without executing my programm first Jun 14 19:05:18 Now it gives an other output after exec 5<>/dev/uio0 Jun 14 19:05:48 clock domain: active | main, iep, uart clock: active Jun 14 19:06:02 oh, and module: ready Jun 14 19:06:21 ok, *that* is what it's supposed to look like... you can close the fd again by doing: exec 5>&- Jun 14 19:07:19 I think that kinda excludes DT... hmm.. Jun 14 19:07:49 there were no errors in the kernel log? (other than those triggered by the bus error) Jun 14 19:08:02 before the first bus error Jun 14 19:09:04 but again my c code gives a bus error. and after killing my process and exec 5... again you tool says that all clocks are active Jun 14 19:09:37 but there are also active after exec 5>&- Jun 14 19:09:44 *they Jun 14 19:09:55 can you pastebin full kernel log? Jun 14 19:10:04 (dmesg | pastebinit) Jun 14 19:10:38 http://paste.debian.net/971494/ Jun 14 19:11:02 whoa there Jun 14 19:11:41 lines 331-370 Jun 14 19:12:11 seeing a backtrace in your kernel log is generally a very bad thing Jun 14 19:12:26 oh boy they just keep going on Jun 14 19:12:36 I know but I have no idea what that means. yes. there are several Jun 14 19:13:30 also, I don't see any bus error in this log? Jun 14 19:14:25 hm, you're right. strange Jun 14 19:15:31 the problems seem to be due to cape-universal being enabled even though it conflicts with your dts customizations? Jun 14 19:15:54 There were other errors before. Like "Unhandled fault: external abort on non-linefetch" Jun 14 19:16:43 yeah, the kernel has wrong abort messages on cortex-a8, it means "bus error on data access" Jun 14 19:16:47 That's my dts file: http://paste.debian.net/971496/ Jun 14 19:17:28 please disable cape-universal (remove the "cape_universal=enable" kernel parameter in your /boot/uEnv.txt) and reboot Jun 14 19:17:32 I used an online generator because I did not read the whole dts specifications Jun 14 19:17:45 oh, you don't have a custom dts but an overlay Jun 14 19:17:46 okay Jun 14 19:18:07 ehm, yes Jun 14 19:18:18 odd, cape-universal should get automatically disabled if any overlay is being used Jun 14 19:18:35 uhh Jun 14 19:19:14 oh, and you use a separate overlay to enable pruss? Jun 14 19:19:31 I am not sure what you mean Jun 14 19:19:39 I have only one dts file Jun 14 19:20:16 well this file only configures pinmux (in a way that's technically correct but still really weird) Jun 14 19:20:19 it doesn't enable pruss Jun 14 19:20:27 hm okay Jun 14 19:20:52 hold on Jun 14 19:20:59 There is also a setup.sh that does this: echo prudaq > /sys/devices/platform/bone_capemgr/slots Jun 14 19:22:14 That's my project: https://owncloud.freakscorner.de/index.php/s/3eMsnvUqOZoxk7I Jun 14 19:22:21 ah, so that's why cape-universal isn't being disabled... your overlay hasn't been configured to load at boot (in /boot/uEnv.txt) Jun 14 19:22:30 I run make, make install, setup.sh and then prudaq_capture Jun 14 19:23:45 With cape-universal disabled I get a "prussdrv_open() failed." without bus error or segfaults or similar. Jun 14 19:25:57 yeah that makes sense Jun 14 19:26:15 so, right now you're trying to use both an overlay and cape-universal... the two are mutually exclusive Jun 14 19:26:35 so you should either use cape-universal and use it to setup your pinmux (using config-pin) Jun 14 19:26:49 or disable cape-universal and use an overlay to enable pruss and do pinmux Jun 14 19:27:12 still I don't really understand the root cause of the kernel errors Jun 14 19:27:55 (other than cape-universal being a horrible hack) Jun 14 19:44:20 So you mean I should disable cape-universal. And then? Jun 14 19:47:16 yeah, hold on, need to check what's needed to enable uio-pruss nowadays Jun 14 19:48:23 thank you very much Jun 14 20:02:53 hi everyone Jun 14 20:04:17 i just downloaded and installed the latest debian image (iot version) on a BBB revB5 and can't find a useful documentation on how to Jun 14 20:04:23 play with PRU Jun 14 20:04:57 I found something on the web, but info. seems deprecated as paths to several files are not anymore where Jun 14 20:05:01 they are indicated Jun 14 20:05:16 any link to some useful PRU example? Jun 14 20:05:19 thank you Jun 14 20:06:52 cosscat: there's indeed a serious shortage of good authoritive docs :/ Jun 14 20:07:29 ... that i observed Jun 14 20:07:47 and it's a pitty since such a beautiful MCU as 2x PRUS Jun 14 20:08:18 indeed. I'm current helping out NTQ with pru issues, I guess you can wait in line? ;-) Jun 14 20:08:54 YES Jun 14 20:08:59 excuse the caps Jun 14 20:09:08 stupid keyboard Jun 14 20:10:13 cosscat: That's the example I used to learn communicating with the PRUs: https://github.com/google/prudaq But I hat to download an other fork because some paths have changed. Jun 14 20:16:05 @ NTQ: thank you, will have a look Jun 14 20:16:28 ... still awaiting for zmatt Jun 14 20:17:58 yeah I'm having a bit of a fight with silly stuff... I don't use the standard images at all anymore, and normally run a custom kernel... so I just installed the latest 4.4-bone kernel on one of the beagles here to replicate a "normal" environment, and now it doesn't boot -.- Jun 14 20:18:05 I think I already know why though, easy enough to fix Jun 14 20:20:56 yeah, 4.4-bone doesn't seem to have the mmcblk numbering fix, grr Jun 14 20:28:51 ok, back on track Jun 14 20:28:58 also, lol wow... Jun 14 20:29:13 :( Jun 14 20:29:14 when using my own kernel: Jun 14 20:29:18 :) Jun 14 20:29:19 Startup finished in 1.397s (kernel) + 3.453s (userspace) = 4.851s Jun 14 20:29:26 switched to latest 4.4-bone Jun 14 20:29:28 again my keyboard Jun 14 20:29:32 Startup finished in 4.552s (kernel) + 4.980s (userspace) = 9.533s Jun 14 20:30:06 i have the 4.4-bone Jun 14 20:31:02 I normally use a recent 4.9-bone with some patches and custom kernel config Jun 14 20:31:37 I have beaglebone 4.4.69-bone17 Jun 14 20:31:45 I know Jun 14 20:31:56 sure you know... dmesg ;-) Jun 14 20:31:58 (kernel 4.4.69-bone17 you mean) Jun 14 20:32:19 yes. I just copied from uname -a Jun 14 20:32:19 ok, it looked like enabling pruss should be trivial, gonna check that now Jun 14 20:32:35 ah, that "beaglebone" is just the hostname Jun 14 20:32:57 yes Jun 14 20:40:16 thanks guys. will come back tomorrow. need to sleep now. It's kind of late whereI'm based Jun 14 20:45:38 zmatt: I hope I do not waste your time too much. Jun 14 20:50:22 nah, you just happened to give me an excuse to look into this... I've been meaning to for a while Jun 14 21:00:23 argh, stupid "No children" issue... I thought that was fixed in ancient times already Jun 14 21:00:48 I don't know about what you are talking :-D Jun 14 21:13:20 ok, I tried 4.9.30-bone4 to see if things are less frustrating there... at least the mmcblk numbering fix is there, but uio doesn't even load -.- seriously, this project really could use some automated tests done on every kernel build... Jun 14 21:13:37 that would be nice... Jun 14 21:31:31 mailing some bug reports to rcn right now Jun 14 21:34:59 zmatt: Something related to my issue? Jun 14 21:35:30 just stuff I ran into trying to get PRU to work Jun 14 21:35:51 (including uio being completely broken in 4.9.30-bone4 ) Jun 14 21:37:45 okay. If you want to try my code you need to connect P8_30 to Vcc. The call is: ./prudaq_capture -o samples.txt Jun 14 21:38:30 Then data should be read from P8_39..46 into samples.txt Jun 14 21:38:31 I haven't been able to load uio_pruss successfully yet Jun 14 21:38:43 Just saying Jun 14 21:47:39 okay, unloading all modules not strictly necessary allowed uio to load Jun 14 21:47:51 apparently the kernel is just too fucking huge Jun 14 21:53:03 crap, gotto catch a bus, bbl Jun 14 21:55:35 np Jun 14 22:54:07 back Jun 14 22:55:48 Hi, how can I know what pin ttyO1 is connected to on the BBB? Jun 14 22:56:13 wb Jun 14 22:56:34 what is WB? Jun 14 22:56:43 kk: Maybe this helps you: https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view#gid=698174264 Jun 14 22:56:44 "welcome back" Jun 14 22:56:47 wb = welcome back Jun 14 22:57:19 NTQ: a shorter link to my spreadsheet is https://goo.gl/Jkcg0w :-) Jun 14 22:57:35 Thanks Jun 14 22:57:55 kk: the "signals" tab is the most useful to find which to pin(s) a signal can be mapped Jun 14 22:59:01 if you then scroll down to module "uart 1" you'll find that its txd and rxd can only be assigned to P9.24 and P9.26 respectively Jun 14 23:02:54 NTQ: rcn has already mailed back and apparently applied some of my patches to the 4.4-bone tree :) Jun 14 23:03:08 nice Jun 14 23:04:40 zmatt: Where're you from? Jun 14 23:05:17 netherlands Jun 14 23:10:29 that explains things. Jun 14 23:10:46 which? :) Jun 14 23:11:06 your qualification and skills. Jun 14 23:11:30 and you excellent english. Jun 14 23:12:18 zmatt: I am from Germany Jun 15 00:48:25 zmatt: Maybe I can contact you next week again. Usually I am working on this project wednesdays. Jun 15 00:49:21 It's a project I work on with a friend of mine and we meet only once a week **** ENDING LOGGING AT Thu Jun 15 03:00:03 2017