**** BEGIN LOGGING AT Mon Sep 09 02:59:58 2019 Sep 09 08:55:39 how can i get Angstrom cross-compile toolchain for Linux Sep 09 08:59:29 How to operate GPIO pins using QT Sep 09 09:03:32 Hello excuse me could you please give me the solution for my problem Sep 09 09:05:25 Devi21: first, the angrom images are massively outdated, you will be way better off using a recent debian image Sep 09 09:06:48 Devi21: second, there is a whole lot of documentation on gpio usage for the BBB. if you are stuck with a specific problem, feel free toask about that. but we usually to not do handholding and guiding through each step here. Sep 09 09:08:22 i am using Debian 9.5 2018-10-07 image Sep 09 09:08:36 then why do you ask about angstrom? Sep 09 09:10:09 angstrom - now there's a blast from the past .. Sep 09 09:10:53 also, your question "How to operate GPIO pins using QT" doesn't make any sense. QT is a graphics toolkit and has nothing to do with gpios Sep 09 09:21:24 my intention is Develop a simple UI (to control LED using UI button)application with BeagleBone Black. How to access BBB through QT. Sep 09 09:22:02 Devi21: just like from any other environment or language too Sep 09 09:25:24 i would like to use c++ language Sep 09 09:26:23 well then do so Sep 09 09:28:17 I want cross compilers for BBB Sep 09 09:28:53 on debian or ubuntu, arm-linux-gnueabi compilers are in the repos Sep 09 09:29:59 location of repos Sep 09 09:30:01 and this is an example using libgpio, if i read it correctly: https://github.com/e-ale/Code/blob/master/RESOURCES/buildroot/eale-gpio-app/eale-gpio-app.c Sep 09 09:30:08 Devi21: apt-get Sep 09 09:30:27 just use the sysfs interface for gpio, it's simpler :P Sep 09 09:30:42 zmatt: but not so cute, i mean... cqt Sep 09 09:30:44 qt Sep 09 09:30:59 zmatt: but yeah, would be way smpler Sep 09 09:31:16 it's like 3 or 4 lines of C code (if you omit error checking :P ) Sep 09 09:31:51 * LetoThe2nd agress and tries to kill some $CUSTOMERS again Sep 09 09:39:10 actually i can't explain my problem? but did you understand what i was told? Sep 09 09:43:34 by using BBB i want to develop a UI application on QT? how can i add cross compilers in QT for Compiling application? Sep 09 09:44:09 I've never tried getting Qt cross-compiling to work, it was easier to just compile locally on the BBB Sep 09 09:45:35 (I don't develop Qt applications myself but I helped a colleague with it. he develops applications locally on his PC, then transfers the code to the BBB and compiles it there) Sep 09 09:53:21 I saw an example "https://www.youtube.com/watch?v=yNvOyY9zK1o" but i doesn't know where can i get cross compilers. Sep 09 10:01:16 getting a cross-compiler is the easy part of getting qt cross-compilation to work, so if you already have trouble with that then you probably shouldn't bother with cross-compilation Sep 09 10:01:42 afk Sep 09 10:02:35 I'd probably just start compilation on device, but with DistCC offloading to a cross-compiler. :D Sep 09 10:14:08 yeah distcc offloading is great Sep 09 14:26:48 m Sep 09 16:55:33 Hi I am facing a problem. Sep 09 16:55:50 If anybody is so kind to help a little Sep 09 16:56:00 I have adxl345 Sep 09 16:56:55 which I have tied to p9_16-scl Sep 09 16:57:02 p9_17-sda Sep 09 16:57:12 and gpio3_19 to int1 Sep 09 16:57:23 the device registers properly Sep 09 16:57:33 but I don't see any interrupt coming from adxl Sep 09 16:57:39 my device node is like this Sep 09 16:57:50 &i2c1 { pinctrl-names = "default"; pinctrl-0 = <&i2c1_pins>; status = "okay"; clock-frequency = <100000>; #address-cells = <1>; #size-cells = <0>; adxl345@53 { compatible = "adi,adxl345"; interrupt-parent = <&gpio3>; interrupts = <19 0>; reg = <0x53>; };}; Sep 09 16:58:27 this same gpio 115 was used in button led test and it works well there. Sep 09 16:58:47 but here if same gpio I am trying to use for adxl interrupt, I don't get any. Sep 09 16:58:59 Any one have any idea what I missed here. Sep 09 17:02:51 Did you try config-pin yet or sysfs entries to change the input/output of your pin? Sep 09 17:03:54 I did exported the gpio 115 Sep 09 17:04:02 echo 115 > export Sep 09 17:04:05 cd gpio115 Sep 09 17:04:17 echo in > direction Sep 09 17:04:27 btw it was by default "in" Sep 09 17:04:40 Oh. Okay. I saw where you said something about the LED. Sep 09 17:04:42 making any other entries like Sep 09 17:04:46 echo out > direction Sep 09 17:05:04 gives error like this Sep 09 17:05:05 gpio-115 (sysfs): _gpiod_direction_output_raw: tried to set a GPIO tied to an IRQ as output Sep 09 17:05:20 nikhil: please don't paste multiline output into chat, it just becomes an unreadable mess. use a paste service like pastebin.com Sep 09 17:05:40 Did you use sudo apt install gpiod yet? Sep 09 17:05:47 set_: please don't try to help Sep 09 17:05:50 you're saying nonsense Sep 09 17:05:52 Fine. Sep 09 17:06:06 this is about a kernel driver using a gpio, not userspace using a gpio Sep 09 17:06:11 Oh. Sep 09 17:06:13 Got it. Sep 09 17:06:16 I will back down. Sep 09 17:06:30 @zmatt: Have at it! Sep 09 17:06:50 https://pastebin.com/raw/qA4ZG300 Sep 09 17:07:10 this is my device node in am335x-bone-common.dtsi Sep 09 17:07:23 nikhil: you should not modify that file Sep 09 17:07:42 Why? Sep 09 17:07:46 either use an overlay or a custom .dts (that for example #includes an another .dts and then adds your own declarations on top of it) Sep 09 17:07:57 No i don't want to use overlay Sep 09 17:07:58 because that file applies to all beaglebone .dts files Sep 09 17:08:11 I didn't say you have to, I said "either .... or ..." Sep 09 17:08:13 I want a built in device tree for my own peripherals Sep 09 17:08:34 Ohh. Yeah, I can try overlay but that's not an issue. Sep 09 17:08:36 a custom dts is fine, but then use a custom .dts Sep 09 17:08:46 don't modify a -common.dtsi file Sep 09 17:08:53 that defeats the whole point of having such a file Sep 09 17:09:37 anyway, what do oyu mean by "I don't get any" w.r.t. the gpio interrupt? Sep 09 17:09:53 because I don't see anything immediately wrong with your declaration (although you should probably add a pinctrl node for the irq) Sep 09 17:10:11 pinctrl node I have made. Sep 09 17:10:43 well not in what you just pasted Sep 09 17:10:54 https://pastebin.com/raw/qFVukYjz Sep 09 17:11:14 Also I took reference from here Sep 09 17:11:15 https://gist.github.com/pdp7/cd47cdc2a6747c8b01a5 Sep 09 17:11:30 for interrupt entries for how it should be in adxl345 Sep 09 17:11:33 those are the pins for the i2c bus, I'm talking about the irq for your device Sep 09 17:11:49 anyway, since gpio is the default, adding a pinmux node for it is optional, but still recommended Sep 09 17:13:04 i2c2 is setup by default anyway, so you'd just add a declaration for the adxl345 to your custom .dts Sep 09 17:14:54 well that's not a problem too, as i2cdetect works if I don't enable the driver. Sep 09 17:15:43 i2c chip is working with that, gpio3_19(115) is by default in gpio mux as said in button test example. So did not needed any extra mux for that. Sep 09 17:16:00 atleast that's what I thought. Sep 09 17:16:33 https://groups.google.com/forum/#!topic/beagleboard/k__0uW8DUTM Sep 09 17:16:41 also, that 0 can't be right Sep 09 17:17:01 could be, that part I am not sure, how to come up with. Sep 09 17:17:15 that's what I just said: it's not required, but still recommended to ensure the kernel knows that pin is in use and by whom Sep 09 17:17:27 and to be sure it is muxed correctly instead of assuming it's right by default Sep 09 17:17:44 the driver says IRQF_TRIGGER_HIGH | IRQF_ONESHOT Sep 09 17:17:50 for interrupt in probe Sep 09 17:18:01 oh right maybe irq type doesn't need to be specified in DT if the driver specifies it Sep 09 17:18:34 https://elixir.bootlin.com/linux/latest/source/drivers/input/misc/adxl34x.c Sep 09 17:18:41 that's the driver. Sep 09 17:20:52 I'll double check, it could be that gpio115 is actually not in gpio mode. Sep 09 17:20:58 https://pastebin.com/raw/MgK1reyh Sep 09 17:21:25 so something like this would be how I'd imagine you'd do a custom dts consisting of bbb + adxl345 Sep 09 17:21:50 might need some more #includes if they're not already included by am335x-boneblack.dts .. haven't checked Sep 09 17:22:29 if you want a nice utility for checking pin config: https://github.com/mvduin/bbb-pin-utils/#show-pins Sep 09 17:22:43 thanks for the idea, I will explicitly define the pin mux for interrupt pin with this snippet. Sep 09 17:22:53 anyway, what did you mean by "if same gpio I am trying to use for adxl interrupt, I don't get any" Sep 09 17:23:12 "don't get any" seems a bit vague. do you get an error? Sep 09 17:24:23 I mean I assumed, gpio115 (P9_27) will be already in gpio mux. Because that was written in a comment given by RobertCNelson in his exmaple driver. Sep 09 17:24:56 pins default to gpio unless configured otherwise (by bootrom, u-boot, or the kernel) Sep 09 17:25:16 P9.27 in particular will normally be gpio by default yes Sep 09 17:25:37 so I don't expect adding a pinctrl node will make any difference, nor did I claim it will. I just said it's better to add one explicitly Sep 09 17:26:54 I can't really try to help you with your actual problem yet since you haven't clarified what symptoms you're actually seeing, even though I requested details a few times now :P Sep 09 17:27:11 Errors! Sep 09 17:27:18 set_: hush Sep 09 17:27:22 No errors. Sep 09 17:27:27 Oh. Okay. Sep 09 17:27:42 cat /proc/interrupts show interrupt allocated on adxl chip Sep 09 17:28:02 but changing orientation or tapping doesn't increase interrupt count Sep 09 17:28:34 my issue was: Am I doing dts declaration correctly ? Sep 09 17:29:08 I think I did correctly, then why no interrupts. Sep 09 17:30:09 I'll debug this issue on my own, try to see if its a chip specific issue. Sep 09 17:30:16 then come up. Sep 09 17:30:18 does the device seem to work otherwise? Sep 09 17:30:28 is it sending events? Sep 09 17:30:39 yeah, with i2c tools device work. Sep 09 17:30:44 https://elinux.org/Device_Tree_Usage might help. I found this the other day. .dts! Sorry @zmatt. Sep 09 17:30:45 no I mean with this driver Sep 09 17:31:06 no evtest shows nothing. Sep 09 17:31:12 hmm Sep 09 17:31:25 (I also have some notes on DT in case it's of any interest: https://pastebin.com/XC8vB33d ) Sep 09 17:32:18 nikhil: can you check with my show-pins utility whether the gpio is high or low? Sep 09 17:34:08 maybe using IRQ_TYPE_NONE actually isn't allowed... you could try IRQ_TYPE_LEVEL_HIGH instead... I'm just not sure how the irq type spec in DT and the one specified by the driver relate/interact Sep 09 17:34:15 full logs : https://pastebin.com/raw/J63BxrVR Sep 09 17:34:46 Yes zmatt going to debug with pin utility now. Sep 09 18:17:38 Ok it works now, I bumped hard my accelerometer Sep 09 18:17:48 and it showed interrupt count increase Sep 09 18:17:57 so my testing was at fault. Sep 09 18:19:25 Yea boy! Sep 09 18:19:33 Way to go! Sep 09 18:20:51 Thanks for all the help :) set_ and zmatt Sep 09 18:21:05 I try while @zmatt knows stuff. Sep 09 18:21:10 nikhil: looks like this driver has very limited configurability via DT... most settings can only be set via the legacy platform data mechanism Sep 09 18:21:42 (this includes which events to generate, hence which interrupts to enable) Sep 09 18:21:44 actually for this sensor another iio driver was written, but I am not using that Sep 09 18:21:58 they serve different purposes I guess Sep 09 18:22:53 Yup the current interrupt is in overrun, which means if data changed, interrupt will fire, Sep 09 18:23:09 changing that data needed hard bump. Sep 09 18:23:51 thresholds are also configurable, but again not via DT Sep 09 18:24:35 I guess making this driver support DT configuration is a job left to the first person who cares enough :P Sep 09 18:25:14 well I assumed many things such as default driver will do everything nicely and keep such settings to minimum Sep 09 18:25:38 I'm sure the defaults were deemed reasonable by someone, for some purpose Sep 09 22:19:12 hello everyone Sep 09 22:20:20 I have a question regarding setting up beagleboard with yocto, since I think beagleboard is no longer working with open embedded Sep 09 22:23:16 hiwaeng: few people here use yocto... maybe try #yocto ? Sep 09 22:24:08 (the original beagleboard is also getting pretty old) Sep 09 22:25:42 zmatt oh really? so what you use ? I used beagleboard 7 years ago and now I am planning to work one it again Sep 09 22:26:01 beaglebone black mostly Sep 09 22:26:27 but everything has changed... I used open embedded angstrom Sep 09 22:26:52 but it seems it doesn't exist anymore , right? Sep 09 22:28:30 I don't really know much about openembedded, angstrom, or yocto (all of which are different things afaik) Sep 09 22:28:49 openembedded and yocto are definitely very much alive, dunno about angstrom Sep 09 22:28:49 from which website can I get setup scripts to my board? Sep 09 22:29:36 I used to clone to this link Sep 09 22:29:41 git clone git://gitorious.org/angstrom/angstrom-setup-scripts.git angstrom-setup-scripts Sep 09 22:29:56 but doesn't exist now Sep 09 22:30:59 angstrom looks pretty dead to me Sep 09 22:31:14 the website appears broken too Sep 09 22:32:17 so how can I set up a system like angstrom to my beagleboard? Sep 09 22:32:26 any guidance Sep 09 22:33:15 but still on the beagleboard website it says: Sep 09 22:33:19 Software Compatitbility Angstrom (Open Embedded) Debian Ubuntu Gentoo Sep 09 22:33:28 the official images for beagleboard and beaglebone are all debian nowadays Sep 09 22:33:35 where does it say that? Sep 09 22:33:38 it should probably be updated Sep 09 22:33:50 https://beagleboard.org/beagleboard Sep 09 22:33:55 have a look Sep 09 22:34:13 last updated 2016 Sep 09 22:34:54 you are right Sep 09 22:35:00 jkridner[m]: Angstrom should maybe be removed from "Software Compatibility" in places like https://beagleboard.org/beagleboard since Angstrom appears to be dead and gone Sep 09 22:35:41 what if I dont want to GUI? Sep 09 22:35:55 hiwaeng: if you don't have a strong preference for a particular linux distro you should probably consider using debian as it is the default Sep 09 22:36:03 most debian images do not have a gui installed Sep 09 22:36:28 is it a console image Sep 09 22:36:29 ? Sep 09 22:36:32 if you want a fairly minimalistic base you can start with the console image (assuming there's one for the old beagleboard, lemme check) Sep 09 22:37:41 huh Sep 09 22:37:43 odd Sep 09 22:38:01 what? Sep 09 22:38:27 I see only an lxqt image for some reason Sep 09 22:38:39 where? Sep 09 22:39:17 both latest official images ( https://beagleboard.org/latest-images ) and testing images ( https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots ) Sep 09 22:40:41 rcn-ee[m]: any particular reason there's no console image for the bb/bbxm ? Sep 09 22:40:44 what's the most current, correct, modern way to install the pasm program? Sep 09 22:41:49 kenrestivo: just compile from source. the exact steps can e.g. be found in the py-uio readme => https://github.com/mvduin/py-uio#uio_pruss Sep 09 22:42:02 thanks Sep 09 22:42:15 zmatt what are your recommendations for me? Sep 09 22:42:59 hiwaeng: I don't really have any specific recommendations. I don't have any of the old beagleboard variants Sep 09 22:44:55 oh well, tried to compile https://github.com/AbhraneelBera/wiringBone and got http://ix.io/1UHJ Sep 09 22:45:02 many thanks zmatt Sep 09 22:45:48 \_(ツ)_/¯ something changed somewhere. not going to worry about it Sep 09 22:46:07 kenrestivo: I mean, the pru code assembled fine, you're getting errors from the C++ code Sep 09 22:46:20 yep, it's probably bitrotted. last updated 2015 Sep 09 22:46:51 looks like they define a macro named "max" Sep 09 22:46:59 causing system headers to break as a consequence Sep 09 22:47:03 loverly Sep 09 22:47:55 that's my best guess anyway Sep 09 22:48:02 seems reasonable Sep 09 22:48:55 * kenrestivo learned long ago not to waste too much time trying to get random shit off the internet to work Sep 09 22:49:13 it's a numbers game: try it, if it works, win, if not, move on to the next one Sep 09 22:49:27 https://github.com/AbhraneelBera/wiringBone/blob/master/library/WConstants.h#L56-L57 Sep 09 22:49:36 lol, that's gonna break stuff too Sep 09 22:49:53 same header also defines min and max as macros yeah Sep 09 22:49:56 it's trying to mimic the API of arduino Sep 09 22:50:22 but that's C, not C++ Sep 09 22:50:39 this code is C++ yet these macros are absolutely incompatible with C++ Sep 09 22:51:05 again, someone's random project from 2015 Sep 09 22:51:13 yeah, I wouldn't want to touch it Sep 09 22:51:16 i don't mean to waste your time with it. i'm moving on Sep 09 22:51:33 I did put some effort into a C++ class for gpios a while back... https://gist.github.com/mvduin/578509d458da8948ae3a14a81dc639e4 Sep 09 22:52:13 i found it interesting that disabling audio overlay made hdmi go away. surprising, but happy Sep 09 22:52:21 * kenrestivo hates hdmi Sep 09 22:52:26 it shouldn't Sep 09 22:52:39 disabling audio should only disable hdmi-audio Sep 09 22:52:44 if you want hdmi gone entirely, disable video Sep 09 22:53:00 video, that's it. Sep 09 22:53:27 now i have plenty of free pins Sep 09 22:53:29 okay, why would you classify that as "surprising" ? it's the exact purpose of that config var Sep 09 22:53:51 to disable hdmi if you don't need it and want more pins available instead Sep 09 22:55:01 happy http://ix.io/1UHL Sep 09 22:55:04 same reason why you can disable audio (if you don't need hdmi audio, want those pins available, but don't want to disable hdmi entirely) or eMMC (if you want those pins available and are okay with booting from sd card) Sep 09 22:55:27 i forgot i had disabled the video, and thought disabling audio got rid of the hdmi, my bad, sorry Sep 09 22:55:52 if you want to use pasm, you'll want to use the PRU-UIO overlay instead of the RPROC one since remoteproc-pru can't load pasm binaries Sep 09 22:56:20 oh, good, thanks Sep 09 22:56:44 what's the most current, recommended way to use the PRU these days? Sep 09 22:57:01 it's been 7 years since i first got a beaglebone, still haven't made use of the PRU yet. keep saying i'm going to one day Sep 09 22:57:28 remoteproc-pru can only load ELF executables as produced by clpru (TI PRU CGT), libprussdrv (C library for uio-pruss) can only load raw binaries as produced by pasm, py-uio (my python library for uio-pruss and uio in general) can load both, although it doesn't yet support the resource table in ELF executables Sep 09 22:57:50 I use uio-pruss and am in zero hurry to move to remoteproc-pru Sep 09 22:58:10 I'm not sure if remoteproc-pru's API is even stabilized yet, it kept changing for a long time I think and maybe still is Sep 09 22:58:12 very good, thanks Sep 09 22:58:59 you should definitely check out py-uio, it makes it really easy to load pru binaries, use shared memory, and introspect and manipulate the state of the PRU cores Sep 09 22:59:49 it Sep 09 23:00:21 it unfortunately doesn't have much documentation other than the README (and a small bit on the wiki), but it does have a bunch of examples Sep 09 23:00:57 (there's a wiki page describing how to read/write/mmap memory) Sep 10 00:03:21 zmatt: no one's asked about a console image for the xM (or iot for that matter) ;) Sep 10 00:04:30 the build farm could handle it no problem, if you think so i'll just enable it.. Sep 10 00:16:09 I'd say it makes sense to have a console image since it's much easier to start with a minimal image and install stuff you want than it is to start with an everything-and-the-kitchen-sink image and remove stuff you don't want/need Sep 10 00:37:48 hiwaeng: upgrade to Yocto Sep 10 00:37:53 blah Sep 10 00:38:10 rce-ee[m]: how long would it take for you to churn out one? :D Sep 10 00:38:16 for either the xM or classic Sep 10 00:40:16 a working binary would be handy to turn one of those into a network device Sep 10 02:53:50 Did flask break on the BBBW? Sep 10 02:56:08 you mean the python web framework? there's nothing beaglebone-specific about that so I feel pretty confident in saying no, it didn't Sep 10 02:56:16 Okay. Sep 10 02:56:46 I am asking b/c i wanted to rehash some ideas and try to use Flask, the MotorCape, and a .service file. Sep 10 02:56:53 Odd days. I will figure it out. Sep 10 02:57:22 I am actually seeing some updates/upgrades I need to perform now. **** ENDING LOGGING AT Tue Sep 10 02:59:57 2019