DoubleHP

Members
  • Content Count

    28
  • Joined

  • Last visited

About DoubleHP

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hello. Armbian_5.35_Orangepizero_Ubuntu_xenial_default_3.4.113.7z Orange Pi Zero 256 I am rading the bootlog via serial console. [FAILED] Failed to start Load Kernel Modules. See 'systemctl status systemd-modules-load.service' for details. # systemctl status systemd-modules-load.service â systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-modules-load.service.d ââ10-timeout.conf Active: failed (Result: exit-code) since Sun 2018-12-30 00:20:40 CET; 3min 8s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 167 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Main PID: 167 (code=exited, status=1/FAILURE) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Warning: systemd-modules-load.service changed on disk. Run 'systemctl daemon-reload' to reload units. # journalctl -f -b _PID=167 -- Logs begin at Sun 2018-12-30 00:20:45 CET. -- Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Failed to insert 'xradio_wlan': Connection timed out Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Inserted module 'g_serial' Dec 30 00:20:45 opi-06-app-c13 systemd-modules-load[167]: Inserted module 'xradio_wlan' ^C # cat /etc/modules #w1-sunxi #w1-gpio #w1-therm #sunxi-cir xradio_wlan g_serial xradio_wlan If I remove any xradio_wlan, then wlan0 is not available at boot. Is there a way to fix the boot error message, without loosing wlan0 ? Obviously, some one is aware of an issue, because some dev has put the same line twice in modules ...
  2. Random tips : - orange pi zero all have 2 SPI bus: one in the main GPIO port, and one for the flash on the back side. If you don't have the plus model, you can unsolder the FLASH and use the port. FLASH is port 1, so, GPIO is port 1. This is very important when you follow tutorials written for other opis - before you start following a tutorial, you need to understand which kernel you are using. If the turial is written after jan 2017, and mentions adding an overlay in armbianEnv.txt, then it's for kernel 4; if the tuto is before feb 2018, and does not mention altering armbianEnv.txt for SPI compatibility, author is using kernel 3. This is critical. - I got adressable LEDs working on both kernels, 3 and 4. Easier on 4. - SPI LCDs work only on kernel 3; I have spend days on kernel 4, just forget them; drivers exist, but they are broken. - con2fbmap is required only on kernel 3 - to get X working, you need to create /etc/X11/xorg.conf.d/99-fbturbo.conf - check your FB number with a command like this: dmesg | grep ili | grep graphics | grep -i fb . I have seen people using 0, 1 and 8. Now, I have ili9486 working perfectly fine ... with image Armbian_5.35_Orangepizero_Ubuntu_xenial_default_3.4.113 (kernel 3.4.113).
  3. DoubleHP

    Problem with FBTFT

    What's your distribution and kernel ?
  4. Previous time I asked where to report bugs: New bug: It's an old bug, met by many people, already reported and fixed by several distros, but, I still had it on a fresh new install: The problem and the fix: https://www.raspberrypi.org/forums/viewtopic.php?f=82&t=218609&p=1406567#p1406567 known bugs: https://bugs.launchpad.net/ubuntu/+source/watchdog/+bug/1448924 https://bugzilla.redhat.com/show_bug.cgi?id=1259816 # systemctl status watchdog.service â watchdog.service - watchdog daemon Loaded: loaded (/lib/systemd/system/watchdog.service; static; vendor preset: enabled) Active: inactive (dead) echo "WantedBy=default.target" >> /lib/systemd/system/watchdog.service systemctl daemon-reload systemctl enable watchdog reboot # wait 2 mn, because it needs to reboot twice. # systemctl status watchdog.service â watchdog.service - watchdog daemon Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-12-21 03:02:14 CET; 58s ago Process: 1122 ExecStart=/bin/sh -c [ $run_watchdog != 1 ] || exec /usr/sbin/watchdog $watchdog_options (code=exited, status=0/SUCCESS) Process: 1120 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module (code=exited, status=0/SUCCESS) Main PID: 1126 (watchdog) CGroup: /system.slice/watchdog.service ââ1126 /usr/sbin/watchdog Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: int=1s realtime=yes sync=no soft=no mla=5 mem=0 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: ping: no machine to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: file: /var/log/syslog:0 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: pidfile: no server process to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: interface: no interface to check Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: temperature: maximum = 80 Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: temperature: /sys/class/thermal/thermal_zone0/temp Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: test=none(0) repair=none(0) alive=/dev/watchdog heartbeat=none to=...ce=no Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: watchdog now set to 10 seconds Dec 21 03:02:14 opi-06-app-c13 watchdog[1126]: hardware watchdog identity: sunxi-wdt Hint: Some lines were ellipsized, use -l to show in full.
  5. I got an XPT2046 / ILI9486 working on Orange Pi Zero, in portrait mode: Be carefull: XPT2046 describes the touch layer; it's shared by many many many different LCD that use ... a huge variety of LCD chipsets: ILI9486, ili9340, and many many many more.
  6. Update: I have bought https://www.fasttech.com/products/0/10020192/5321900-3-5-320-480-tft-lcd-display-touch-board-for Sold with the following specs: which seems to me very similar to https://www.amazon.fr/gp/product/B06X191RX7/ref=oh_aui_detailpage_o02_s00?ie=UTF8&amp;psc=1 I started with image Armbian_5.35_Orangepizero_Ubuntu_xenial_next_4.13.16.img And then, ran the following commands to get the LCD working on oPi0: aptitude dist-upgrade vim /root/myili9431.dts # see previous message reboot aptitude install linux-headers-next-sunxi armbian-add-overlay myili9431.dts reboot modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 and now I have a console in portrait mode. # cat /root/myili9431.dts /* author: Adrian Brzezinski: adrb at wp.pl, adrian.brzezinski at adrb.pl */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@01c69000"; }; }; fragment@1 { target = <&spi1>; __overlay__ { status = "okay"; spidev { compatible = "spidev"; reg = <0>; spi-max-frequency = <50000000>; }; }; }; }; To get X: # Some of the following packages may be facultative. aptitude install startx xinit x11-xserver-utils xinput-calibrator xinput xserver-xorgxserver-xorg-video-all xterm x11-utils startx # gives a black console # or xinit # gives a white console Mouse does not work very well. Did not try keyboard. No touchpad (I don't need it, so, no time to loose on this). Rotation of screen works, but produces crappy output. # Need reboot each time modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=90 modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=180 modprobe fbtft_device custom name=fb_ili9486 gpios=dc:18,reset:2 speed=16000000 busnum=1 rotate=270 # 90 and 270 produce a rectangle in landscape orientation; unusable in neither console or X. # 180 works fine. Bed time; more tries later. Some tips to make conf persistent: https://kaspars.net/blog/linux/spi-display-orange-pi-zero
  7. I was wrong ... I just found a corruption on my wifi master AP opi, an opi that never does scanning, since it's always in master mode: # cat /boot/armbianEnv.txt.backup.2018-11-17_22-14-09 verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u # cat /boot/armbianEnv.txt | hexdump 0000000 6576 6272 736f 7469 3d79 0a31 6f6c 6f67 0000010 643d 7369 6261 656c 0a64 6f63 736e 6c6f 0000020 3d65 6f62 6874 640a 7369 5f70 6f6d 6564 0000030 313d 3239 7830 3031 3038 3670 0a30 766f 0000040 7265 616c 5f79 7270 6665 7869 733d 6e75 0000050 6938 682d 0a33 766f 7265 616c 7379 753d 0000060 6273 6f68 7473 2032 7375 6862 736f 3374 0000070 7720 2d31 7067 6f69 700a 7261 6d61 775f 0000080 5f31 6970 3d6e 4150 3531 720a 6f6f 6474 0000090 7665 553d 4955 3d44 6265 3965 6164 6663 00000a0 312d 3432 2d66 3834 6336 622d 6336 2d31 00000b0 3830 3437 6539 3032 3339 3437 720a 6f6f 00000c0 6674 7473 7079 3d65 7865 3474 000a 0000 00000d0 0000 0000 0000 0000 0000 0000 0000 0000 * 0000120 0000 0000 0000 0000 0000 0000 0000 7500 0000130 6273 7473 726f 6761 7165 6975 6b72 3d73 0000140 7830 3532 3733 303a 3178 3630 3a36 2c75 0000150 7830 3532 3733 303a 3178 3630 3a38 0a75 0000160 7375 7362 6f74 6172 6567 7571 7269 736b 0000170 303d 3278 3335 3a37 7830 3031 3636 753a 0000180 302c 3278 3335 3a37 7830 3031 3836 753a 0000190 000a 0000191 Tricky one ... was not visible in car, only in vim ...
  8. Took me over a year to isolate this bug. Randomly, I have found that /boot/armbianEnv.txt had unconsistent content. Examples: .tty1tty1LOGIN.8 ¹[fU7ttyS0tyS0LOGINusbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u network={ ssid="Demaine_40_Grd_Rue_Chambre-BP" #psk="1234567890" psk=693d195a3bf2ab6defbcc0b54604ced4286a067996138db6dc793d8648f67d79 } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u network={ ssid="fabste" #psk="1234567890" psk=95342031a4b28398045e1761f9c64f8454902e80d37102e5476fa79abd59e144 } 2 } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u At last, I have found that "fabste" is the SSID of the network of my neighbour. How did this get here ? The bug occurs only on Orange Pi Zero boards ... which need to perform wifi scan. Does not happen on boards that operate as WIFI AP, or use ethernet. The wifi scan is required to connect to the AP. The scan seem to produce a temp file somewhere (maybe in /tmp, not sure). Then, later, /etc/init.d/armhwinfo runs this, which is very suspicious to me: read USBQUIRKS <${TMPFILE} sed -i '/^usbstoragequirks/d' /boot/armbianEnv.txt echo "usbstoragequirks=${USBQUIRKS}" >>/boot/armbianEnv.txt and if this is followed by a power failure, you end up with a corrupted file: https://lists.denx.de/pipermail/u-boot/2018-June/332375.html https://github.com/ConnectBox/connectbox-pi/issues/220 It's a rare issue from Google point of view; but it's known, and it makes most of my opi0 unusable. Sooner or later, it affects 100% of my opi0 that work as wifi clients. It rendends my pis unusable because I need very specific features which are set in /boot/armbianEnv.txt , usually w1-gpio. When the file is corrupted, and after reboot, I loose control over my 1W devices, and the whole project got broken. Here is my fstab, in case it matters: UUID=ebe9dacf-124f-486c-b6c1-08749e209374 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 I am not sure how to fix this at the distribution level: - use something different than sed in armhwinfo to alter /boot/armbianEnv.txt - perform a sync - change ext4 features - change mount options For now, I am trying to write a personnal fix: record a backup copy of /boot/armbianEnv.txt and restaure it if critical words like "overlay_prefix=sun8i-h3" disappear. Note that, when the file is heavily broken, for all 3 examples above, the pi can boot, establish network connexion, and remains reachable, mostly. I only loose the 1W or GPIO feature. There seem to be very good default settings set as fallback somewhere else. Here are unaffected opis: verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=cir usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 w1-gpio param_w1_pin=PA15 rootdev=UUID=ebe9dacf-124f-486c-b6c1-08749e209374 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I am not sure why one has an empty line. But in both case, the usbstoragequirks line is doubled, and identical to my eyes. This means, /etc/init.d/armhwinfo tries to add already existing data. This script lacks checks !!! .
  9. Either I tried to mkdir build, or, maybe I made the LCD work without this git tree; I forgot. But according to my last post, I probably got it working without this git tree. Try my post from Jan 17th 2018 ...
  10. DoubleHP

    Orange Pi PC 1-Wire

    According to https://www.armbian.com/orange-pi-zero/ My way to do it is crontab: * * * * * root /usr/bin/cpufreq-set -f 1200MHz ; /usr/bin/cpufreq-set -g performance Of course, editing /etc/default/cpufrequtils sounds much better.
  11. DoubleHP

    /var easily get full with log2ram

    When default settings lead to "aptitude install munin-node" refuse to install the package, on 3 machines in two weeks, there is a bug at the distro level. My fix for now: # cat /etc/crontab | grep var * * * * * root [ $(df -h /var/log | grep -e "/var/log" | awk '{print $5}' | tr -d "\%") -gt 90 ] && rm "/var/log/$(ls -S /var/log/ | head -n1)" && systemctl restart log2ram # this crontab line checks every minute if /var/log is more than 90% full, and if it is, removes the largest file. tkaiser I disagree; your idea is very good; it's what I was planning to do on long term; but in emergency, I wrote the above simple line. I usually keep all my logs for 10 years. So, the best way to do this would be to sync rotated logs to .hdd, and then remove them immediately from the ramdisk. And sync at boot should exclude them. It's not hard to do; just a few rsync arguments. But I got more urgent things to do now. Logrotate also would probably need some customisation to handle side effect of this sync. Not finding /var/log/syslog at all, or having an empty file is much more an issue than not finding /var/log/syslog.1 The partial sync also allows to have a /var/log.hdd larger than 50M, allowing to keep a lot of logs, while log2ram limits it to 50M. PEople who would be confused by this can disable log2ram; but this comes with a risk for the flash.
  12. DoubleHP

    /var easily get full with log2ram

    I am working on a workaround; but there is a bug at the distribution level, because once var has reached 100%, the only way to get /var/log working again is to manually remove a file; if you reboot 10 times or wait a full week, the system will NOT fix itself. And since the bug occurs often, there should be a fix at the distro level.
  13. DoubleHP

    /var easily get full with log2ram

    On most your Orange Pi Zero 256M, I got this: # df -h Filesystem Size Used Avail Use% Mounted on udev 85M 0 85M 0% /dev tmpfs 25M 3.5M 21M 15% /run /dev/mmcblk0p1 15G 1.3G 14G 9% / tmpfs 120M 4.0K 120M 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 120M 0 120M 0% /sys/fs/cgroup tmpfs 120M 80K 120M 1% /tmp log2ram 50M 50M 0 100% /var/log tmpfs 25M 0 25M 0% /run/user/0 This happens very fast, after a few days, for Pis that are now plugged 24/7. Then I have to manually remove some large file, and, when the Pi have run a cron.daily and cron.weekly, and it always stays on, then, this never happens again. What is the best workaround, or fix ? Obvisouly, I can not really increase the size of the ramdisk. I don't want either to stop using log2ram; I have killed many SD cards in the past. And the problem is always the same: # ls -lha /var/log/ | grep M total 50M -rw-r----- 1 syslog adm 25M Feb 27 04:49 kern.log.1 -rw-r----- 1 syslog adm 25M Feb 27 06:25 syslog.1 drwxr-xr-x 2 root root 40 May 12 2016 sysstat This is the third time. # head /var/log/syslog.1 Nov 25 06:20:40 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="579" x-info="http://www.rsyslog.com"] start Nov 25 06:20:40 localhost rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ] Nov 25 06:20:40 localhost rsyslogd: rsyslogd's groupid changed to 108 Nov 25 06:20:40 localhost rsyslogd: rsyslogd's userid changed to 104 Nov 25 06:20:40 localhost kernel: [ 0.000000] Booting Linux on physical CPU 0x0 Nov 25 06:20:40 localhost kernel: [ 0.000000] random: get_random_bytes called from start_kernel+0x31/0x352 with crng_init=0 Nov 25 06:20:40 localhost kernel: [ 0.000000] Linux version 4.13.16-sunxi (root@armbian) (gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08)) #20 SMP Fri Nov 24 19:50:07 CET 2017 Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=50c5387d Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: div instructions available: patching division code Nov 25 06:20:40 localhost kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache # tail /var/log/syslog.1 Feb 12 17:44:52 localhost kernel: [23357.366931] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366935] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366940] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366944] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366949] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366953] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366957] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366962] rc rc0: IR event FIFO is full! Feb 12 17:44:52 localhost kernel: [23357.366966] rc rc0: IR event FIFO is full! 1: I don't like removing logs 2: this is a recurring bug on several pis; either I am doing something wrong each time, or there is a bug deep in Armbian.
  14. DoubleHP

    System watchdog package usage

    Here is my solution: echo '@reboot root while true ; do echo 1 > /dev/watchdog ; sleep 3 ; done' >>/etc/crontab Everything else fails. Doing 'cat /dev/watchdog' or 'echo 1 >/dev/watchdog' makes the system reboot 16s later ... prooving the hardware part works fine, but that the service is not doing it's job properly. Some people say there should be one process per core. Other people have more than 1 line out of 'dmesg | grep wat' This second form procudess less mess in dmesg and syslog: echo '@reboot root { while true ; do echo 1 ; sleep 1 ; done ; } > /dev/watchdog' >>/etc/crontab But both may be unreliable; depending on which shell interprets the line, things like bash may produce a routine that is always run by the same process; so if the kernel is lacking of memory, or can not create any new process, that snipset may keep feeding watchdog even on a dead machine. So, this (untested) method may be reliable to track process creation issues: echo '* * * * * root { for i in $(seq 11) ; do echo 1 ; sleep 10 ; done ; } > /dev/watchdog' >>/etc/crontab but it will produce one line of garbage per minute. In either case, have fun killing the parent process, and you get a reboot. Proofing my stupid line works better than the service installed by 'apt-get install watchdog', even after loosing 2h in /etc/default/watchdog and /etc/watchdog.conf
  15. DoubleHP

    System watchdog package usage

    I am stuck as well, did you find a solution ?