jimg

Members
  • Content count

    14
  • Joined

  • Last visited

  1. That seems reasonable. Thanks for all your help. You've saved me lots of time.
  2. What are the incompatibilites between the legacy kernel and Stretch? Just curious... Will there every be a mainline kernel version developed for Stretch, or will Armbian no longer support Debian?
  3. I have been using Debian Jessie on an Orange Pi Plus 2e, but decided to upgrade to Stretch so I could install Chromium (which isn't in the Jessie repositories). I substituted 'stretch' for 'jessie' in /etc/apt/sources.list, then did: $ sudo apt-get update $ sudo apt-get dist-upgrade Everything went OK, until it hung while reconfiguring network manger. I restarted and re-ran sudo apt-get dist-upgrade. Everything else appeared to install OK except network-manager (which is shown as installed but half-configured) and network-manager gnome (which is shown as unpacked and not configured), If I try to fix network-manager using dpkg, this is what i get: $ sudo dpkg --configure network-manager Setting up network-manager (1.6.2-3) ... Job for NetworkManager.service failed because the control process exited with error code. See "systemctl status NetworkManager.service" and "journalctl -xe" for details. invoke-rc.d: initscript network-manager, action "restart" failed. ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Mon 2017-07-03 11:20:42 CDT; 50ms ago Docs: man:NetworkManager(8) Process: 4100 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, status=226/NAMESPACE) Main PID: 4100 (code=exited, status=226/NAMESPACE) Jul 03 11:20:42 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:20:42 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. dpkg: error processing package network-manager (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: network-manager Here are the systemd error logs: $ systemctl status NetworkManager.service ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2017-07-03 11:35:20 CDT; 10s ago Docs: man:NetworkManager(8) Process: 4301 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=exited, status=226/NAMESPACE) Main PID: 4301 (code=exited, status=226/NAMESPACE) $ sudo journalctl -xe -- Subject: Unit NetworkManager.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has failed. -- -- The result is failed. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Service hold-off time over, scheduling restart. Jul 03 11:35:20 orangepiplus2e systemd[1]: Stopped Network Manager. -- Subject: Unit NetworkManager.service has finished shutting down -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has finished shutting down. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Start request repeated too quickly. Jul 03 11:35:20 orangepiplus2e systemd[1]: Failed to start Network Manager. -- Subject: Unit NetworkManager.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit NetworkManager.service has failed. -- -- The result is failed. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Unit entered failed state. Jul 03 11:35:20 orangepiplus2e systemd[1]: NetworkManager.service: Failed with result 'exit-code'. Jul 03 11:35:58 orangepiplus2e sudo[4307]: jim : TTY=pts/1 ; PWD=/home/jim ; USER=root ; COMMAND=/bin/journalctl -xe Jul 03 11:35:58 orangepiplus2e sudo[4307]: pam_unix(sudo:session): session opened for user root by jim(uid=0)
  4. Now that Debian stable has moved from Jessie to Stretch, what would it take to move the Debian branch of Armbian to Stretch? Would it break anything if I just s/jessie/stretch/g in /etc/apt/sources.list and do sudo apt-get update && sudo apt-get dist-upgrade?
  5. The chgrp command is incorrect. It should be: $ sudo chgrp -HR gpio /sys/class/gpio/gpio10
  6. 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
  7. 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.
  8. 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?
  9. 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?
  10. 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
  11. 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.
  12. Thanks, I'll let you know how it goes.
  13. 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