• Content count

  • Joined

  • Last visited

  1. The chgrp command is incorrect. It should be: $ sudo chgrp -HR gpio /sys/class/gpio/gpio10
  2. You are correct: it's not necessary to modify the FEX file to use the GPIO pins, and you should use the mainline formula to calculate pin numbers. I'll share what I learned attempting to solve this problem in case anyone else runs into it. As the error states, it's a permissions problem. Using "sudo echo" won't work because the redirection occurs before sudo is started, which ends up you trying to write to a file you don't have permissions to. To do a one-off manipulation of a GPIO pin, you have to start a separate shell as a superuser first, then use echo. For instance to turn pin A10 on: $ sudo sh # echo 10 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio10/direction # echo 1 > /sys/class/gpio/gpio10/value Or you can use tee to avoid creating a subshell: $ echo 10 | sudo tee /sys/class/gpio/export $ echo out | sudo tee /sys/class/gpio/gpio10/direction $ echo 1 | sudo tee /sys/class/gpio/gpio10/value A better, more permanent solution is to create a separate GPIO group, add yourself as a user to that group, and then give the GPIO group permissions to modify the GPIO pin directories: $ sudo groupadd gpio $ sudo usermod -aG gpio <your_username> $ su <your_username> $ sudo chgrp gpio /sys/class/gpio/export $ sudo chgrp gpio /sys/class/gpio/unexport $ sudo chmod 775 /sys/class/gpio/export $ sudo chmod 775 /sys/class/gpio/unexport You'll also have to modify the permissions on the directory of each GPIO pin you add. Again using pin A10 as an example: $ echo 10 > /sys/class/gpio/export $ chgrp -HR /sys/class/gpio/gpio10 $ chmod -R 775 /sys/class/gpio/gpio10 Then you can change that pin as necessary without being a superuser: $ echo out > /sys/class/gpio/gpio10/direction # set as output pin $ echo 1 > /sys/class/gpio/gpio10/value # set high $ echo 10 > /sys/class/gpio/gpio/unexport # reset the pin
  3. What is now the correct way to change the pin settings on kernel 3.4.113 if not modifying the FEX file? I didn't think it used Device Tree since it's below V 3.10. It still uses FEX files for other features (e.g., I got uart3 working on ttyS3 by simply editing the FEX file). FWIW, I had also tried using the mainline pin numbers to turn them on and off but still had the same problem. The example Accessing the GPIO pins through sysfs on sunxi-3.4 on the sunxi wiki uses a sequential numbering system defined by the FEX file to access the pins, not the mainline pin numbering system. That's why I tried using the method I did.
  4. I'm trying to use a few of the GPIO pins as output pins on an Orange Pi PC+ running Armbian 5.26 and legacy kernel 3.4.113-sun8i. When I look at the FEX file, it appears that the GPIO pins have all been disable d by default: [gpio_para] gpio_used = 0 gpio_num = 0 I don't recall them being disabled by default in previous versions of Armbian. I s this a recent change? Anyway, I edited the file and changed it to: [gpio_para] gpio_used = 1 gpio_num = 3 gpio_pin_1 = port:PA13<1><default><default><default> gpio_pin_2 = port:PA14<1><default><default><default> gpio_pin_3 = port:PD14<1><default><default><default> then did the following: $ fex2bin /tmp/custom.fex /boot/bin/custom.bin $ ln -sf /boot/bin/custom.bin /boot/script.bin <reboot> $ modprobe gpio-sunxi But I cannot seem to get the GPIO pins working: $ sudo echo 1 > /sys/class/gpio/export -bash: /sys/class/gpio/export: Permission denied Any advice on what I'm doing wrong?
  5. I have an Orange Pi Plus 2 that was running Armbian off of its onboard eMMC module, but I think I may have damaged it while working with the GPIO pins as it now will no longer boot from the module. The board will boot and run OK off of an SD card, but I'd like to copy the OS back to the eMMC module if possible. I've tried to rerun the script 'nand-sata-install', but I receive the error 'There are no targets. Please check your drives'. If I list the mmc devices I just get one, which I presume is the SD card: > ls -l /dev/ | grep mmcblk brw-rw---- 1 root disk 179, 0 Mar 20 16:51 mmcblk0 brw-rw---- 1 root disk 179, 1 Mar 20 16:51 mmcblk0p1 Does this mean the eMMC card is permanently damaged? Is there anything I could do to attempt to bring it back?
  6. I am having the same problem with UART2 on an Orange Pi+2 using the latest stable legacy version of Armbian (Armbian_5.20_Orangepiplus_Debian_jessie_3.4.112_desktop). It will receive, but it won't transmit. Convolu is correct; pin PA0 is misconfigured. In the fex file, PA0 has the following attributes: $ bin2fex /boot/script.bin | grep PA00 jtag_ms = port:PA00<3><default><default><default> uart_tx = port:PA00<2><1><default><default> gpio_pin_6 = port:PA00<1><default><default><0>But, according to sunxi-pio, it's an input pin: $ sudo sunxi-pio -m print | grep -E "^PA[0-4]<.*" PA0<0><0><0><0> PA1<2><1><1> PA2<2><1><1> PA3<2><1><1> PA4<2><1><1> Resetting the pin to match the settings of PA1 makes it work correctly as UART2_TX: $ sudo sunxi-pio -m PA0'<2><1><1>' $ sudo sunxi-pio -m print | grep -E "^PA[0-4]<.*" PA0<2><1><1> PA1<2><1><1> PA2<2><1><1> PA3<2><1><1> PA4<2><1><1> To expand on how Convolu got this to persist using systemd, here's what I did: 1. Create a service file in /etc/systemd/system using a text editor (must be run as root). Here's what my file looks like: $ cat /etc/systemd/system/pinA0_reconfigure.service [Unit] Description=Re-configure PinA0 as I/O for UART2_TX etc. [Service] Type=oneshot ExecStart=/usr/bin/sunxi-pio -m PA0'<2><1><1>' [Install] WantedBy=dev-ttyS2.device 2. Enable and start the service: $ systemctl enable pinA0_reconfigure.service created symlink from /etc/systemd/system/dev-ttyS2.device.wants/pinA0_reconfigure.service to /etc/systemd/system/pinA0_reconfigure.service. $ systemctl start pinA0_reconfigure.service
  7. I haven't quite figured out PL03 yet in the schematic, but it's a moot point for now anyway because I can't resume from suspend using the reset switch . I lose the wifi connection and get errors in a terminal window. Here's what I get in the terminal upon resume using the reset switch: Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565193] sunxi oops: enable sdcard JTAG interface Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565202] sunxi oops: cpu frequency: 1008 MHz Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565210] sunxi oops: ddr frequency: 672 MHz Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565219] sunxi oops: gpu frequency: 252 MHz Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565227] sunxi oops: cpu temperature: 48 Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.565238] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.568434] Process ifconfig (pid: 3353, stack limit = 0xd20322f8) Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.568446] Stack: (0xd2033d80 to 0xd2034000) Message from syslogd@localhost at Aug 20 20:40:13 ... kernel:[ 1864.568462] 3d80: eea44000 00000000 eea44500 00000000 d2033db4 d2033da0 c04643cc c0461b38 ...(more stack trace)... I can post the dmesg output if you want. FWIW, I'm using /etc/network/interfaces.default as the /etc/network/interfaces file. Following this, it won't shutdown properly, either. It just hangs, and I have to power off to get it to shutdown.
  8. Thanks, I'll let you know how it goes.
  9. First off, I'd like to thank the maintainers for all the work you've put into Armbian. It's really been a pleasure to use. I'm currently using an OrangePI 2+as a kiosk computer, and I'm wondering if there might be some other way to wake it from sleep other than pressing the power button. Would it be possible for it to wake from sleep if one of the GPIO pins were pulled high, for instance? TIA, -Jim