V10lator

  • Posts

    7
  • Joined

  • Last visited

Everything posted by V10lator

  1. I know the RPi is pretty limited on the GPIO pins. Now my question is how it looks on Le Potato, i.E. is it possible to power a fan directly from the GPIO pins? Powering it from the 3.3 V line seems to work just fine but I fear damaging hardware by trying to connect it to a GPIO instead.
  2. Could help a lot if you could give a link to what exactly you installed. I found this bug report: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1584488 - So the message seems harmless and should go away when you update. Sounds like there's no display server whatsoever but kodi doing everything directly. Try pressing Ctrl + Alt + F2 when kodi is running to get to a terminal. Log in as root there and see what's running with systemctl status
  3. Sorry about that. In the meantime everything seems to work, it was just bad reception. I re-arranged the antenna and got: root@libre-computer-board:/home/libre# ntpq -c as -c cv -c rv ind assid status conf reach auth condition last_event cnt =========================================================== 1 6448 8811 yes none none reject mobilize 1 2 6449 961b yes yes none sys.peer clock_alarm 1 associd=0 status=0060 6 events, clk_unspec, device="RAW DCF77 CODE (Conrad DCF77 receiver module)", timecode="--#---##-#####---D--S---8-2-p------p1-4--212-----1124-1---p", poll=19, noreply=0, badformat=2, baddata=1, fudgetime1=292.000, stratum=0, refid=DCFa, flags=0, refclock_time="dd9a3d04.00000000 Tue, Oct 24 2017 22:28:20.000", refclock_status="DST; TIME CODE; (LEAP INDICATION; CALLBIT)", refclock_format="RAW DCF77 Timecode", refclock_states="*NOMINAL: 00:03:21 (16.76%); BAD FORMAT: 00:15:38 (78.23%); ILLEGAL DATE: 00:01:00 (5.00%); running time: 00:19:59" associd=0 status=0218 leap_none, sync_lf_radio, 1 event, no_sys_peer, version="ntpd 4.2.8p4@1.3265-o Thu Sep 7 20:45:44 UTC 2017 (1)", processor="aarch64", system="Linux/4.13.3-v10-g019e61d-dirty", leap=00, stratum=1, precision=-22, rootdelay=0.000, rootdisp=163.587, refid=DCFa, reftime=dd9a3ccd.c4a9b7f9 Wed, Oct 25 2017 0:27:25.768, clock=dd9a3d04.a924ffa0 Wed, Oct 25 2017 0:28:20.660, peer=6449, tc=6, mintc=3, offset=-83.435947, frequency=493.057, sys_jitter=77.994238, clk_jitter=18.641, clk_wander=118.435
  4. Today we got working UART A, so I decided to wire up a cheap DCF77 receiver to it. On a first test I got spammed with libre-computer-board ntpd[1518]: parse: convert_rawdcf: start bit / parity check FAILED for "###############RADMLS1248124P124812P1248121241248112481248P??" This was solved with the following kernel patch: diff -Nru libretech-linux.old/drivers/tty/serial/meson_uart.c libretech-linux/drivers/tty/serial/meson_uart.c --- libretech-linux.old/drivers/tty/serial/meson_uart.c 2017-10-24 19:49:30.776000382 +0200 +++ libretech-linux/drivers/tty/serial/meson_uart.c 2017-10-24 19:52:39.660000472 +0200 @@ -362,7 +362,7 @@ writel(val, port->membase + AML_UART_CONTROL); - baud = uart_get_baud_rate(port, termios, old, 9600, 4000000); + baud = uart_get_baud_rate(port, termios, old, 50, 4000000); meson_uart_change_speed(port, baud); port->read_status_mask = AML_UART_TX_FIFO_WERR; No more errors in the logs but still no time: root@libre-computer-board:/home/libre# ntpq -c as -c cv -c rv ind assid status conf reach auth condition last_event cnt =========================================================== 1 29169 8811 yes none none reject mobilize 1 2 29170 802b yes no none reject clock_alarm 2 associd=0 status=0012 1 event, clk_bad_format, device="RAW DCF77 CODE (Conrad DCF77 receiver module)", timecode="-?#-#?-??---#--?-?-???---1??p1-?-?-?1--8-2--4-??-1?2-?1--8??_", poll=24, noreply=0, badformat=1, baddata=0, fudgetime1=292.000, stratum=0, refid=DCFa, flags=0, refclock_time="<UNDEFINED>", refclock_status="", refclock_format="RAW DCF77 Timecode", refclock_states="*BAD FORMAT: 00:24:38 (100.00%); running time: 00:24:38" associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart, version="ntpd 4.2.8p4@1.3265-o Thu Sep 7 20:45:44 UTC 2017 (1)", processor="aarch64", system="Linux/4.13.3-v10-g019e61d-dirty", leap=11, stratum=16, precision=-22, rootdelay=0.000, rootdisp=22.170, refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000, clock=dd99fe54.700d7c45 Tue, Oct 24 2017 20:00:52.437, peer=0, tc=3, mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000, clk_jitter=0.000, clk_wander=0.000 Any ideas?
  5. That's weird and might be why you see these errors. Could you check the outut of cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and if it says anything other than performance do sudo echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor (please note that this setting won't survive a reboot) and then redo your testing? BTW: Is wget https://git.kernel.org/torvalds/t/linux-4.14-rc5.tar.gz a good way to reproduce the issue for you? What's ifconfig and cat /etc/resolv.conf telling before and after you do ifdown/ifup?
  6. Did you comile your own kernel? Just asking as I had similar issues when compiling a custom kernel with any other CPU frequency governor than Performance. This is how it should be: $ gunzip -c /proc/config.gz | grep CPU_FREQ_GOV CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set
  7. Same here (make -j4 with gcc/g++) but it doesn't always bring the system down. It showed 45000 at the time the log messages happened. A pretty good way to reproduce seems to be doing "make -j4" on http://distfiles.macports.org/openfst/openfst-1.3.4.tar.gz - you'll either see internal "compiler error: Bus error" or "g++: internal compiler error: Segmentation fault (program cc1plus)" while dmesg shows the messages from @CaptManiac. I observed this on the 2GB Kit Special (first batch of production-ready batch of 2GB boards, push pin heatsink, custom active cooling case with fan, HDMI cable, power supply, and 32GB UHS MicroSD) in headless mode.