**** BEGIN LOGGING AT Fri Feb 09 03:00:02 2018 Feb 09 04:43:13 for the different spi modes do i need to manually set certain pins to pull up high or low or should that be done through a lib Feb 09 04:55:17 spi mode is not relevant for pull-up/down Feb 09 04:55:48 ideally spi mode is configured in the device tree, but you can override it from userspace when using the spidev interface Feb 09 07:06:27 hello all Feb 09 07:06:38 I a trying to run config-pin on my beaglebone blue Feb 09 07:06:45 to control p8.7 that is the led Feb 09 07:06:58 however it says P8_7 pinmux file not found! Feb 09 07:07:01 why is this? Feb 09 07:08:26 does whatever documentation you follow and library you use match the current kernel and overlay? Feb 09 07:08:56 pru_python: the blue has no p8 or p9 headers Feb 09 07:09:16 also I'm not even sure config-pin works on the blue? Feb 09 07:09:37 btw about uio-pruss: you can try installing a 4.9-bone kernel instead of a -ti kernel Feb 09 07:10:02 sudo ./update_kernel.sh --lts-4_9 --bone-channel ? Feb 09 07:10:04 -bone kernels don't have remoteproc-pru whatsoever, so with a bit of luck the dt there is setup for uio-pruss instead Feb 09 07:10:17 uh I've never used that script, I just apt-get install a kernel Feb 09 07:10:18 but i need the rt patched kernel :( Feb 09 07:10:31 bone has the -rt variant too Feb 09 07:10:32 "need", are you sure? Feb 09 07:10:38 also that Feb 09 07:10:57 RT does not mean "magically faster" Feb 09 07:11:10 yeah but i want my program to run on top priority Feb 09 07:11:23 no you don't Feb 09 07:11:51 prioritizing it to rt prio 50 or higher is probably a bad idea Feb 09 07:12:21 how do i set pins on the blue without config pin? Feb 09 07:12:26 using the file sytem? Feb 09 07:12:54 I didn't say it doesn't work, I just said I'm not sure Feb 09 07:13:16 okay cool, ill try that out tonight with the bone kernel Feb 09 07:13:25 try config-pin -l or so Feb 09 07:13:34 it does show with -l Feb 09 07:13:41 the gpio info Feb 09 07:17:04 oh ew they still use the p9/p8 terminology for most pins of the blue Feb 09 07:17:13 I see now that it does support cape-universal Feb 09 07:17:24 and by "support" I mean it's included hardcoded into the base dts Feb 09 07:20:10 based on a quick browse of the dts for 4.9.80-bone-rt-r9, things are setup for uio-pruss but it's not enabled by default afaict Feb 09 07:20:26 so you'd need to add a &pruss { status = "okay"; }; block Feb 09 07:21:24 hey zmatt Feb 09 07:21:29 or load the appropriate overlay Feb 09 07:21:35 yo Feb 09 07:21:35 can you help me understand what a phandle is ? Feb 09 07:21:45 i know what they *do* but not *how* or *why* Feb 09 07:22:25 unique 32-bit integer assigned by dtc to each dt node Feb 09 07:22:44 ah okay, so just a way to reference Feb 09 07:22:46 easy Feb 09 07:22:50 yes Feb 09 07:23:10 <&foo> is replaced by the phandle number for &foo Feb 09 07:24:05 (while &foo outside <> is replaced by the path of &foo as NUL-terminated string) Feb 09 07:24:33 gotcha Feb 09 08:46:34 in case pru_python shows up again, he's a slightly cleaned up version of am335x-boneblue.dts from 4.9-bone that may make it easier to read (and customize) how the pins are being configured (and which are and aren't runtime-configurable) Feb 09 08:46:39 https://pastebin.com/raw/2UWqyWYc Feb 09 15:36:58 zmatt: Hey, I just gathered a few questions, terribly sorry to bother you, but would you min deplaning how I can access pins that don't have the pru_mode via the pru Feb 09 15:37:04 like the red and green LEDs Feb 09 15:37:08 mind* Feb 09 15:40:32 those are gpio 2.02 and 2.03, so... Feb 09 15:41:19 yeah but see, when i do config-pin -l it shows the modes for those, but with -q it throws the pinmux not found error Feb 09 15:41:39 write 1 << 2 or 1 << 3 (or a bitwise-or of those) to register 0x481ac190 to set them low or 0x481ac194 to set them high Feb 09 15:42:03 they have a fixed configuration in the dt Feb 09 15:42:32 here's a slightly cleaned up version of am335x-boneblue.dts from 4.9-bone that may make it easier to read (and customize) how the pins are being configured (and which are and aren't runtime-configurable): https://pastebin.com/raw/2UWqyWYc Feb 09 15:42:58 there isn't much to configure about those pins anyway Feb 09 15:43:07 zmatt: will you be online for some time now? I got some time off college work and I want to get the PRUs working today! pretty please?? Feb 09 15:43:23 other than gpio the only useful mode might be the timer modes (to pwm them) Feb 09 15:43:44 I'm online but only sporadically paying attention Feb 09 15:43:53 thats cool enough :) Feb 09 16:03:04 I want to use the pyqtcharts module for a gui on the beaglebone. It's only available for python3.5. Is there an easy way to install 3.5 on the bb? Feb 09 16:03:15 or will I need to complile from source Feb 09 16:05:38 sudo apt-get install python3 Feb 09 16:07:07 that gets me 3.4 Feb 09 16:07:29 or is there a newer version of debian that includes 3.5? Feb 09 16:07:42 are you on jessie? Feb 09 16:07:43 debian stretch (stable) is 3.5.3 Feb 09 16:07:48 bingo Feb 09 16:07:55 debian buster (testing) is 3.6.4 Feb 09 16:08:03 sweet Feb 09 16:08:04 thanks Feb 09 16:08:55 fyi, I am looking into packaging pyqtgraph for meta-qt5 if you are a Yocto Project user Feb 09 16:09:24 cool. I'm still undecided between yocto and buildroot. Last time I tried buildroot. Feb 09 16:12:51 zmatt: so if I get it right, I can only use the files under pru_pru_pins: pinmux_pru_pru_pins in my dts along with the PRU? Feb 09 16:13:06 ?? Feb 09 16:13:49 im following derek molly's book, so in that, for the blink example, he sets the pru pin modes for the in and out pins Feb 09 16:14:06 to be able to use peripherals with pru, they should be first set to pru mode right Feb 09 16:14:20 uhhh Feb 09 16:15:04 if you want to use the fast direct pru gpio capabilities that some pins have, they need to be configured into that mode Feb 09 16:15:33 since all pins are already being configured by the main dts in case of the blue, you shouldn't try to set pinmux using an overlay Feb 09 16:15:35 but how will i access any general gpio without using the r30/r31 registers? Feb 09 16:15:51 read my answer to your question earlier about the leds Feb 09 16:15:57 oh and also, how do i check what dts is currently loaded and being used? Feb 09 16:16:12 u-boot source code or messages on the serial console Feb 09 16:16:12 i didn't get what you meant by the bit shift operations Feb 09 16:16:55 each gpio controller manages up to 32 gpios Feb 09 16:17:05 correcft Feb 09 16:17:08 for various registers these are represented by the 32 bits of that register Feb 09 16:17:26 in particular that's true for the "clear output" and "set output" registers Feb 09 16:29:44 I just tried the ./setup_sdcard.sh for the first time Feb 09 16:29:51 and created an image for the beaglebone black Feb 09 16:30:03 sudo ./setup_sdcard.sh --mmc /dev/sdc --dtb beaglebone Feb 09 16:30:51 kernel panics Feb 09 16:31:10 https://pastebin.com/iwmYTkjA Feb 09 16:39:17 zmatt: So I've loaded bone kernel 4.9, any reason why the green wifi led doesn't light up when connected? Feb 09 16:43:25 maybe its declaration is missing from the dt for whatever reason? Feb 09 16:49:32 zmatt: hey so some progress.. I cloned pypruss and ran the blinkled example (after installing am335x_pru_package), and it throws this: File ./blinkled.bin open failed Feb 09 16:49:44 Segmentation fault Feb 09 17:05:13 right so Feb 09 17:05:32 even if i run the example from derek molly's book, it throws the same segmentation fault error Feb 09 17:11:48 zmatt: success! the bin file was loaded succesfully Feb 09 17:24:50 zmatt: hey how can i see what program is running on the PRU currently? Feb 09 17:29:53 zmatt: I defined the LED as GPIO2_2 1<<2 Feb 09 17:30:31 where GPIO2 is 0x481ac000 Feb 09 17:33:33 hi everyone Feb 09 17:40:48 zmatt: could you explain what the GPIO_SETDATAOUT/GPIO_DATAOUT offsets are? Feb 09 18:09:18 pru_python: did you mean GPIO_CLEARDATAOUT? Feb 09 18:10:25 They set/clear the GPIOs respectively Feb 09 18:11:20 you give a bitmask if the GPIOs you wish to change state. Feb 09 18:12:32 mattvenn_: why are you using such an ancient u-boot? Feb 09 18:13:44 mattvenn_: it seems especially jarring since you're using a very recent kernel Feb 09 18:39:53 does anyone know how to enable/shut down pru cores using uio_pruss Feb 09 18:40:36 something like the uio equivalent of: echo 4a338000.pru1>/sys/bus/platform/drivers/pru-rproc/unbind Feb 09 18:41:18 there's presumably some function to halt cores Feb 09 18:41:54 also, unbind? talk about a heavy-handed solution Feb 09 18:42:02 I doubt that's what you're supposed to do with remoteproc either Feb 09 18:42:26 oh shucks Feb 09 18:42:56 zmatt: did you get a chance to see how I defined my LED gpio? Feb 09 18:43:52 I have no idea what you meant by what you said Feb 09 18:44:26 int prussdrv_pru_disable(unsigned int prunum); Feb 09 18:44:31 sounds like what you're looking for? Feb 09 18:44:37 yep got it Feb 09 18:44:58 my USR2 LED is flashing continuously, what does that mean? Feb 09 18:45:41 usr2 is by default configured to indicate cpu load (of the cortex-a8) Feb 09 18:45:58 cpu activity I should say Feb 09 18:52:45 zmatt: if you have couple of mins, heres my pru code: https://pastebin.com/XZKMyac7 Feb 09 18:53:05 I also happened to make a tiny (untested) example: https://pastebin.com/raw/ZzHUQ6FJ Feb 09 18:53:21 zmatt: I referred to this table:https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv Feb 09 18:53:53 (needless to say you shouldn't turn them on and off again without inserting a large delay, since you won't be able to see the blink otherwise) Feb 09 18:54:27 you may find my spreadsheet more readable than that csv -> https://goo.gl/Jkcg0w it has a BBBlue tab Feb 09 18:55:06 oh man this is so much better eesh Feb 09 18:55:21 please use parentheses when #defining expressions Feb 09 18:56:00 noted Feb 09 18:56:23 #define GPIO2_2 1<<2 is rather hazardous, since GPIO2_2 + GPIO2_5 would be interpreted as 1<<(2+1)<<5 Feb 09 18:56:45 what's gpio 2.05 anyway? Feb 09 18:56:47 * zmatt looks it up Feb 09 18:57:03 ah the pause button Feb 09 19:00:17 zmatt: any other mistakes? Feb 09 19:00:29 zmatt are you the guy who wrote the make getting started with beaglebone? Feb 09 19:00:41 Bongobong: uh, no? Feb 09 19:01:18 guy was named matt and said go to #beagle and i was like what are the odds Feb 09 19:02:32 pru_python: I'm still reading Feb 09 19:02:45 pru_python: a bit of comments really wouldn't have hurt, e.g. https://pastebin.com/raw/2BhAyn2u Feb 09 19:02:46 zmatt: yes boss.. Feb 09 19:03:04 zmatt: sorry! i was in a hurry to get it to work Feb 09 19:03:09 note that you could also just enable the master port from the cortex-a8 instead of spending pru code on it Feb 09 19:03:19 how do i do that Feb 09 19:03:54 you can write to everything in pruss when using uio-pruss... I can check for you in a moment Feb 09 19:09:30 for polling the pause button you want GPIO_DATAIN, not DATAOUT Feb 09 19:10:19 oh you are polling DATAIN, your constant just has the wrong name Feb 09 19:11:20 oh sheet, ill change that Feb 09 19:12:24 zmatt: sorry to interrupt, but none of the LEDs are working on the board, since i changed to 4.9 bone Feb 09 19:12:26 why is that Feb 09 19:14:28 uhh, I don't know? pastebin the output of dmesg Feb 09 19:16:51 you're polling GPIO2.31 instead of GPIO2.05 Feb 09 19:23:09 ahh shit Feb 09 19:29:10 well i am trying to turn led on using adafruit_bbio Feb 09 19:31:21 but it is not loading any pin Feb 09 19:31:51 missing file it says Feb 09 19:39:22 heres the dmesg: https://pastebin.com/kgMT6QM6 Feb 09 19:43:13 I also think you had the pause button test inverted Feb 09 19:44:02 I was fiddling a bit with what seemed to be the nicest way to write this code... https://pastebin.com/raw/4U2ZHDwE Feb 09 19:44:42 oh I fucked up Feb 09 19:45:25 where? Feb 09 19:45:32 https://pastebin.com/raw/vvN7Pz5z Feb 09 19:46:33 ah Feb 09 19:47:03 so, when you said "none of the LEDs are working on the board", what do you mean by that exactly? Feb 09 19:47:09 I mean you mentioned seeing usr2 activity Feb 09 19:47:27 ITS WORKIING Feb 09 19:47:40 sir i bow down to thee Feb 09 19:47:48 also, whatever error you got from adafruit_bbio is probably a bug in adafruit_bbio Feb 09 19:47:57 i meant Feb 09 19:48:02 that like for example Feb 09 19:48:07 wifi led wasn't turning on Feb 09 19:48:44 PRU_EVTOUT_0 is defined as 3 ... that seems weird to me Feb 09 19:49:50 it should be 0 right Feb 09 19:52:14 writing 32..47 triggers event 16..31 in the pruss intc Feb 09 19:53:16 (a bit awkward. in prussv1 writing 32..63 triggered event 32..63 in the intc) Feb 09 19:54:29 dtbh Feb 09 19:54:49 tbh* I am not still comfortable with the PRUSS, ill read up more and work on this Feb 09 19:55:12 But the blinky has lifted my spirits up! Feb 09 19:55:55 I hope my "cleanup" of the code didn't make it too hard to understand ;) your code was also pretty close to working anyway Feb 09 19:56:11 lemme see if I see anything obvious wrong with the wifi led Feb 09 19:56:24 a few questions: 1) what is this: .setcallreg r3.w2 Feb 09 19:56:57 it tells the pru compiler to use r3.w2 for storing the return address for call/ret Feb 09 19:57:11 (this is the designated register for it in the EABI) Feb 09 19:57:20 okay Feb 09 19:58:12 the slightly odd choice of using r14 for the argument is also defined by the EABI Feb 09 19:58:32 there's no real reason to follow EABI here, but I figured there's also no reason not to Feb 09 19:59:43 well apart from what it stands for, I don't know anything about EABI :( Feb 09 20:00:06 it's just a set of conventions about stuff like which registers to use for certain things Feb 09 20:00:23 it would matter if you were to try interfacing between asm code and C code Feb 09 20:00:49 asm??? Feb 09 20:00:56 i.e. it doesn't matter :) but it's as good a pick for a random register as any other Feb 09 20:01:07 assembly? you know, what you're writing in Feb 09 20:01:17 oh ahaha :) Feb 09 20:02:09 yeah the wifi led is just... missing Feb 09 20:02:22 from the dt definitions for the bbblue in 4.9-bone Feb 09 20:02:35 i would eventually want to pass "parameters" to the pru asm code using global memory, like the pwm duty cycle etc, is that where it would be needed? Feb 09 20:02:43 nope Feb 09 20:03:00 it's not relevant at all for you Feb 09 20:03:30 like I said, I just figured it's as good a pick for a random register as any other Feb 09 20:03:36 phewee Feb 09 20:03:52 or, well, some registers have some special uses in certain situations Feb 09 20:04:01 r14 is definitely not one of those Feb 09 20:04:37 umm.. i don't have a /opt/source/dtb-4.9-bone Feb 09 20:05:01 here are some notes I once made about pru registers: https://pastebin.com/raw/sTcQAMfB Feb 09 20:05:03 is it in the overlays Feb 09 20:05:07 ? Feb 09 20:05:13 what? Feb 09 20:05:31 I have no idea what lives in /opt/source or what would put it there, I just checked in the git repo Feb 09 20:05:39 oh lol Feb 09 20:06:25 oh looks like 4.9.x in dtb-rebuilder is even less uptodate Feb 09 20:06:43 eesh Feb 09 20:07:44 would someone ever get around to updating it and adding small stuff like the wifi led etc Feb 09 20:08:34 i have a question Feb 09 20:08:45 would uio_pruss run on 4.4-bone Feb 09 20:08:49 btw, how did you end up enabling uio-pruss ? did you add a declaration to the dts and recompile? Feb 09 20:08:56 (if so, *which* dts ?) Feb 09 20:09:21 when i installed 4.9-bone it started by default Feb 09 20:09:26 but Feb 09 20:09:30 huh Feb 09 20:09:54 that's... weird. the dts didn't look like it was enabled by default Feb 09 20:09:57 maybe I overlooked it Feb 09 20:10:11 when i was trying before, i had to #include "am33xx-pruss-uio.dtsi" Feb 09 20:10:25 yeah no it worked on boot :p Feb 09 20:10:43 when you did recompile your dtb, where did you put it? Feb 09 20:11:27 oh nm I'm blind Feb 09 20:11:35 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.80-bone-rt-r9/arch/arm/boot/dts/am335x-boneblue.dts#L524-L526 Feb 09 20:11:38 it's right fucking there Feb 09 20:12:13 lol :) Feb 09 20:12:37 it wouldn't be hard to mix-and-match the 4.9-bone and 4.9-ti device trees to get the best of both Feb 09 20:12:56 btw, the adafruit library works for kernels 4.4 Feb 09 20:12:59 as for your earlier question about 4.4-bone... why on earth would you want to use such an ancient kernel? Feb 09 20:13:04 any ideas why they won't work for 4.9 Feb 09 20:13:28 adafruit breaks all the time, it generally does silly things Feb 09 20:13:35 cuz i had sub-zero knowledge about embedded linux, now I have slightly above zero Feb 09 20:13:43 about linuc* Feb 09 20:13:46 linux* Feb 09 20:13:56 just write to sysfs directly Feb 09 20:14:26 yeah ill prolly just write up my own py script to do that :p Feb 09 20:16:43 looks like there are pretty significant differences between 4.9-ti and 4.9-bone device trees for the blue... the 4.9-bone one is just older it seems Feb 09 20:18:10 I'll see if I can fix up a proper dt later, first I gotto do some stuff, bbl Feb 09 20:18:54 yeah cool Feb 09 20:18:59 thanks again :) Feb 09 21:04:44 I still wonder how the *heck* the Quick Branch if Greater/Less Than (or Equal) instructions ended up being defined the way they are... (qbgt label, a, b means branch to label if b > a) Feb 10 00:22:32 Hey all, does anyone have any suggestions, I recently got a PocketBeagle, I flashed an image to it and it was working, shut down my computer and then started it back up and the beagle won't boot, tried flashing the same image onto the SD card again and tried the revision before. All of them just have my "power" LED lit up, none of the other LEDs which previously lit up are lighting up. Any ideas on things to check? Feb 10 00:32:19 Did you have any peripherals connected to the pocketbeagle at the time the PC was shut down? Feb 10 00:33:23 No, nothing was attached other than the SD card was inside Feb 10 00:37:48 Well that's weird. I don't have any smoking-gun ideas at this point, I'm trying to think of what other questions I should ask to get more info out of you so the experts can weigh in :P Feb 10 00:38:12 alright, thanks for the help! Feb 10 00:38:46 I really should get a pocketbeagle, they look interesting. Feb 10 00:39:26 I don't have much experience with development boards so not sure if there's something obvious I'm missing, but it was working and now its not. Not sure if maybe I have a defective board? I've tried multiple computers, micro USB cables, SD cards, tried downloading and flashing the SD card from 2 different computers in case something weird was there all to no luck Feb 10 00:54:32 those are all the standard steps, it sounds like the board might just be bad, are you still within the seller's return period? Feb 10 00:55:55 I'd imagine so -- I'll look at the return process and try to return it, thanks! Just was wondering if there was anything obvious I missed Feb 10 01:07:16 Any chance you have another SD card to try? That's the last thing I can think of. They do fail, definitely.. Feb 10 01:08:56 Actually come to think of it, the highest-failure-rate electronics in my life are... microSD cards, microUSB connectors, and power supplies, in that order. Feb 10 01:21:57 (the reason I was asking about peripherals connected while powered down, see the bold notes in this section: https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#71_Expansion_Header_Connectors ) **** ENDING LOGGING AT Sat Feb 10 03:00:01 2018