patrick-81 Posted December 13, 2017 Posted December 13, 2017 I am on this kernel: Linux tinkerboard 4.4.102-rockchip #3 SMP Fri Nov 24 19:01:14 CET 2017 armv7l armv7l armv7l GNU/Linux But I don't understand what you mean about the guides.
Tido Posted December 13, 2017 Posted December 13, 2017 With guide I mean what I wrote in here: https://forum.armbian.com/topic/4792-tinker-board-gpio/?do=findComment&comment=45664
patrick-81 Posted December 13, 2017 Posted December 13, 2017 54 minutes ago, Tido said: With guide I mean what I wrote in here: https://forum.armbian.com/topic/4792-tinker-board-gpio/?do=findComment&comment=45664 I download and compile the library as suggested yes. And then run the test.
Tido Posted December 13, 2017 Posted December 13, 2017 Aha, I think I found the bug. I added this to the install tutorial: Before you start, I recommend Armbian for your operating system, because all tests were also done with Armbian as an Operating System with Kernel 4.14 https://www.armbian.com/download I guess you have the Asus operating system installed ?
patrick-81 Posted December 13, 2017 Posted December 13, 2017 8 hours ago, Tido said: And you followed the guides on a fresh 4.x Kernel install ? I have Armbian installed with mate desktop. And I am up to date today.
patrick-81 Posted December 18, 2017 Posted December 18, 2017 Got a lib that works here: https://github.com/TinkerBoard/gpio_lib_c.git Unfortunately it doesn't accept to work for any user whatever I can do. And I don't understand because the "gpio" command works fine for any user. For me it is a mystery. I try to look to the code, but it is like Chinese for me. Does somebody can en-light my brain ? thanks
Tido Posted December 18, 2017 Posted December 18, 2017 So you have armbian 4.4 kernel installed - and tried armbianIO that was tested on 4.14 kernel, instead of posting the error message in a code box, you now grab wiringPi for Tinkerboard OS (not armbian) and you are wondering it doesn't work. Am I right ?
patrick-81 Posted December 18, 2017 Posted December 18, 2017 Effectively I have Armbian 4.4 installed. I tested your solution armbianIO and failed. I tested the last solution I found that works well from command. I mean the gpio command. The gpio command has the suid bit set for root. Would it be necessary to set the suid bit for the wiringPi libs too ?
patrick-81 Posted December 20, 2017 Posted December 20, 2017 The new API works fine now. There was issues with the previous. But my problem now is to execute programs without being root. The only solution I find is to suid all the programs that I use (found that gpio has the suid bit set). This is not a very satisfying solution. but I don't know if there is other solution. And maybe as the structure of the calling are a bit complex I don't know what part I have to suid. The bold, the red, the green, the blue or all of them ?Kstars (astro program) --> indi server (astro server) --> Focuser driver --> libwiringPi--> [GPIO --> stepper controller --> Stepper motor] I have tested: sudo chown root:gpio /usr/local/lib/libwiringPi.so.2.31 sudo chmod u+s /usr/local/lib/libwiringPi.so.2.31 compile and execute blink.c as normal user. and got the result can't open /dev/mem and /dev/gpiomem wiringpiSetup: Unable yo ope /dev/mem... I don't know what I can do else.
willycat Posted March 6, 2018 Posted March 6, 2018 Thanks for yours fast responses. I installed the default image and the audio works well. But now, i have a new issue: my python script used to handle the power button doesn't work (it worked fine with the mainly image) and it is very boring because the power led on top of the case stay on even if the board is off. Here is my script: #!/usr/bin/python import RPi.GPIO as GPIO import time import os,sys import signal #GPIO.setwarnings(False) GPIO.setmode(GPIO.BOARD) GPIO.setup(31,GPIO.OUT) GPIO.setup(33,GPIO.IN) GPIO.output(31,GPIO.LOW) def shutdown_system(channels): os.system("sync") time.sleep(1) os.system("shutdown -h now") sys.exit() GPIO.add_event_detect(33,GPIO.RISING,callback=shutdown_system) while True: time.sleep(1) When i execute the script: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.new gpio = 238 Traceback (most recent call last): File "/usr/share/PiDesktop/python/restart.py", line 22, in <module> GPIO.add_event_detect(33,GPIO.RISING,callback=shutdown_system) RuntimeError: Failed to add edge detection Pin 31 is really configured as an output and pin 33 as an input as showed below: root@tinkerboard:/home/willy# gpio readall +-----+-----+---------+------+---+--Tinker--+---+------+---------+-----+-----+ | CPU | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | CPU | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 252 | 8 | SDA.1 | | 1 | 3 || 4 | | | 5V | | | | 253 | 9 | SCL.1 | | 1 | 5 || 6 | | | 0v | | | | 17 | 7 | GPIO0C1 | IN | 0 | 7 || 8 | 1 | SERL | TxD1 | 15 | 161 | | | | 0v | | | 9 || 10 | 1 | SERL | RxD1 | 16 | 160 | | 164 | 0 | GPIO5B4 | IN | 1 | 11 || 12 | 0 | | GPIO6A0 | 1 | 184 | | 166 | 2 | GPIO5B6 | SERL | 1 | 13 || 14 | | | 0v | | | | 167 | 3 | GPIO5B7 | SERL | 1 | 15 || 16 | 1 | IN | GPIO5B2 | 4 | 162 | | | | 3.3v | | | 17 || 18 | 1 | IN | GPIO5B3 | 5 | 163 | | 257 | 12 | MOSI1 | | 0 | 19 || 20 | | | 0v | | | | 256 | 13 | MISO1 | | 1 | 21 || 22 | 0 | IN | GPIO5C3 | 6 | 171 | | 254 | 14 | SCLK1 | | 1 | 23 || 24 | 1 | | CE0 | 10 | 255 | | | | 0v | | | 25 || 26 | 1 | | CE1 | 11 | 251 | | 233 | 30 | SDA.2 | | 1 | 27 || 28 | 1 | | SCL.2 | 31 | 234 | | 165 | 21 | GPIO5B5 | IN | 1 | 29 || 30 | | | 0v | | | | 168 | 22 | GPIO5C0 | OUT | 0 | 31 || 32 | 1 | SERL | GPIO7C7 | 26 | 239 | | 238 | 23 | GPIO7C6 | IN | 0 | 33 || 34 | | | 0v | | | | 185 | 24 | GPIO6A1 | | 0 | 35 || 36 | 1 | SERL | GPIO7A7 | 27 | 223 | | 224 | 25 | GPIO7B0 | SERL | 1 | 37 || 38 | 0 | | GPIO6A3 | 28 | 187 | | | | 0v | | | 39 || 40 | 0 | | GPIO6A4 | 29 | 188 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | CPU | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | CPU | +-----+-----+---------+------+---+--Tinker--+---+------+---------+-----+-----+ Here is a part of the kern.log file after executing the script: Mar 6 15:12:19 localhost kernel: [ 611.528620] ------------[ cut here ]------------ Mar 6 15:12:19 localhost kernel: [ 611.528670] WARNING: CPU: 1 PID: 3450 at drivers/gpio/gpiolib.c:85 gpio_to_desc+0x68/0xbc() Mar 6 15:12:19 localhost kernel: [ 611.528680] invalid GPIO 238 Mar 6 15:12:19 localhost kernel: [ 611.528688] Modules linked in: zram lz4_decompress lz4_compress 8723bs uas Mar 6 15:12:19 localhost kernel: [ 611.528724] CPU: 1 PID: 3450 Comm: restart.py Not tainted 4.4.119-rockchip #4 Mar 6 15:12:19 localhost kernel: [ 611.528733] Hardware name: Rockchip (Device Tree) Mar 6 15:12:19 localhost kernel: [ 611.528765] [<c0110104>] (unwind_backtrace) from [<c010bde8>] (show_stack+0x20/0x24) Mar 6 15:12:19 localhost kernel: [ 611.528789] [<c010bde8>] (show_stack) from [<c05bcd70>] (dump_stack+0x84/0xa4) Mar 6 15:12:19 localhost kernel: [ 611.528809] [<c05bcd70>] (dump_stack) from [<c011e104>] (warn_slowpath_common+0x98/0xc4) Mar 6 15:12:19 localhost kernel: [ 611.528828] [<c011e104>] (warn_slowpath_common) from [<c011e170>] (warn_slowpath_fmt+0x40/0x48) Mar 6 15:12:19 localhost kernel: [ 611.528847] [<c011e170>] (warn_slowpath_fmt) from [<c05f4bb8>] (gpio_to_desc+0x68/0xbc) Mar 6 15:12:19 localhost kernel: [ 611.528867] [<c05f4bb8>] (gpio_to_desc) from [<c05f6d54>] (export_store+0x3c/0xe0) Mar 6 15:12:19 localhost kernel: [ 611.528889] [<c05f6d54>] (export_store) from [<c0709d58>] (class_attr_store+0x28/0x34) Mar 6 15:12:19 localhost kernel: [ 611.528909] [<c0709d58>] (class_attr_store) from [<c02abc34>] (sysfs_kf_write+0x48/0x54) Mar 6 15:12:19 localhost kernel: [ 611.528927] [<c02abc34>] (sysfs_kf_write) from [<c02ab14c>] (kernfs_fop_write+0x150/0x19c) Mar 6 15:12:19 localhost kernel: [ 611.528947] [<c02ab14c>] (kernfs_fop_write) from [<c023ed6c>] (__vfs_write+0x3c/0xe4) Mar 6 15:12:19 localhost kernel: [ 611.528967] [<c023ed6c>] (__vfs_write) from [<c023f520>] (vfs_write+0xbc/0x144) Mar 6 15:12:19 localhost kernel: [ 611.528986] [<c023f520>] (vfs_write) from [<c023fc60>] (SyS_write+0x50/0x88) Mar 6 15:12:19 localhost kernel: [ 611.529006] [<c023fc60>] (SyS_write) from [<c0107600>] (ret_fast_syscall+0x0/0x48) Mar 6 15:12:19 localhost kernel: [ 611.529046] ---[ end trace d2b3067e9760c78b ]--- Mar 6 15:12:19 localhost kernel: [ 611.529057] export_store: invalid GPIO 238 Do you have an idea of the problem or does i need to come back to the mainline image and wait for the audio fix to become available ? Thanks, Willy.
Jamess Huang Posted March 9, 2018 Posted March 9, 2018 Hi, willycat Can you show the result of the below cmd ? $ ls /sys/class/gpios
TonyMac32 Posted March 9, 2018 Posted March 9, 2018 I just caught up on this, I think this will be due to not rolling back the base 1000 change from Rockchip. I did not notice that right away, it's certainly an unexpected change... tony@tinkerboard:~$ ls /sys/class/gpio export gpiochip1024 gpiochip1088 gpiochip1152 gpiochip1216 unexport gpiochip1000 gpiochip1056 gpiochip1120 gpiochip1184 gpiochip1248
Jamess Huang Posted March 9, 2018 Posted March 9, 2018 Yes, It's caused by this commit https://github.com/rockchip-linux/kernel/commit/3b7424f3327304988431eca44adf92e59999aa2b#diff-3e6c33bd6c3a2e7db0ba4fd6b1c2612fR28
DVE Posted April 24, 2018 Posted April 24, 2018 Hi all, I'm using Armbian_5.41_Tinkerboard_Debian_stretch_default_4.4.119, and get the same problem. I'm testing this code: https://github.com/TinkerBoard/gpio_lib_python/blob/sbc/tinkerboard/python/test/add_event_callback.py (pin was changed to 40). Output: new gpio = 188 Traceback (most recent call last): File "add_event_callback.py", line 22, in <module> GPIO.add_event_detect(pin, GPIO.BOTH, callback=my_callback) RuntimeError: Failed to add edge detection How can I fix it? Thanks.
TonyMac32 Posted April 24, 2018 Posted April 24, 2018 If that code depends on the memory mapped IO driver, that is still in the development branch.
DVE Posted April 25, 2018 Posted April 25, 2018 Thanks. Stupid question: is Tinker OS GPIO code and pin numbers is compatible with Armbian? I was using https://github.com/TinkerBoard/gpio_lib_python library, but should it work on Armbian at all?
chwe Posted April 25, 2018 Posted April 25, 2018 9 hours ago, DVE said: I was using https://github.com/TinkerBoard/gpio_lib_python library, but should it work on Armbian at all? https://github.com/armbian/build/pull/907
TonyMac32 Posted April 25, 2018 Posted April 25, 2018 If anyone has put considerable time into testing this let me know. Otherwise it has to stay in the develoen branch for a while longer
chwe Posted April 25, 2018 Posted April 25, 2018 2 hours ago, TonyMac32 said: If anyone has put considerable time into testing this let me know. Otherwise it has to stay in the develoen branch for a while longer as long as it fails to compile it as a module, I'm a bit concerned to "deliver" it to everyone... I gave it one shot, compiling it as module but it didn't worked properly (but I didn't look deeper into it and may not have the time to do it atm)... gpiomem is with 666 relatively open for every user to make things people may not want (especially for users which don't use GPIOs at all and might not notice that there's a new gpiomem in /dev... ). A possibility to load it as a module or would be preferred IMO. Or we set it with more restrict rights and add it to something like a GPIO group but I don't know how much adjustments are needed to bring it up that way.
TonyMac32 Posted April 25, 2018 Posted April 25, 2018 as long as it fails to compile it as a module, I'm a bit concerned to "deliver" it to everyone... I gave it one shot, compiling it as module but it didn't worked properly (but I didn't look deeper into it and may not have the time to do it atm)... gpiomem is with 666 relatively open for every user to make things people may not want (especially for users which don't use GPIOs at all and might not notice that there's a new gpiomem in /dev... ). A possibility to load it as a module or would be preferred IMO. Or we set it with more restrict rights and add it to something like a GPIO group but I don't know how much adjustments are needed to bring it up that way. Fair. If I have a bit of time I'll look at the driver and see two things:1) can it be compiled as a module and2) can I use the device tree to load it so it isn't a problem for the MiQi.I need to get on the device tree overlays work, that's the only way most of this stuff will ever be properly done, like those lame 2-lane cameras.Sent from my Pixel using Tapatalk
chwe Posted April 25, 2018 Posted April 25, 2018 4 minutes ago, TonyMac32 said: 1) can it be compiled as a module and it can (ore parts can be compiled as module) but it didn't work properly.. 5 minutes ago, TonyMac32 said: 2) can I use the device tree to load it so it isn't a problem for the MiQi. or you write the corresponding device tree for the MiQi too so that both can benefit from it. I'm not sure if ASUS developed it.. Cause this one here: https://github.com/joerg65/gpiomem_tinkerboard looks very similar and he uploaded it on 27 Sep 2017, Asus did it a few days later 12 Oct 2017. Would be a bit nasty if they stole his code and removed him as an author (there are some differences and I don't want to start a shitstorm here, but we might clarify it first do it right. ).
Frank Wu Posted April 26, 2018 Posted April 26, 2018 11 hours ago, chwe said: it can (ore parts can be compiled as module) but it didn't work properly.. or you write the corresponding device tree for the MiQi too so that both can benefit from it. I'm not sure if ASUS developed it.. Cause this one here: https://github.com/joerg65/gpiomem_tinkerboard looks very similar and he uploaded it on 27 Sep 2017, Asus did it a few days later 12 Oct 2017. Would be a bit nasty if they stole his code and removed him as an author (there are some differences and I don't want to start a shitstorm here, but we might clarify it first do it right. ). 4 Hi @chwe, Nice to meet you. I'm one of Tinker Board team member and also is the one of in charge of the community. I remember for this case. We have required our RD team need to take a kindly asking with joerg65 to get the confirm. (And we got the approved to add it) Even as we know, it's an open source and public codes, we can directly use them by following GPL license. But we also would make a confirm with them. Because we want to let everyone understand, we are very serious about all contribution in the open source world. So, please don't worried about this. Kindly let us have few days to double check it more internally. And discuss with RD team, to know how can we do for let it better, e.g. add missed commit log or other ways to prove is joerg65's contribution. BR, Thanks.
chwe Posted April 26, 2018 Posted April 26, 2018 First of all, I appreciate your fast answer. And that there's clarification inside your team. 1 hour ago, Frank Wu said: Even as we know, it's an open source and public codes, we can directly use them by following GPL license. But we also would make a confirm with them. Because we want to let everyone understand, we are very serious about all contribution in the open source world. I don't think that he would have a problem that you use his code. But in his version there was a small add on top: Quote /* * Ported to rk3288 from Jörg Wolff, 2017 */ For me, there's no reason to remove this small credit part. 1
Jamess Huang Posted April 26, 2018 Posted April 26, 2018 Hi, chwe Thanks for your remind. It indeed is our mistake. We have updated the commit and reserve all of the original information. https://github.com/TinkerBoard/debian_kernel/commit/de8ac6cdee368fd27bea9ecaa9149087029ea52c 1
Recommended Posts